[infinispan-dev] lock acquisition - "finally release" it
Philippe Van Dyck
pvdyck at gmail.com
Mon May 17 07:37:33 EDT 2010
On Mon, May 17, 2010 at 11:47 AM, Manik Surtani <manik at jboss.org> wrote:
>
> On 16 May 2010, at 18:35, Philippe Van Dyck wrote:
>
> > Hi all,
> >
> > in a servlet environment, you sometimes have to claim back a thread for
> your thread pool.
> > Jetty has a nice "denial of service attack" filter and a setting
> (maxIdleTime) interrupting servlet threads if nothing comes out (nothing is
> written in the pipe).
> >
> > Well it does not play well with infinispan. Everybody knows that when you
> open a stream, the best way to reclaim scarce resources is to close it in a
> 'finally' statement. What about applying it to infinispan locking mechanism
> ? ;-)
> >
> > Calls to acquireLock should be guarded by a finally {releaseLock} (at
> least to catch an interruptedException)
>
> This is a good point, in the event of a failure (for whatever reason) the
> lock may still be acquired and should be cleaned up. Care to create a JIRA
> for this?
>
Done - ISPN-444 </browse/ISPN-444>
>
> > It looks very easy to implement, but since releaseLock does not seems to
> be called every time in the code, I need help !
> >
> > The only places where aquireLock is called are
> CacheLoaderInterceptor.loadIfNeeded and
> EntryFactoryImpl.wrapEntryForWriting.
> >
> > And BTW, the locks never expire ... so if you interrupt a thread and the
> lock is not released, you better say bye bye to the cache entry!
>
> Hmm. While I agree in principle (we could implement a max lock period in
> the config file), how do you see this working in practice? Maintain
> timestamps of all acquired locks, and have a maintenance thread regularly
> check these for locks that have expired (and then interrupt the locking
> thread)?
>
I think there is a need for this kind of cleanup whatever the reason a lock
is in 'stale' mode.
But IMHO there is a lot of cleanup to do when you interrupt a thread !
What about some timeout callback attached to each lock ?
Now, to test this, you should replay test suites with a 'one millisecond'
timeout and ensure that everything is correctly cleaned up.
Great way to improve the quality of the code, but hell of a job!
Cheers,
phil
>
> Cheers
> Manik
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100517/9550905d/attachment.html
More information about the infinispan-dev
mailing list