Hmmmm...it seems to me that making locks that never time out would be hiding a real problem that you could be having. It should never take anywhere near that long to get a lock, and if it does, something very serious is wrong and very unlikely to fix itself. I don't think this lock is even of any value if you access the index with only one JVM and follow good Lucene design practices. I think its more of a safeguard against erratic use...
On Nov 7, 2007 9:05 AM, Nikolay Diakov <[EMAIL PROTECTED]> wrote: > Ok, to make thing simpler, our application cannot tolerate timeouts, so > the following business case becomes desirable: > > "I'd like mandatory locks - ones that either block or lock the resource." > > One way to do this requires passing of a very large value that seems > infinite to a normal business user. At the moment we use 100 minutes, > but our first guess was - "hey, lets try the maximum number - it works > on other lock based APIs of Java". Hence the reported "feature". > > Anyway, the least improvement of Lucene in that respect would include > documenting the usable range of the argument value - in that case [0 to > 1000 times less than Long. MAX_VALUE]. The left interval border one can > guess easily as we have milliseconds. For the right border one needs to > look at the code for a spec. > > > Cheers, > Nikolay > > Mark Miller wrote: > > I agree to an extent. You could argue for checks like this in a lot of > > places though. It seems to protect an odd use case here. Normally your > > timeout would not be anywhere near Long.MAX_VALUE. I would argue there > > should be a better way to set "never timeout" than by using a huge > > number. In either case, its a pretty easy error to spot even without > > an exception thrown. These types of checks are a slippery slope. > > > > Of course the Lucene developers just might agree with you. > > > > On Nov 7, 2007 8:48 AM, Nikolay Diakov <[EMAIL PROTECTED]> wrote: > >> Thanks, I understand. > >> > >> Nevertheless, a proper check for > Integer.MAX_VALUE won't hurt and will > >> make the function tolerate the whole range of its parameter values. > >> > >> Cheers, > >> Nikolay > >> > >> > >> Mark Miller wrote: > >>> There are a few places in Lucene (prob in a lot of other code as well) > >>> where you should not use Long.MAX_VALUE. > >>> > >>> Don't use it as the number of docs to return in a TopDocsCollector > >>> either. If the code that takes that long even just adds 1 to the > >>> variable...your screwed with a huge negative number. > >>> > >>> In your case here, a huge long is getting cast to an int, and the int > >>> just cannot hold a number that big. > >>> > >>> Prob could be handled better, but I would avoid using Long.MAX_VALUE > >>> anyway. > >>> > >>> - Mark > >>> > >>> On Nov 7, 2007 8:21 AM, Nikolay Diakov <[EMAIL PROTECTED]> wrote: > >>>> In Lucene 2.x, in method Lock#obtain(long lockWaitTimeout) I see the > >>>> following line: > >>>> > >>>> int maxSleepCount = (int)(lockWaitTimeout / LOCK_POLL_INTERVAL); > >>>> > >>>> Since I wanted to set the lock timeout to the largest possible, I called > >>>> the IndexWriter#setDefaultWriteLockTimeout(Long.MAX_VALUE). This > >>>> produces the effect in the quoted line that we get maxSleepCount a > >>>> negative number. > >>>> > >>>> Is this intended? > >>>> > >>>> Cheers, > >>>> Nik > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
