Re: [infinispan-dev] lock acquisition - "finally release" it
On 17 May 2010, at 12:37, Philippe Van Dyck wrote:
On Mon, May 17, 2010 at 11:47 AM, Manik Surtani <manik(a)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
Hmm, about this - I suppose it really isn't enough to wrap the tryLock call since a
thread could be interrupted doing a multitude of other things in addition to just
acquiring locks - e.g., waiting to write state to a cache store, network comms, etc.
So while I have checked in a fix for ISPN-444 [1], I presume what we really need is a
finally block around the InvocationContextInterceptor where all invocations come in [2],
to clean up any locks acquired within the scope of the current call.
Thoughts?
Cheers
Manik
[1] http://fisheye.jboss.org/changelog/Infinispan/trunk?cs=1794
[2]
http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org