OK, I've opened https://issues.apache.org/jira/browse/LUCENE-1048 to this issue.
Thanks Nikolay!
Mike
"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_
"Nikolay Diakov" <[EMAIL PROTECTED]> wrote:
> I hope we do not get lock starvation or anything in these cases. Do
> these lock have any fairness integrated in them?
Unfortunately, none of the builtin lock factories in Lucene have
fairness: they always just retry once per second (by default). T
Seems pretty desirable to me. Unless you where *really* counting on
that lock obtain timing out after how ever many years of being denied
.
On Nov 7, 2007 9:06 AM, Nikolay Diakov <[EMAIL PROTECTED]> wrote:
> Yes, yes, I never said it does not work ;-). I wrote that we get a
> negative number there
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 us
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.
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 c
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:
H...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
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
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
produ
H...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 v
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, 20
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 p
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
13 matches
Mail list logo
