<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 12:52 AM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</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">On 12/11/2013 04:47 PM, Pedro Ruivo wrote:<br>
> Hi,<br>
><br>
> I've created a method to clean a specific ThreadLocal variable from all<br>
> live threads [1].<br>
><br>
> My goal is to clean the ThreadLocal variables after a cache stops. It's<br>
> kind expensive method (it uses reflection) but I think it is fine.<br>
><br>
> Currently, I'm using it to clear the Marshaller ThreadLocal in here [2].<br>
><br>
> Does anyone see any problem with this approach? Maybe it can be used in<br>
> other possible leaking ThreadLocals?<br>
<br>
</div>It's an interesting idea (I've done something similar in the past to<br>
simply drop all thread locals). I would recommend that you check that<br>
all the JDKs you want to support use the same technique for thread<br>
locals though. Because these fields are not part of the JDK, they may<br>
not always exist in all environments.<br></blockquote><div><br></div><div>Yeah, the implementation of ThreadLocal has changed in the past and is likely to change again in the future. If that happens and we have to support different JDKs with different methods for clearing ThreadLocals, it won't be pretty.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, it is important to only ever clean the thread locals of your<br>
current thread, or you're inviting all kinds of bizarre concurrency<br>
problems (maybe even locking threads into infinite loops), especially if<br>
the thread is running and actively using thread locals at the time.<br></blockquote><div><br></div><div>Indeed, ThreadLocalMap doesn't look to be thread-safe. I'm not sure if a remote() from another thread can cause an infinite loop like in HashMap because it uses open addressing instead of chaining, but it looks like it may cause a get() for a different ThreadLocal to return the wrong instance. (I would be ok with it if it would only cause breakage for threads using the cache that's being stopped, but it looks like it can touch more than one entry.)<br>
<br></div><div>I think we shouldn't concern ourselves with actually removing the ThreadLocal from the map, we just have to keep track of the ThreadLocal instances and clean any references to other objects they might have (a la ExternalizerTableProxy). Or maybe give up on ThreadLocals and use a ConcurrentWeakKeyHashMap<Thread, PerThreadInstanceHolder> instead.<br>
<br></div><div>Dan<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">--<br>
- DML<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div></div>