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:06:59 GMT
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 <markrmiller@gmail.com> 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