[
http://jira.codehaus.org/browse/MEXEC-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89216
]
David Smiley commented on MEXEC-20:
-----------------------------------
(Note: you didn't mention step 2.5 which is to join on the interrupted threads)
It is true that if there are no other things that Maven is going to do
following java:exec before the VM shuts down, then there's no need to interrupt
nor stop daemon threads (#2, #3). I'd guess this is the typical case.
It would be nice if the plugin could know wether Maven is going to go off and
do other things 'cause then we could have different defaults depending on the
context. But this isn't a big deal.
I'm in support of not doing #2, nor #3 by default if you think that's best,
Jerome. If it were my decision alone, I would by default interrupt the daemon
threads, but not join on them. Its harmless, particularly if you don't join on
them.
No matter what the outcome of this issue, it should be well documented.
> 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
