[
http://jira.codehaus.org/browse/MEXEC-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89672
]
Jerome Lacoste commented on MEXEC-20:
-------------------------------------
Putting more thoughts into this, the main thing is to allow one to either
disable or enable this extra thread management and decide if it should be
enabled by default or not.
It is particularly required for safety when maven runs in embedded environment
(to avoid dangling threads).
But keeping it render the java plugin slightly different from what the java
command line class does.
I am now starting to lean on the second option, that is to let this extra
thread management by default, and allow a switch to disable it.
As long as it is well documented I think it will serve better the users: people
that should be affected by extra-thread management should be few, while having
dangling threads in your VM could be more problematic.
Comments ?
> rethink the default thread management
> -------------------------------------
>
> Key: MEXEC-20
> URL: http://jira.codehaus.org/browse/MEXEC-20
> Project: Mojo Exec Plugin
> Issue Type: Improvement
> Affects Versions: 1.1
> Reporter: Jerome Lacoste
> Priority: Blocker
>
> Before 1.1 is released I want us to make a proper handling of threads in
> java:exec.
> Today the plugin does the following:
> 1- join non daemon threads
> 2- interrupt remaining threads
> 3- stop() all threads in group
> 1 is OK as that's the condition used by the VM for detecting when to stop().
> But I don't think we should enable 2 and 3 by default, because they don't
> represent what the VM does.
> The whole idea of cleaning up threads after running is because we are running
> the command in the same VM as maven and we don't want these unfinished
> threads to keep running. Thus we're forced to do things that are abnormal
> compared to normal execution.
> So what could we do ?
> I believe that the plugin is mostly used on the command line. In that case,
> not cleaning up is less of a problem.
> One proposed solution is to not perform point 2 and 3 by default and force
> the user to enable a flag to kill those threads.
> Any better idea ?
> See MEXEC-18 and MEXEC-6 for historic and discussions of the original
> implementation of the thread management in 1.1
--
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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
