Bug 34498 - Don't use additional thread for external processes.
Don't use additional thread for external processes.
Status: RESOLVED INVALID
Product: platform
Classification: Unclassified
Component: Execution
3.x
PC Windows ME/2000
: P3 (vote)
: 6.x
Assigned To: Jesse Glick
issues@platform
: THREAD
: 36577 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-19 17:17 UTC by hlavac
Modified: 2010-05-04 23:27 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
ide.log (90.54 KB, text/plain)
2003-06-19 17:18 UTC, hlavac
Details
ide.log (219.04 KB, text/plain)
2003-09-18 21:55 UTC, hlavac
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hlavac 2003-06-19 17:17:26 UTC
I killed running integrated Tomcat using Process list 
window and got this java.lang.IllegalMonitorStateException
Comment 1 hlavac 2003-06-19 17:18:03 UTC
Created attachment 10743 [details]
ide.log
Comment 2 David Konecny 2003-06-23 13:17:32 UTC
Petr, could I ask you for your advice about what could be wrong here? 
Comment 3 Petr Nejedly 2003-06-24 15:12:35 UTC
OK, this is very ugly one and it seems it shouldn't happen, but I
think I've found how it can occur:
IIRC, we're using Thread.stop() to kill some internal things,
probably also for stopping internal tomcat (Jirka?)

The IMSE can occur if you do monitorexit on already unlocked monitor.
The bytecodes for the method are:
...
21 monitorenter
...
95 monitorexit
96 ireturn
...
144 monitorexit 
Ex table:
from:22 to:96 use:141 type:any

That means:
if the method just executed the bytecode 95 (i.e. unlocked the
monitor) and the Thrad.stop() is called on it exactly at that time,
the ThreadDeathError exception is invoked in that thread and the
control is forwarded to offset 141, where it tries to unlock the same
monitor again.

Now, this is my hypothesis based on assumption that we're using
Thread.stop() and that bytecode execution can really be interrupted
between those two bytecodes.
If this is the real thing happening inside VM, this exception should
be very rare and also innocent (just kills the thread that was going
to be killed anyway).
If the problem is reproducible (or not that rare), please note it.

I'll try to ask JDK/VM team for more details, but using of
Thread.stop() is strongly discouraged and deprecated for a long time
already ...
Comment 4 David Konecny 2003-06-24 15:30:00 UTC
Thanx very much Petr!

The same exception was reported in issue 31682 which I closed as
worksforme, because I was not able to reproduce it.

I also tend to think that this exception should be harmless. Do you
think I should catch it and log it just as INFORMATIONAL warning?
Because otherwise I do not see much else I could do here.
Comment 5 hlavac 2003-09-18 21:55:54 UTC
Created attachment 11665 [details]
ide.log
Comment 6 hlavac 2003-09-18 21:56:59 UTC
Sorry, wrong issue - ignore C:\projects\kuk\ide.log
Comment 7 Petr Jiricka 2003-09-19 08:05:21 UTC
Sorry for a late reply to Petr N's question - I overlooked this.

Well, I think Thread.stop() is used internally by the execution
framework (method org.netbeans.core.execution.DefaultSysProcess.stop()
calls ThreadGroup.stop()), but I don't see why it should really be
needed to stop Tomcat. Tomcat only needs to kill the external Tomcat
process, and then the threads which copy the standard output of the
external process to the IDE's output window. But I don't think we need
to use Thread.stop() for this. 

So I think the question is whether we can rearchitect the internals of
the execution framework in such a way that it does not use a thread
that is then stop()-ed. I don't understand why the internal thread is
there - can you enlighten me please? Thanks.
Comment 8 Petr Nejedly 2003-09-19 12:16:14 UTC
I don't understand much of the execution framework but I have noticed
too many threads as well:
1. The ThreadExecutor which waits for ThreadGroup to finish
  2. The ProcessExecutor which spawns the external process and waits
    for the result
  3.-5. CopyMaker threads which forward stdin/stdout/stderr between
    the process and IO window
6. JDK's process reaper thread (only one per running JVM?)

(1) is IMO not really needed.
I hope (3)-(5) can be merged using nio on JDK1.4
 
Comment 9 David Konecny 2003-09-22 13:51:36 UTC
"...too many threads..." -> adding Jesse to CC:
Comment 10 Jesse Glick 2003-09-23 17:07:25 UTC
You do need Thread.stop() for some cases, e.g. when using internal
execution and it just keeps on going and you wish to kill it. For
stopping an external process, or for well-behaved internal processes,
it should not be necessary. We could probably clean up the engine to
only use T.s() when actually necessary. ExecutorTask already has a
stop() method which IMHO is all the engine should need to call -
ThreadExecutor should implement this with Thread.stop().
Comment 11 David Konecny 2003-10-15 11:48:13 UTC
*** Issue 36577 has been marked as a duplicate of this issue. ***
Comment 12 Marian Mirilovic 2004-01-14 15:24:44 UTC
changing owner dkonecny -> pnejedly
Comment 13 Petr Nejedly 2004-01-15 16:57:29 UTC
OK, I've worked around the exception (which could occur for internal
execution even if we improve the framework).
The rest is a RFE about threading in execution framework.
Comment 14 Antonin Nebuzelsky 2008-02-19 14:00:00 UTC
Reassigning to new module owner Tomas Holy.
Comment 15 Jesse Glick 2010-05-04 23:27:05 UTC
Probably long obsolete.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo