<br><br><div class="gmail_quote">On Mon, May 17, 2010 at 11:47 AM, Manik Surtani <span dir="ltr"><<a href="mailto:manik@jboss.org">manik@jboss.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 16 May 2010, at 18:35, Philippe Van Dyck wrote:<br>
<br>
> Hi all,<br>
><br>
> in a servlet environment, you sometimes have to claim back a thread for your thread pool.<br>
> 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).<br>
><br>
> 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 ? ;-)<br>
><br>
> Calls to acquireLock should be guarded by a finally {releaseLock} (at least to catch an interruptedException)<br>
<br>
</div>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?<br></blockquote><div><br></div><div>Done - <span class="Apple-style-span" style="font-family: arial, FreeSans, Helvetica, sans-serif; font-size: 14px; color: rgb(51, 51, 51); line-height: 19px; "><a id="key-val" href="/browse/ISPN-444" style="cursor: pointer; text-decoration: underline; color: rgb(102, 0, 0); ">ISPN-444</a></span></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> It looks very easy to implement, but since releaseLock does not seems to be called every time in the code, I need help !<br>
><br>
> The only places where aquireLock is called are CacheLoaderInterceptor.loadIfNeeded and EntryFactoryImpl.wrapEntryForWriting.<br>
><br>
> 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!<br>
<br>
</div>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)?<br>
</blockquote><div><br></div><div>I think there is a need for this kind of cleanup whatever the reason a lock is in 'stale' mode.</div><div><br></div><div>But IMHO there is a lot of cleanup to do when you interrupt a thread !</div>
<div><br></div><div>What about some timeout callback attached to each lock ?</div><div><br></div><div>Now, to test this, you should replay test suites with a 'one millisecond' timeout and ensure that everything is correctly cleaned up.</div>
<div>Great way to improve the quality of the code, but hell of a job!</div><div><br></div><div>Cheers,</div><div><br></div><div>phil</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers<br>
Manik<br>
--<br>
Manik Surtani<br>
<a href="mailto:manik@jboss.org">manik@jboss.org</a><br>
Lead, Infinispan<br>
Lead, JBoss Cache<br>
<a href="http://www.infinispan.org" target="_blank">http://www.infinispan.org</a><br>
<a href="http://www.jbosscache.org" target="_blank">http://www.jbosscache.org</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div><br>