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
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
Comment 2Antonin Nebuzelsky
2004-11-12 16:10:17 UTC
> 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.
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..
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
Comment 17Marian Mirilovic
2006-01-03 10:53:52 UTC
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.
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
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.