qweries at gmail.com
Wed Jul 5 03:55:45 EDT 2006
We moved the logging code to expungeStaleEntry and the log files are
getting generated. From the logs it was confirmed that it was a
re-entrant call to ThreadLocalMap, the call sequence being:
So infact we were facing "5025230R (thread) Creating thread local
variables from within ThreadLocal.initialValue()".
Thomas, like you mentioned, it appears that using third party
libraries in ThreadLocal.initialValue is dangerous. Extending the
argument we should consider JDK classes as third party classes (you
never know which JDK class implementation uses a ThreadLocal). Which
basically means never over-ride ThreadLocal.initialValue.
Thanks all for all the help.
On 7/3/06, Thomas Hawtin <tackline at tackline.plus.com> wrote:
> Raj wrote:
> > To check if we are facing the "ThreadLocal.initialValue" creating a
> > new ThreadLocal bug, we added the following to ThreadLocal.java and
> > set it in the boot classpath.
> It's not a problem of creating a ThreadLocal within initialValue. The
> problem is initialising a pre-thread value for a ThreadLocal, from
> either set or get.
> If you put you logging code in replaceStaleEntry and rehash, I suspect
> you will see a call from initialValue (or no NPE).
> Tom Hawtin
More information about the Concurrency-interest