Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3F391ADB.7010902@earthlink.net>
Date: Tue, 12 Aug 2003 10:50:35 -0600
From: Dmitry Serebrennikov <dmitrys@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: Lucene Developers List <lucene-dev@jakarta.apache.org>
Subject: Re: Adding lock timeouts to write.lock
References: <3F340378.3020301@etapestry.com> <3F390198.1030203@etapestry.com>
In-Reply-To: <3F390198.1030203@etapestry.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

There is another change around the locks that I have made in our copy of 
Lucene that has been working really well.
Perhaps something like this already exists in the main code base (I 
haven't checked lately), but the idea was this: most of the problems 
that we were getting with locks was due to a crash of some type that 
left locks in place. They later had to be removed manually or the system 
wouldn't work. The solution that worked in our environment was to add a 
"staleLockAge" parameter to the methods that attempt to obtain the lock. 
If the lock was present but was older than the specified age, it was 
considered "stale" and would automatically be broken (the file deleted). 
This worked in our environment because we never hold locks for longer 
than a few minutes.

Is something like this already in the code base? If not, what do people 
think about it? I can supply more detailed API if needed.
Dmitry.


Scott Ganyo wrote:

> Ok, I know I said I'd check in Wednesday, but as it turns out I'm 
> going to be out Wednesday.  So, as there has only been positive 
> feedback, I'm just going to go ahead and commit now.
>
> Scott
>
> Scott Ganyo wrote:
>
>> As suggested in previous emails, I have implemented the ability to 
>> wait on any kind of lock.  I've attached the diffs, but here are the 
>> highlights:
>>
>> 1) added the following statics to Lock:
>>
>>    public static long WRITE_LOCK_TIMEOUT = 1000;
>>    public static long COMMIT_LOCK_TIMEOUT = 10000;
>>    public static long LOCK_POLL_INTERVAL = 1000;
>>
>> 2) added the following method to Lock:
>>
>>  /** Attempt to obtain an exclusive lock within amount
>>   *  of time given. Currently polls once per second until
>>   *  lockWaitTimeout is passed.
>>   * @param lockWaitTimeout length of time to wait in ms
>>   * @return true if lock was obtained
>>   * @throws IOException if lock wait times out or obtain() throws an 
>> IOException
>>   */
>>  public boolean obtain(long lockWaitTimeout) throws IOException
>>
>> 3) added the following method to Lock.With:
>>
>>    /** Constructs an executor that will grab the named lock. */
>>    public With(Lock lock, long lockWaitTimeout)
>>
>> 4) cleaned up Lock.With to use the new obtain(long) method on Lock.
>>
>> 5) changed callers obtaining "write.lock" to pass 
>> Lock.WRITE_LOCK_TIMEOUT
>>
>> 6) changed callers obtaining "commit.lock" to pass 
>> Lock.COMMIT_LOCK_TIMEOUT
>>
>> The net effect is to expose the timeout and change the write.lock to 
>> have a 1 second timeout as a default instead of immediately throwing 
>> an IOException.
>>
>> So that there can be a review and comment period, I won't plan to 
>> check it in Wednesday of next week.
>>
>> Scott
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>