DefaultArtifactResolver forks non-daemon threads
------------------------------------------------
Key: MNG-4738
URL: http://jira.codehaus.org/browse/MNG-4738
Project: Maven 2 & 3
Issue Type: Bug
Components: Embedding
Affects Versions: 3.0-beta-1
Environment: Ubuntu Lucid, JDK 6u21
Reporter: Jesse Glick
Priority: Minor
I am working on embedding Maven 3 (beta 1). I ran into a problem with Maven
execution hanging at the end.
When we run a "process" in-VM, we try to emulate a forked Java as much as is
reasonable. A new thread group is created, whatever work needs to be done is
done from a new thread in that group, and then we wait for the "process" to end
by checking that all non-daemon threads in the group have exited.
In the case of Maven execution, typically DefaultArtifactResolver is called at
some point. By default, this creates a ThreadPoolExecutor with 5 non-daemon
threads in it (which are created inside the thread group of the caller).
Although all tasks are certainly completed by the end of the Maven run, these 5
threads remain alive, and so the thread group cannot be considered dead.
It seems to me that DefaultArtifactResolver is at fault here. It should not be
spawning non-daemon threads. Although it shuts down the executor upon being
finalized, there is no guarantee of this happening in a timely manner.
Since the tasks being run in the threads are only active within the dynamic
scope of calls to resolve, it should be safe to mark the executor threads as
daemon. I would be happy to supply a patch incl. test case if you agree with
the premise.
The workaround is to set maven.artifact.threads=1 before starting Maven
execution, so that no threads need be spawned at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
