DefaultLegacySupport and long-lived worker threads

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

DefaultLegacySupport and long-lived worker threads

András Péteri

I have encountered an issue similar to MNG-4785 [1] while using plugins
from Eclipse's Tycho project, where code running in a worker thread of
Eclipse's job framework uses LegacySupport to get the current Maven
session. It is used for artifact resolution [2], just like in the ticket.
This works until LegacySupport#setSession is called from the main thread,
at which point the default implementation [3]:

- sets the value of the current AtomicReference to null;
- if the new session is not null, it also replaces the AtomicReference with
another instance, leaving child threads with the null-ed out earlier

The thread pool maintained by the job manager does not retire worker
threads immediately after they are finished with the current job, so it is
purely based on workload/chance when a new thread is spawned, and when an
existing thread takes on the next submitted job. The new threads have no
issues, as InheritableThreadLocal can initialize the variable with a "good"
AtomicReference from the parent thread; this is also mentioned in the
comments section of the JIRA ticket. The latter however fail with an NPE as
a result of the above.

Given that DefaultLegacySupport is already marked Singleton, could the
static ThreadLocal be replaced with a final AtomicReference instance field?
This would be accessible across all threads, has less chance of leaking and
can still be updated in a thread-safe manner. Let me know if I should file
a JIRA issue for this.