"Jason Polites" <[EMAIL PROTECTED]> wrote on 27/08/2006 09:36:07:
> I would have thought that simultaneous cross-JVM access to an index was > outside of scope of the core Lucene API (although it would be great), but > maybe the file system basis allows for this (?). Lucene does protect you from mis-accessing its indexes from separate jvms or even, to a certain extent, separate machines. > > I like the idea of catching IOExceptions and returning false. Conceptually, > failing to obtain a lock due to any reason can be thought of as the same > thing, regardless of the reason (so long as its logged). > > Seems like the simplest solution too. I agree with this - as this would be a more correct behavior when the lock could not be obtained. However it would not handle the problem that I had, and I think you had too - that due to some temporary situation in the OS/FS there is a temporary inability to perform an action that should be possible - i.e. creating a new file, or renaming another. Application writers would be "surprised" to be having to deal with this failure to obtain a lock with no "expected" reason. Since this painful situation is evidently possible, and since this is so frustrating for Lucene users to get their index corrupted in this case, I still think it is worth the effort of spending some 30ms or so on the rare occasions that this happen, and retry, trying to bypass this temporary obstacle. Did you try that patch? Does it work for you? I plan to submit an update to that patch later today accommodating your comments (and others); It will most probably retry for IOExceptions (not analyzing the exception text); also, it would return false if the *retry* for obtain() failed with exception. If you can try out this patch it would be very valuable information to know whether it prevents the problem or not. Thanks, Doron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
