Seems pretty desirable to me. Unless you where *really* counting on that lock obtain timing out after how ever many years of being denied <g>.
On Nov 7, 2007 9:06 AM, Nikolay Diakov <[EMAIL PROTECTED]> wrote: > Yes, yes, I never said it does not work ;-). I wrote that we get a > negative number there, doubting it desired behavior. > > --Nikolay > > > Mark Miller wrote: > > By the way...it looks like to me like you still get the behavior you > > wanted. Getting the lock effectively never times out, correct? > > > > On Nov 7, 2007 8:54 AM, Mark Miller <[EMAIL PROTECTED]> 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]
