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 <[EMAIL PROTECTED]> 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 <[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]
---------------------------------------------------------------------
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]
