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 you invoke View Server Log on a server node in Runtime tab, Output window is populated with the contents of the log. Populating the window is slow, especially with the first invocation when you can almost count the lines as they are being printed out.
This is wierd: not for me: i can see the entire content pretty fast... Can you describe more your system? Can you reproduce this on another system?
> Can you describe more your system? Linux FC2, notebook Dell Latitude C840, 2GHz PIV, 1GB RAM. The profiler shows that the top hotspot is NbWriter.println(). Perhaps non-buffered stream? > Can you reproduce this on another system? My other machine (W2K desktop) fails to show the log with an error message about bad path to the log.
I'll try on a linux system and will check for buffered streams. Thanks.
Created attachment 18871 [details] Hotspots as listed in optimizeit
bad path error should be fixed now, so can you get the same date for windows XP? Seems to be a linux issue I think with JDK
Yes, I don't see the issue on Windows (W2K). View Server Log action finishes almost instantly there.
We are now truncating the log file to view only 10 000 max lines... Does this improve the issue for long files?
moving to core for further analysis. Why output2.NbWriter.println would take so long only on linux systems?
where can I check the sources for LogViewerSupport?
a few general thoughts. the output window apis are primarily focusing on the usecase where the output is continually growing. That's what the Ui component also takes into account, scrolling to the end of output all the time etc. your usecase where you dump the whole log file at once into the output is at least non-optimal use of the apis and one cannot expect a top performance there. Ideally the log file should be passed to the output window in one chunk. Now you are actually copying the log file into another file, line-by-line and through the UI. That *has* to be slow..
I'll send it to you. For now it is close source.
1/ we are doing only tha last n lines so that the user has some context: usally, when there are errors in the log, this is what the user expects. (outside the IDE, the user would do a tail-f ) 2/ on Windows XP, it is very very fast. So the issue is either in Linux window manager or ui threading.
in order to speed up the processing, we would need to enhance the current API to include the usecase from enhancement #55151. That cannot be done in 4.1 timeframe though. I cannot see any other solution to fix the problem. You could try not to trim the output to fixed size. Given that the output UI component always scrolls to the end, the user should be able to see the relevant portion of the log.
If you wanted to open up the API for this, cleanest might be to allow a client to supply their own pre- populated implementation of Storage, or the file itself that should be displayed (note the output window expects UTF-16 - for throughput reasons, that's what its memory mapped buffer is). Note if text wrapping is turned on, there will be some inevitable delay as wrap points are calculated.
I have added some basic implementation of the direct log file viewing. it's in core/output2 on branch ISSUE_51188. I added a IOProvider.showLogFile(String name, File logFile) method, the implementation will memory map the log file itself without any copying. There are 3 drawbacks to the current implementation now: 1. just UTF-16 supported as the log file's encoding. To support something else, we will probably have to copy+encode the original log file into a different one. 2. the log file is assumed to grow only. Shrinking /deleting of the file is not handled yet. TBD. 3. No hyperlinks in the text possible. As we avoid the println() calls on the InputOutput instance, there's no way of adding hyperlinks. IMHO this is unfixable and if hyperlinks are required we need to go some other way. I've tried on a 40 MB file and the performance was acceptable (given the size of the file)
Too late for NB5.0, please reevaluate.
I am experiencing the same symptoms on windows XP (2GB RAM, 2.8 HT PENT) / JDK1.4.2_10 running JBoss 4.0.3.
I am experiencing the same symptoms on windows XP (2GB RAM, 2.8 HT PENT) / JDK1.4.2_10 running JBoss 4.0.3. I see this when I am running multiple JBoss Appservers. My development environment requires that I run 2 servers and the output is very slow from the Appserver I use as the Servlet / jsp server.
One simple suggestion: From the profiler data, it looks like you're populating the output component from the AWT thread. The IO APIs are designed to be thread-safe, and if it's a large log file, the AWT thread is probably the wrong place to make this call. What's happening in println, IIRC, is that the code is searching for newlines in the text passed to it and calling itself back with individual lines. That might not be terribly efficiently implemented - when I wrote it, I was expecting maybe a few hundred characters of text to be the common use case for that call, not a giant log file.
Created attachment 32601 [details] sample module that tries to demonstrate teh problem
attached is a sample application that simulates what your module does. 1. print 15000 lines in a loop, count the time it took, 2. reset the output 3. print 15000 lines in look again, again mark how long it took. both times are comparable for me and reasobaly fast. so my assumption is that the problem lies in the application server module - closing as wontfix. please reopen with the sample app changed to demonstrate the problem. tboudreau: the awt stuf fin teh profiles picture is probably the output window scrolling down and showing new lines.. hatleye: please file a separate issue agains the jboss support.