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.

Bug 215337 - Glassfish Exception logging is very slow and uses a lot of cpu
Summary: Glassfish Exception logging is very slow and uses a lot of cpu
Status: VERIFIED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: GlassFish (show other bugs)
Version: 7.2
Hardware: PC Windows 7
: P2 normal with 1 vote (vote)
Assignee: TomasKraus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-10 08:36 UTC by daedalus
Modified: 2013-01-11 10:21 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
netbeans profile export (272.79 KB, application/octet-stream)
2012-07-10 09:53 UTC, daedalus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description daedalus 2012-07-10 08:36:38 UTC
Hello, 

in our company we all have the problem that Netbeans is very slow if it displays the Stacktrace of an Exception in the Glassfish Log.

If an Exception occurs and the Stracktrace is printed by Netbeans in the best cases the Netbeans uses just a high amount of CPU during the printing.  

But in bad cases Netbeans prints the first lines of the Stacktrace and our application (running on Glassfish) freezes completely. 
During this time Netbeans has 100% CPU usage on one core of our CPU. Glassfish itself has 0% CPU usage during this time. Then after 1 or 2 minutes Netbeans prints the Stracktrace and the applications continues. 

If I kill the Netbeans process during this freeze then our application starts to immediately to respond

This behavior occurs with Netbeans 7.1, 7.1.2, 7.2 Beta and 7.2 RC1
Comment 1 daedalus 2012-07-10 09:53:34 UTC
Created attachment 121879 [details]
netbeans profile export

I profiled the IDE during a freeze caused by Stacktrace printing. It took several minutes but i was also building our application with maven.
Comment 2 Martin Entlicher 2012-07-10 12:21:02 UTC
This is a problem of a glassfish logger, which is searching class path to add hyper links.
Comment 3 daedalus 2012-09-14 09:37:11 UTC
Hello!

Is there any progress on this? I'm asking because this bugs gets more and more annoying for our complete company. Nearly every time an exception occurs Netbeans and so Glassfish and our application freezes for 3-5 minutes. This makes debugging very annoying. 

We would be happy with a solution that just allows us to turn this feature off. Hyperlinks in the log are nice but a responding application is way more important.
Comment 4 bht 2012-09-14 19:07:30 UTC
An idea for consideration:

The number of lines displayed in the view is limited, so could the hyperlinking be limited to that area? I have seen the delay mostly when many pages of log files were scrolling by VERY slowly.
Comment 5 TomasKraus 2012-09-17 13:13:59 UTC
Unfortunately I have to work on more serious bugs now. I'll keep this one in P2 but it has to wait a bit.
Comment 6 TomasKraus 2012-09-24 12:55:35 UTC
We will try to improve this before 7.3 release. We already did some investigation and we know cause of this issue.
Comment 7 daedalus 2012-09-26 07:46:17 UTC
Thank you very much! 

I think everyone in our company will be very happy if this problem is solved.
Comment 8 TomasKraus 2012-10-05 10:08:03 UTC
I implemented caching into org.netbeans.modules.glassfish.eecommon.api.LogHyperLinkSupport to avoid subsequent calls of
accessible = globalPathRegistry.findResource(path)
Which seems to be huge performace issue here.

Problem with this caching is, that I had not enough time to implement some cached records updates (e.g. removing corresponding records on global path registry changes).
Also current prefix tree code does not support string removal.

changeset:   235036:5d08cab4e854
summary:     #215337 - Added global path registry requests caching into LogHyperLinkSupport.

I'm pushing those changes into 7.3 to let you test it.
Comment 9 TomasKraus 2012-10-05 11:27:06 UTC
Please download 7.3 snapshot build from http://bertram2.netbeans.org:8080/job/web-main/8772/
and let me know if it works better now.
Comment 10 Quality Engineering 2012-10-06 02:02:04 UTC
Integrated into 'main-golden', will be available in build *201210060002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/5d08cab4e854
User: Tomas Kraus <TomasKraus@netbeans.org>
Log: #215337 - Added global path registry requests caching into LogHyperLinkSupport.
Comment 11 TomasKraus 2012-10-09 10:47:02 UTC
Please can you test last nightly build and let me know if it's better now?
Comment 12 TomasKraus 2012-10-15 14:09:25 UTC
Adding delete operation to prefix tree to allow cache items removal on the fly.

Pushed into GlassFish Tooling SDK:
----------------------------------
changeset:   283:c2d983034575
summary:     Bug# 215337 - Prefix tree delete operation added.
Comment 13 Petr Hejl 2012-10-15 14:35:22 UTC
(In reply to comment #12)
> Adding delete operation to prefix tree to allow cache items removal on the fly.
> 
> Pushed into GlassFish Tooling SDK:
> ----------------------------------
> changeset:   283:c2d983034575
> summary:     Bug# 215337 - Prefix tree delete operation added.

BTW toCharacter() method introduced seems to be creating new instance for every char - use Character.valueOf() instead.
Comment 14 TomasKraus 2012-10-15 23:30:24 UTC
Well, let me know how to use char as a key in collections and I will remove Character instances. But I do agree that it's slow.

I would like to replace Java default TreeMap with something better (AVL tree) in the future and char key will be simply part of tree node object.
But there is not enough time to play with this now.
Comment 15 Petr Hejl 2012-10-16 08:45:34 UTC
(In reply to comment #14)
> Well, let me know how to use char as a key in collections and I will remove
> Character instances. But I do agree that it's slow.

It's not about key replacement. It's about reduced number of instances in the code (and actually in the VM). As I wrote instead of "new Character()" use "Character.valueOf()" that will reduce number of instances a lot.
Comment 16 TomasKraus 2012-10-16 09:24:09 UTC
Ok, I got it. :)

changeset:   284:a6fd2d7fbdce
summary:     Bug# 215337 - new Character() replaced with Character.valueOf()
Comment 17 TomasKraus 2012-10-17 13:00:30 UTC
GlassFish Tooling SDK:
----------------------
changeset:   298:da272b5637ff
summary:     Bug# 215337 - Added non recursive clear() method into StringPrefixTree

Unfortunately I can't do caching the way I was planning. Cache should be cleaned up with every single GlobalPathRegistry content change.
So here is one fast clear() method for prefix tree.

I'll put it into GlobalPathRegistryListener in LogHyperLinkSupport to clean cache with every single change event.
We still believe that it would improve performance a bit.
Comment 18 TomasKraus 2012-10-17 15:04:07 UTC
NetBeans web-main:
------------------

changeset:   236089:acb72fd8e85d
summary:     #215337 - Global path registry requests cache should be cleaned 
             with every GlobalPathRegi

changeset:   236312:75992226bf71
summary:     #215337 - Unused code removal

changeset:   236313:c9316261b1e9
summary:     #215337 - code cleanup

There is nothing to be tested by QA.

Please let me know if performance of stack trace processing is better now.
Comment 19 Quality Engineering 2012-10-18 02:02:49 UTC
Integrated into 'main-golden', will be available in build *201210180002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/acb72fd8e85d
User: Tomas Kraus <TomasKraus@netbeans.org>
Log: #215337 - Global path registry requests cache should be cleaned with every GlobalPathRegistry content change