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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to