This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When closing IDE user is falsely warned that run/debug processes are sill in progress. To reproduce: - create Java Web project with GlassFish 3.1.2.2 server - right-click project node and choose Run - wait until application is deployed and browser opened - try to close NetBeans main window but it opens the "Exit IDE" dialog informing that "Process - WebApplication1 (run)" will be terminated. This process should be already finished. - right-click project node and choose Debug - wait until application is deployed and browser opened - try to close NetBeans main window again and now you see two processes - run and debug Product Version: NetBeans IDE Dev (Build 201209020001) Java: 1.7.0_06; Java HotSpot(TM) 64-Bit Server VM 23.2-b09 System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)
I am also seeing this behaviour when deploying to GF and then exiting IDE. jstack says: Unable to open socket file: target process not responding or HotSpot VM not loaded
*** Bug 218491 has been marked as a duplicate of this bug. ***
This might be related: "pool-3-thread-1" prio=10 tid=0x00007f006c364000 nid=0x5455 in Object.wait() [0x00007f00aabf4000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000fe7fdca0> (a java.io.PipedInputStream) at java.io.PipedInputStream.awaitSpace(PipedInputStream.java:257) at java.io.PipedInputStream.receive(PipedInputStream.java:215) - locked <0x00000000fe7fdca0> (a java.io.PipedInputStream) at java.io.PipedOutputStream.write(PipedOutputStream.java:132) at org.glassfish.tools.ide.server.FetchLogLocal.call(FetchLogLocal.java:224) at org.glassfish.tools.ide.server.FetchLogLocal.call(FetchLogLocal.java:56) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) When IDE shows me there are N running task (usually run-deploy) in thread dump there is N*2 such threads. Does not seem to be ok.
*** Bug 218606 has been marked as a duplicate of this bug. ***
This should get fixed for Beta.
Glassfish Tooling SDK: ---------------------- changeset: 175:ff5a0848823a summary: Bug# 217734 - Allow to check if fetcher task is running.
NetBeans: --------- changeset: 233862:3c8a710fd24e summary: #217734 - Log fetcher tasks cached for every server instance.
Glassfish Tooling SDK: ---------------------- changeset: 176:382fead29e5c summary: Bug# 217734 - Fixed fetcher task termination process. NetBeans: --------- changeset: 233942:bb0bc72d610e summary: Bug# 217734 - Fixed fetcher task termination process.
Glassfish Tooling SDK: ---------------------- changeset: 177:9cb6ac689beb summary: Bug# 217734 - Better IOException handling on exit. changeset: 178:608607749ac1 summary: Bug# 217734 - Better IOException handling on exit. NetBeans: --------- changeset: 233943:634fbe7a8f0c summary: #217734 - Better IOException handling on exit.
I have to wait for Petr Hejl to test this because I can't reproduce it on my laptop.
Integrated into 'main-golden', will be available in build *201209210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/3c8a710fd24e User: Tomas Kraus <TomasKraus@netbeans.org> Log: #217734 - Log fetcher tasks cached for every server instance.
Still reproducible in Product Version: NetBeans IDE Dev (Build 201209210001) Java: 1.7.0_07; Java HotSpot(TM) 64-Bit Server VM 23.3-b01 System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)
Still reproducible. One change is that only one task is reported as running regardless of how many deploys I performed. Is that same for you Jirko?
Yes, only the first one is listed as running.
I went through the code, but I don't really understand the combination of original and current log support. So I can provide just couple of notes for Tomas to help with fixing. For me it looks like there are two competing things LogViewMgr and FetchLogXXX. When I start (run) the app for the first time the server starts up and the application is running. Logs are visible in the output window and there are LogViewMgr threads in the output window. No FetchLog thread. See the first thread dump. If I consequently execute deploy operation. The code gets to FetchLogLocal through CommandRunner and the FetchLogLocal spawns a new thread in the constructor (not really nice). See the second thread dump. The stop operation is not called on this thread when deploy is finished. On subsequent deploys I guess no more instaces of FetchLogLocal are created. So the state is that there is one non deamon thread (that from Executor in the constructor of FetchLogXXX) in the same ThreadGroup in which the first deploy operation was executed. Such ThreadGroup is considered to be alive and IDE reports there are running tasks.
Created attachment 124685 [details] the first threaddump
Created attachment 124686 [details] the second threaddump
Created attachment 124694 [details] sdk patch This would be a quick fix patch though I would rather see all the threads spawning in the GF plugin consolidated somehow.
GlassFish startup saves stderr and stdout of the process and that's why there are no FetchLog threads at the beginning. It's also source of that little competition between LogViewMgr and FetchLog. On the other hand when GlassFish had beed for some reason running before NetBeans were started, we won't get any sdtin and stderr and even the process handler. Just log file. That's why independent FetchLog is used later. I have plans to change this sdtin and stderr but we did not have time to make it in 7.3. I'll use your patch to get rid of this issue now. I'm just wondering why stop task was not called. It looks like there was no attempt to stop running GlassFish on NetBeans exit.
(In reply to comment #19) > I'll use your patch to get rid of this issue now. I'm just wondering why stop > task was not called. It looks like there was no attempt to stop running > GlassFish on NetBeans exit. As I said earlier GF is going to be stopped in shutdownHook at the moment JVM is exiting. Not when user is trying to close IDE - he may still change his mind due to unsaved files dialog or this running tasks dialog.
Created attachment 124702 [details] fixed patch There was missing runnable to be passed to thread.
GlassFish Tooling SDK: ---------------------- changeset: 179:217c67e1e137 summary: Bug# 217734 - Log fetcher thread marked as daemon, NetBeans: --------- changeset: 233957:af8890d5c00b Together with other changes in libs.glassfish.sdk library.
Could somebody fix it also in releases/release73_beta branch ?
I would like to wait for testing results.
This now works fine for me in build web-main#8630.
Verified in NetBeans IDE Dev (Build 201209220001). Please, transplant to beta branch.
(In reply to comment #26) > Verified in NetBeans IDE Dev (Build 201209220001). Please, transplant to beta > branch. SO, please integrate the fix also into releases/release73_beta branch ASAP. Thanks in advance.
Transplanted to beta: http://hg.netbeans.org/releases/rev/7199340c3876 http://hg.netbeans.org/releases/rev/acf8575e9b10 http://hg.netbeans.org/releases/rev/f2453023f15f http://hg.netbeans.org/releases/rev/edbad2c79c80