[concurrency-interest] NullPointerExceptioninThreadLocal$ThreadLocalMap.replaceStaleEntry

Raj qweries at gmail.com
Wed Jul 5 03:55:45 EDT 2006


Hi Tom,

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:
    ThreadLocal.get
    ThreadLocal$ThreadLocalMap.get
    ThreadLocal.initialValue
    DocumentBuilderFactory.newInstance
    AppServerClassLoader.loadClass
    ThreadLocal.get
    ThreadLocal$ThreadLocalMap.expungeStaleEntry

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.

Regards,
Raj

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 mailing list