lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller" <markrmil...@gmail.com>
Subject Re: - possible bug in lock timeout
Date Wed, 07 Nov 2007 14:18:08 GMT
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 <nikolay.diakov@fredhopper.com> 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 <nikolay.diakov@fredhopper.com> 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 <nikolay.diakov@fredhopper.com>
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: java-user-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: java-user-help@lucene.apache.org
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: java-user-help@lucene.apache.org
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: java-user-help@lucene.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message