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.
I'm not surprised we didn't see this before because I don't think it's among the test cases. To reproduce the problem, write a web application that ends up in an infinite loop. You can do this by writing a servlet that forwards to itself for example. When the server process the request, there is an awful lot of output written to the context log file. Because the logger window is so narrow (just a couple of rows), and because of the Swing performance, this window keeps updating forever. It doesn't stop after you stop the server. The other parts of the IDE are sort of functional, but the logger window never becomes usable again (not even when you restart the server) and it is not possible to close it while it's updating. The only way to get out of it is to exit the IDE and restart it. I think basically we have to work around this problem. It's not ideal, but I would suggest that in order to keep the feature working, it's fair enough that if the user stops the server, then the IDE stops displaying the logs. I've come across this a couple of times now. I think it would make sense to add this to the negative test cases that QA does with the IDE in general.
Does it mean that output window can't work if there is a huge amount of data? Then it is likely problem of this window and should be reassigned properly and solved on its side.
I am trying to reproduce this bug on Netbeans3.4 (Windows 2000). It seems that the behaviur is normal. It's true that the context log file reaches astronomic size-but it is the same in the standalone Tomcat. After a while, the process stops with exceptions in the browser.The output window grows in its size as well, but this doesn't cause the problem. Then when I executed another servlet - everything continues normally. The informational messages appear at the bottom of the context log output correctly. If the user stops the Tomcat Server(or closses the output window) - the thread that writes to the output window should be stopped as well. If problem persists, please reopen the bug and send me the test case.
Hi, after trying to reproduce it myself, I notice I only see it in some circumstances. I will attach a web module which reproduces it reliably for me. Start the web module (it two index.jsp so it's necessary to use the workaround to compile it) and allow the browser to try to download "/" for about ten seconds (or longer to worsen the problem) before stopping the server. The localhost__ log keeps updating for a very long time after the server has been stopped. Closing the tab does not help, it is immediately reopened. I clearly misreported the problem the first time around, and it is not the looping that's the problem but the log file getting very big.
Created attachment 7877 [details] gzipped tar of app which produces a big log file
Apologies, I should have added some more explanation. The reason I think it's a problem (and you can downgrade it if you disagree with the priority) is that the window continues to display the stuff as long as I try to execute the web module, and there is no way to stop it. If I depend on messages to the logger - because I have logging statements in my web app, not because I want to examine the interminable stacktrace - for the current debugging tasks, this means that I either have to wait for a very long time before I can restart the app and see the log file from afresh, or I have to stop and restart the server. Also, because the buffer size of the logger window itself is limited, even though the buffer scrolls down the huge log file, the messages I'm looking for are not there anyway, so it's not of any benefit to me that it attempts to go through the whole lot. So my preferred behaviour is that the logging window should stop displaying data as soon as I stop the server. However, I'd like to hear other people's opinions on this issue also. I'm CC'ing Jeff Hoffman because I guess that either way, it's a usability issue. As to Radim's question, I'm not entirely sure whether the problem is the window or not :) It's probably not reasonable for the output window to hold enormous buffers, but perhaps it's the output window that needs a mechanism such that it can be told to stop displaying. Ana
I managed to reproduce it with an attached examplke. The bug was fixed in trunk. The output thread is stopped after the Tomcat4.0 server is stopped. Attention! It can take IDE few seconds(3-10) to stop the output now.
The thread that writes to the output window is stopped now.However,if the log file is huge - the output window mechanism is emptying its buffer and this could take rather long time. My previous assesment (3-10 sec) could be exceeded. Yes there should be the mechanism how to stop writing to the output window from the buffer.
The previous estimate of 3-10 seconds is far exceeded. I attempted to verify this and it took over two minutes after stopping the server for the log window to stop display messages. Two minutes is too long in my opinion, so I'm reopening this bug.
I found the fix. Now waiting for approval from Petr Jiricka. The fix is based on cutting off the text from output window when the Tomcat log file grows in speed more then 1024x60 bytes per 2 seconds. I think - for the real applications it is no restriction.
Well, will limiting to 60000 characters help ? What will the time it takes to empty the buffer be ? Also, Jason, could you check what is the size of the Tomcat log file (in the <userdir>/tomcat406_base/logs directory), realistically ?
More clarification based on some measuring : In this particular example when the web module contains an infinite loop which writes a huge amount of data to the log file - the speed how the context log file grows is half Mbytes/2 seconds. This has an effect that the thread that writes the data to the output window doesn't keep up with this speed. It is not able to flush 1/2 Mbytes to the output window per 2 sec. The suggested fix just limits the amount of written data to 1024x60 bytes/2 seconds. It is no limitation for normal cases. The fix doesn't cut the log file as a whole. If the log file grows normally (less then 61440 chars/2 sec.) - it is being fully written to the output window. The fix is suitable for infinite loops that write repeatedly some log messages - mostly some exceptions. The fix was consulted with Petr Jiricka.
See the diff : http://web.netbeans.org/source/browse/tomcatint/tomcat40/src/org/netbeans/modules/tomcat/tomcat40/Tomcat40DataObject.java.diff?r1=1.48&r2=1.49
Verified with release 3.5.1. Took under 10 seconds to stop displaying messages after the Tomcat server was stopped.