McCandless wrote:
I agree, we should not ignore the return value here. I think throwing an
exception if it returns false is the right thing to do? Though, if it's
a checked exception, that's not a backwards compatible change...
Mike
"Nikolay Diakov" <[EMAIL PROTECTED]>
I have briefly reviewed the SimpleFSLock of Lucene 2.1 and 2.2. I see
that the lock release mechanism does not check the return value of delete:
public void release() {
lockFile.delete();
}
On most linux-es this can never return false, however under some windows
FS if someone (a virus
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 > I
.
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
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
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
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 <[EMAI
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 = (i
