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.
I think it's too much to have 2 nbexec.exe, java.exe and netbeans.exe for one started IDE. Killing netbeans.exe does not close the main window etc.
For this is unusual and I do not know how this can happen I want to ask you for more information. A thread dump of both IDEs can help us. You can use jps + jstack if you run on JDK6 to get these.
What do you mean by "both IDEs"? Just start NB 5.0 and look at the task manager.
Ideally there should be only netbeans.exe
really there are 4 processes. OTOH what's the problem? two instances of nbexec.exe seems to be strange. the rest is more an enhancement to load these things as a DLLs into one process.
The problems are: - killing netbeans.exe does not close the main window and you have to kill other three processes - netbeans.exe does not consume CPU time but java.exe does and it is not possible to define whether it is NetBeans or another Java application
re killing netbeans.exe: maybe this can be fixed re java.exe: surely there are tools that will tell you more about running processes. unfortunately this platform does ship with reasonable set of tools :-(. OK if we change the launcher to link with java.dll this will solve the problem.
Now I see why there are two instances of nbexec.exe: netbeans.exe (or nb.exe) start nbexec.exe with some set of params. nbexec.exe checks at the begining if the mode is runnormal or runupdater and if it is not it starts nbexec.exe with aditional params to set this mode.
This is even more strange for RCP-based applications. You get your app.exe and two instances of nbexec.exe running (and java.exe of course). This is not very friendly for non-developers to guide them through their process list, just in case something bad is happening.
We plan to solve this issue in NB 7.0. We plan to move nbexec functionality to dll and run netbeans in single process.
Created attachment 75107 [details] patch
please see http://wiki.netbeans.org/WinNB7Launcher for details
[JG01] If java.exe is no longer a separate process, how does AU restart the IDE to install updates? Is it guaranteed that file locks acquired by Java code are released when the JVM exits, even though the process does not exit? How do we install updates to the o.n.bootstrap pseudomodule which contains the launchers themselves? [JG02] "--sproc" is not a very intuitive option name.
> [JG01] I would expect that all resources are released when JVM exit. However, bigger problem is that NB calls System.exit() on exit which terminates whole process and control is not returned to launcher as I expected. So I was forced to change it to create new process on NB restart. > [JG02] I changed --sproc to --javaprocess. Feel free to choose better name if you wish.
Created attachment 75196 [details] updated diff
To JG02: --fork-java seems clearest to me.
t_h I may be missing something where you talked about System.exit, but the JVM shared library will not allow you to release it and reload it unless this has been fixed in recent years. It has always had a bug where two instances can never be created in the same process, but again, maybe that is fixed now. I haven't tried that in years as it had been an issue. Most OS and C environments have hooks for the messages a given process will be given. You should be able to setup a hook for when the process is shutting down. Now, if you can't capture a system message or install a native hook into the process using which ever tools and runtime you're using, another solution is to create a new Java package to use native methods which is only used by the launcher. Essentially what you will do is use: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#getRuntime() http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread) and thus from the native code, instantiate an instance of what ever class you have created for the shutdown hook, then inside that class, it uses native methods to do what ever you need to do to setup to run the application again, and I guess if you can get that work done from plain old Java classes then you wouldn't even need any other native logic from that point of view. Either way, the Java classes being specific to the launcher, can be added to the classes by the launcher automatically when launching the JVM, so none of the rest of NB will be affected by them. That will allow it to work as now on restart. That of course is the JVM shared libraries still can not be reloaded. Last I heard that wasn't a priority.
>[JG02] OK. > wadechandler Maybe it was not clear from my message: Original intention was to restart JVM within single process without creating new one (on NB restart). Because it is not possible (due to System.exit() and maybe it would not be possible even without System.exit() because of the issue you mentioned) new process is created on restart (and old one is finished).
core-main #8dd0fe0d2bd1
Integrated into 'main-golden', will be available in build *200901070201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8dd0fe0d2bd1 User: Tomas Holy <t_h@netbeans.org> Log: #85228: new launchers for windows
Integrated into 'main-golden', will be available in build *200901170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/eff88627be15 User: Richard Michalsky <rmichalsky@netbeans.org> Log: #85228: missing lib/nbexec.dll caused suite JNLP build to fail
ok