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.
Created attachment 125188 [details] Context menu screenshot NetBeans IDE 7.3 Beta (Build 201209272333) JDK 7u7 64-bit When first starting up the IDE, and selecting one of the two GlassFish servers that I have registered, the context menu has the wrong set of items enabled. Note in the screenshot that the server is not running but the start items are disabled. When right-clicking on it for a second time, the correct items are enabled.
I had to remove server status checks from netbeans startup because it was causing deadlocks. Now real server status is being checked with 1st GUI request and there is always risk that user is too fast. I'm trying to reproduce this in my own environment without a single success, context menu works correctly with first right-click for me. GlassFish status is being checked in Hk2InstanceNode constructor when it's being opened as a full node: public Hk2InstanceNode(final GlassfishInstance instance, boolean isFullNode) { this(instance, new InstanceContent(), isFullNode); if (isFullNode) { instance.getCommonSupport().refresh(); } } refresh() does asynchronous server state in separate thread and send notification to all listeners. But yes, this may not happen immediately. Also som individual context menu actions have their own checks, e.g. in StartServerAction ((CommonServerSupport) commonSupport).isReallyRunning()) is being called. Here isReallyRunning() is the same method that is being called inside instance.getCommonSupport().refresh() to check server status. In DebugAction and ProfileAction (start in debug or profile mode) those checks rely on stored server state without additional checks so it may take some time before this is updated from asynchronous refresh(). But simple "Start" menu item should depend on real server state. I'll try to improve server status check here.
Server status checks were rewritten from scratch to be a bit faster. Please can you try to reproduce this with last 7.3 build?
(In reply to comment #2) > Server status checks were rewritten from scratch to be a bit faster. Please can > you try to reproduce this with last 7.3 build? Will do, as soon as there is a build later than 20 Nov available. :)
(In reply to comment #2) > Server status checks were rewritten from scratch to be a bit faster. Please can > you try to reproduce this with last 7.3 build? This still happens sometimes with build 201211260002.
This should wait for next release (7.4) where I would like to rewrite server status checks from scratch.
New server status check code is already pushed into web-main. I also did some changes into context menu items visibility code but I still would like to do more. If you have time to play with last development build, you may try to check it now. There may still be some delay because server status monitoring needs some time to settle down.
I'm closing this bug. It's not possible to minimize this window to 0 even with background status checks (it need some 2-3 seconds to get first result). We can't do server status checks during startup, it will add delays to the process and introduce deadlocks in Keyring access. Current 7.4 code will check all servers after 1st user activity on them (trough project or Services:Servers. I can't tell you what will happen in next release. We may change status checking strategy back to 'on demand only'. There are some reasons to do that, but this will be decided later. So closing as won't fix, but I did the best I could.