Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 3.0-beta-1
-
Fix Version/s: 3.0-beta-2
-
Component/s: Embedding
-
Labels:None
-
Environment:Ubuntu Lucid, JDK 6u21
-
Complexity:Intermediate
-
Number of attachments :
Description
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.
Issue Links
- is depended upon by
-
MANTTASKS-213
<artifact:dependencies> spawns non-daemon thread
-
Please go ahead.