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:26:59 GMT
I hope we do not get lock starvation or anything in these cases. Do 
these lock have any fairness integrated in them?

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