lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Diakov <nikolay.dia...@fredhopper.com>
Subject Re: - possible bug in lock timeout
Date Wed, 07 Nov 2007 14:05:12 GMT
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


Mime
View raw message