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:25:42 GMT
Ok, some more info then - one of our tests ran on a machine with not so 
many resources. The system started swapping a lot and the file system 
slowed down its response to many operations. As one effect - locks 
started timing out. We like to have these machines around since slow 
machines tend to make more likely to happen some otherwise tricky errors 
that one does not see very often on fast machines. Hence the thing with 
mandatory locks that lock "no matter what", and the subsequent posting.

--Nikolay

Mark Miller wrote:
> 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
> 

---------------------------------------------------------------------
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