[
http://jira.codehaus.org/browse/MEXEC-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89460
]
Milos Kleint commented on MEXEC-20:
-----------------------------------
AFAIK there isn't a way to figure that out from the plugin. not sure there
should be.
yup. there should be some docs, but so far it's a moving target generally and I
keep figuring out things that are bad for embedding on the run...
1. use of System.getProperty() in plugins or non-forked threads are bad. (both
get and set)
2. Runtime's shutdownhooks are problematic.
3. setting a context classloader is bad.
4. assuming a working directory (by constructing java.io.File with relative
path) is also troublesome.
5. static memory caches are problem but mostly for components, plugins are ok
there.
regarding threading:
point 1 (joining of threads) is generally fine.
cleaning up threads (2+3) should be done carefully not to shoot down unrelated
codebase or completely shutdown the environment.
at least NetBeans that I use as environment should have guards against stuff
like System.exit() calls etc. At the same time it has it's own ways of killing
a group of threads. So it can basically do 2+3 for you I assume
Handling Runtime's processes also should be considered. If a thread is waiting
for Runtime's process to finish and gets killed itself, it should at least
attempt to shoot down it's process as well. (By catching ThreadDeath or
something like that)
There could be more, i'm not really frequent in this area..
> 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
