Hi We've run into problems w/ LockFactory usage on our system. The problem is that the system can be such that the index is configured on a local file system, or a remote, shared one. If remote/share, the protocol is sometimes SMB 1.0/2.0, Samba, NFS 3/4 etc. In short, we have no control on the FS type used or OS (Linux, Windows 2003/2008, Unix, AIX, iSeries etc.).
We currently use NativeFSLockFactory, because we want to ensure the lock file is deleted upon JVM exit, whether by clean exit, or "kill". However, the more I read the documentation of the class, and the inline documentation in the class, I get a feeling that this choice, in our environment, is error prone. Some file systems do not support native FS locking, some may take too long to obtain the lock, in which case the Lock obtain method will timeout etc. The current problem is that the index is configured on a Samba share, and we hit LockObtainFailedExceptions (timeouts, or Access Denied once). When the system is configured on a Windows share (I think SMB 1.0), everything works fine. So I'm not sure what to do. Should we always use SimpleFSLockFactory? We know for sure only one node in the cluster will access the shared file system for writing (not in a given time, but always). Therefore I was tempted to move to NoLockFactory. But this move scares me a bit, and I'd appreciate if someone can confirm my understanding of Lock being used to protect against multiple IndexWriters from different JVMs *only*, or does it have other uses as well? What about multiple IndexWriters from the same JVM? If NoLockFactory is not safe, then we can move to SimpleFSLockFactory, and since we can guarantee by other means that only one IndexWriter attempts to write to the index, we can IndexWriter.unlock(Dir) if the lock exists. Also, the code of NativeFSLockFactory mentions that on NFS if not configured properly, the lock obtaining may take 35 seconds. What sort of configuration is needed? Just out of curiosity. Any advice will be appreciated. Shai
