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 deploy application on Glassfish V3, each item that is displayed on Netbeans takes almost a second to display. This making Netbeans 6.8, and 6.9 (RC1, RC2) not practical to development software on glassfish (especially with project that has many EJBs, and require hibernate logging). When I disabled Logging Glassfish V3 admin >> Configuration >> Logger Setting >> javax.enterprise.system.container.ejb or change the level from INFO to WARNING, the application can be deployed about 7 times faster. For example. 17,xxx ms to 2337ms 8 mins to 1 min When I started Glassfish V3 outside netbeans 6.8 and 6.9 (RC1 and RC2), the deployment is yielding the same result as disable the logging. Many other people also face the same problem, you can see it at http://forums.netbeans.org/topic22511.html. This is really critical issue for practical software development on Glassfish V3 by netbeans 6.8, and 6.9. I hope it can get resolve soon for the full release of version 6.9.
switching to server plugins. vince, can you take a look?
(In reply to comment #1) > switching to server plugins. vince, can you take a look? John.. could you advise me on how to switch to Glassfish V3 server plugin please? I can only find that there is server plugin for Eclipse only. I could not find one for Netbeans. I can't find one under Netbeans >> Tools >> Plugins too. Thanks you very much in advance John
It's included in standard builds in 6.8 and 6.9. no special UI for it. GFv3 is included in the Java and All distributions, should be registered by default (just create a JavaEE project to activate JavaEE functionality). Or you can point the IDE to any existing GFv3 installation on your machine by right-clicking Servers in the Services window and choosing Add Server. HTH.
this looks like it is related to bug 180801 and bug 186806... Both of those issues are filed against windows... Have you seen this on a different OS?
Can you share a sample app that demonstrates the issue?
I have a fix for bug 180801... which appears to be related to this issue. The fix should appear in a nightly build of 'post NB 6.9' in the next couple of days. I will update this issue when the fix is available for download from NetBeans.org.
You can get a zip distro of NB (not an installer) that has the fix in it from here: http://bertram.netbeans.org/hudson/job/web-main/3338/ An installable version will take a bit more time to generate Please let me know if this is effectively resolves your issue.
The proposed fix is the nightly dev build... available from http://bits.netbeans.org/dev/nightly/ this build also has an installer. Please let me know whether the fix addresses the issue or not...
I think the fix is http://netbeans.org/bugzilla/show_bug.cgi?id=180801#c12... but I do not know, since I have not seen the really bad behavior that folks have described. teerakorn@netbeans.org: Please download the latest dev build of 'post NB 6.9' to verify whether the change has had a positive effect in your environment.
I tested the nightly dev build with installer on Windows 7 environment. Now logging of the glassfish V3 is much faster than before. This speeds up Glassfish V3 startup and application deployment time a lots. ### Logging Statistics (Starting Glassfish V3 with Netbeans) #Without this fix: App Deployment time is 225,868ms Glassfish V3 startup: 4174ms #With this fix: App Deployment time is 43,688ms Glassfish V3 startup: 2785ms ### Logging statistics (Starting Glassfish V3 from command line) ### #With this fix: App Deployment time is 29765 ms Glassfish V3 startup: 2475ms Note: tested project has about 270 EJBs with 200+ entity beans with hibernate One observation is that the application deployment time on Netbeans is almost 50% slower if starting Glassfish V3 with netbeans, than starting the server from command line. I also saw that the fix was to adjust the logging delay. So I am wandering whether this delay could be made configurable in a Netbeans config file?
Vince and QE - are we seeing the same slow-down for GF on Windows 7? teerakorn - how many modules/projects is the app split into? Is it 200+ EJB modules inside an EAR or are they grouped into just a couple of projects?
I think Vince already fixed this bug for Netbeans 6.9 on Windows. Even though, I only test the fix on Windows 7. Thanks you very much :) The tested application contains four EJB modules, and one Web Module 1) The first one contains about 200 EJBs 2) The second one contains 15 EJBs 3) The third one contains 5 EJBs 4) The fourth one contains 10 EJBs 5) Web application module They are all deployed within an EAR. Note: 1) From my tests, the time to deployed each module separately is about the same as deployment them in EAR. 2) I also found that Netbeans 6.8 on Windows (XP and 7) also has the same logging delay problem on Glassfish V3. With GF V2, there is no logging delay problem. I am not sure whether there will be a fix for people who still using Netbeans 6.8. But I want to inform the team.
Yes but even with the bug you're showing deployment taking twice as long in NB as on command-line. That's what I want to investigate.
(In reply to comment #10) > I tested the nightly dev build with installer on Windows 7 environment. > Now logging of the glassfish V3 is much faster than before. This speeds up > Glassfish V3 startup and application deployment time a lots. > > [snip] > > One observation is that the application deployment time on Netbeans is almost > 50% slower if starting Glassfish V3 with netbeans, than starting the server > from command line. > > I also saw that the fix was to adjust the logging delay. > > So I am wandering whether this delay could be made configurable in a Netbeans > config file? We could probably do that for the next major feature release... I would not want to do that as part of 6.9.1...
(In reply to comment #11) > Vince and QE - are we seeing the same slow-down for GF on Windows 7? > > teerakorn - how many modules/projects is the app split into? Is it 200+ EJB > modules inside an EAR or are they grouped into just a couple of projects? I do not have access to a Windows 7 environment. Folks have reported this delay on XP and Vista, but the reports have not contained enough info to act on. I have a Vista laptop that I can use for testing... but hg stopped working, so I cannot really use it as a build machine.
(In reply to comment #12) > I think Vince already fixed this bug for Netbeans 6.9 on Windows. Even though, > I only test the fix on Windows 7. Thanks you very much :) The fix is NOT in 6.9 at the moment. Now that you have verified that the patch is effective, we can probably put the change into the code that will get released as 6.9.1. > >[snip] > 2) I also found that Netbeans 6.8 on Windows (XP and 7) also has the same > logging delay problem on Glassfish V3. With GF V2, there is no logging delay > problem. I am not sure whether there will be a fix for people who still using > Netbeans 6.8. No. I cannot imagine that we would create a patch for 6.8. >But I want to inform the team.
(In reply to comment #13) > Yes but even with the bug you're showing deployment taking twice as long in NB > as on command-line. That's what I want to investigate. We should probably open a second issue for that. The priority of that issue is lower than the priority of the issue as originally opened.
(In reply to comment #17) > (In reply to comment #13) > > Yes but even with the bug you're showing deployment taking twice as long in NB > > as on command-line. That's what I want to investigate. > > We should probably open a second issue for that. The priority of that issue is > lower than the priority of the issue as originally opened. Do you think lowing the delay to be lesser than 100ms would help in optimizing logging time further difference between starting GF V3 by netbeans and command-line? http://hg.netbeans.org/main/rev/83257b9eab3b
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #13) > > > Yes but even with the bug you're showing deployment taking twice as long in NB > > > as on command-line. That's what I want to investigate. > > > > We should probably open a second issue for that. The priority of that issue is > > lower than the priority of the issue as originally opened. > > Do you think lowing the delay to be lesser than 100ms would help in optimizing > logging time further difference between starting GF V3 by netbeans and > command-line? > It is possible.... the change to the DELAY is really not the 'right fix' for this issue... it is a patch. A real fix needs to address why the delay was having an effect at all... since it should not have been a factor. That investigation is going to take a fair bit of time. I want to address the worst part of the situation first and then start doing the real work associated with developing a fix.
BTW perhaps the extexecution api could help http://bits.nbextras.org/download/6.8/fcs/javadoc/org-netbeans-modules-extexecution/. I can't guarantee it will really help (there is lot of issues with running external process in java), but there were lot of issues solved in this API. Perhaps some prototyping could tell you more - unfortunately I don't have time to do it on my own.
PHejl: Thanks for the pointer. I will take a look at it soon. I need to get my hg under Windows issues resolved first. (Since I cannot do a pull or clone, working on this issue as been pretty slow)
This patch addresses the worst part of the issue and should get integrated into 6.9.1 > Integrated into 'main-golden', will be available in build *201006090001* on > http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) > Changeset: http://hg.netbeans.org/main/rev/83257b9eab3b > User: vince kraemer <vkraemer@netbeans.org> > Log: #180801: DELAY slows server on Windows... a patch. I am going to open a p2 issue to track the remaining slow-down issues reported in http://netbeans.org/bugzilla/show_bug.cgi?id=187198#c10
Bug 187741 is the subissue
Please verify bugfix for this bug, so it can be integrated into release691 repository. Thanks, -R
(In reply to comment #24) > Please verify bugfix for this bug, so it can be integrated into release691 > repository. > > Thanks, > -R I think this comment satisfies the verification requirement... http://netbeans.org/bugzilla/show_bug.cgi?id=187198#c10
What is the real changeset for *THIS* issue? It looks like this is a sort of a duplicate of issue 180801 and sub issue 187741 has be created. In other words to backport fix for this issue, I should port fix for issue 180801, while this issue 187198 has been set VERIFIED-FIXED without real changeset related to this issue and remaining problems have been out-reported into issue 187741. Having that said, this issue itself does not qualify for porting into release691 repository. If you want a fix for this issue in that repository, consider marking issue 180801 with keyword 6.9.1_CANDIDATE and *VERIFY* that issue. Removing the 6.9.1_CANDIDATE keyword from this issue due to failure to meet qualification criteria (missing changeset for porting).
*** This bug has been marked as a duplicate of bug 180801 ***