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 179199 - NetBeans server log output locks up Tomcat
Summary: NetBeans server log output locks up Tomcat
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Tomcat (show other bugs)
Version: 6.x
Hardware: PC Other
: P3 normal with 2 votes (vote)
Assignee: Petr Hejl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-04 10:39 UTC by rptmaestro
Modified: 2011-04-26 09:04 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Screenshot of mixed logging in Tomcat 5.5 (149.70 KB, image/jpeg)
2010-01-04 10:39 UTC, rptmaestro
Details
Tomcat 5.5 Thread dump (43.26 KB, text/plain)
2010-01-04 10:39 UTC, rptmaestro
Details
NetBeans 6.8 Thread dump (13.43 KB, text/plain)
2010-01-04 10:40 UTC, rptmaestro
Details
Thread dump during application undeploy (56.89 KB, text/plain)
2010-01-04 10:59 UTC, rptmaestro
Details
NetBeans Thread dump during application undeployment (17.97 KB, text/plain)
2010-01-04 11:01 UTC, rptmaestro
Details
server lockup during shudown via netbeans (58.56 KB, text/plain)
2010-01-04 11:03 UTC, rptmaestro
Details
netbeans thread dump during server shutdown (21.48 KB, text/plain)
2010-01-04 11:06 UTC, rptmaestro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rptmaestro 2010-01-04 10:39:16 UTC
Created attachment 93052 [details]
Screenshot of mixed logging in Tomcat 5.5

I have a maven web application that deploys to a Tomcat 5.5 server. At least a few times a day, when I get an exception in my web application, the tomcat server stops responding and never returns a response to the browser. When this happens, I invariably see my stack trace mixed up with other logging in the "Tomcat 5.5" output window. This seems to always happen when there is a combination of exception (red-formatted) logging and other (black-formatted) logging. The logging appears in the the "Tomcat 5.5" output window in alternating lines of red (for the exception stack trace) and black (for the other logging) (See screenshot)

The attached thread dump of Tomcat 5.5 shows that the logging output stream is locked in thread "http-8080-Processor23". The attached thread dump of NetBeans shows that the input stream is locked in the thread "Tomcat 5.5 ServerLog - Thread". Whether this latter thread state is normal, I am unsure, but the Tomcat 5.5 server request thread ("http-8080-Processor23") remains locked indefinitely and never completes.

Occasionally, Tomcat stops responding entirely and won't complete any more requests and won't even shut down normally so that I have to kill it via the operating system.

Other members of my team that use the Eclipse IDE never encounter this problem with the same project, but I encounter it a few times a day. Moreover, it doesn't happen if Tomcat 5.5 is running outside of the IDE either (for example, from the console)
Comment 1 rptmaestro 2010-01-04 10:39:58 UTC
Created attachment 93053 [details]
Tomcat 5.5 Thread dump
Comment 2 rptmaestro 2010-01-04 10:40:36 UTC
Created attachment 93054 [details]
NetBeans 6.8 Thread dump
Comment 3 rptmaestro 2010-01-04 10:59:19 UTC
Created attachment 93055 [details]
Thread dump during application undeploy

This thread dump was taken after the Tomcat 5.5 server stopped responding to requests and I attempted to have NetBeans undeploy the application.
Comment 4 rptmaestro 2010-01-04 11:01:14 UTC
Created attachment 93056 [details]
NetBeans Thread dump during application undeployment
Comment 5 rptmaestro 2010-01-04 11:03:51 UTC
Created attachment 93057 [details]
server lockup during shudown via netbeans
Comment 6 rptmaestro 2010-01-04 11:06:31 UTC
Created attachment 93058 [details]
netbeans thread dump during server shutdown

Eventually the shutdown timed out and Netbeans displayed a message that shudown failed.
Comment 7 mbauer77 2010-02-28 03:29:21 UTC
Same problem here with Tomcat 6.0.

Interestingly - if i manage to stop tomcat from within netbeans, the log output and execution starts a while until it is really shutdown
Comment 8 trojanfoe 2010-07-07 08:41:12 UTC
I have the same issue with Tomcat 6.0.26.  I am forced to start tomcat outside of NB and 'attach' to it in order to debug my web app.
Comment 9 soupdragon 2011-03-29 08:20:04 UTC
This sounds very much like the problem which has been slowing my development speed. I'm working with JSF on 6.9.1 and tomcat 6.0.26. Because I get exceptions as a matter of routine (view cannot be restored and, above all, deserialization errors because I've changed beans in session) I'm having to restart Tomcat repeatedly, virtually each time I redeploy the program.

JConsole shows the Tomcat serverlog thread in WinNTFileSystem.getBooleanAttributes() triggered from ServerLog$ServerLogSupport.analyseLine().

Clearly the problem is in the log display's attempt to find the source code location of an FQN in the stack trace it's attempting to display.

I'm not sure why I'm being picked on in this way, my colleague is working in a similar environment but doesn't seem to be getting the problem.

My guess, it's that horrible meta-data repository again, which seems to be the cause of most of netbean's woes. (Can't we try sticking it on a real database?) I've read in other bug reports that a great deal of Netbeans time is spent in getBooleanAttributes.

This bug is accumulating cobwebs, presumably because it's proved difficult to duplicated.

I'm going to try deleting and rebuilding the Netbeans cache.

Stack trace: 
java.io.WinNTFileSystem.getBooleanAttributes(Native Method)
java.io.File.isDirectory(File.java:754)
java.io.File.toURI(File.java:661)
org.netbeans.modules.project.ant.ProjectLibraryProvider$ProjectLibraryImplementation.getContent(ProjectLibraryProvider.java:687)
org.netbeans.api.project.libraries.Library.getContent(Library.java:125)
org.netbeans.modules.java.j2seplatform.libraries.J2SELibrarySourceForBinaryQuery.findSourceRoots2(J2SELibrarySourceForBinaryQuery.java:94)
org.netbeans.modules.java.j2seplatform.libraries.J2SELibrarySourceForBinaryQuery.findSourceRoots(J2SELibrarySourceForBinaryQuery.java:122)
org.netbeans.api.java.queries.SourceForBinaryQuery.findSourceRoots(SourceForBinaryQuery.java:93)
org.netbeans.api.java.classpath.GlobalPathRegistry.getSourceRoots(GlobalPathRegistry.java:331)
org.netbeans.api.java.classpath.GlobalPathRegistry.findResource(GlobalPathRegistry.java:380)
org.netbeans.modules.tomcat5.util.ServerLog$ServerLogSupport.analyzeLine(ServerLog.java:314)
org.netbeans.modules.tomcat5.util.ServerLog.processLine(ServerLog.java:120)
org.netbeans.modules.tomcat5.util.ServerLog.run(ServerLog.java:176)
Comment 10 Petr Hejl 2011-04-01 10:35:55 UTC
Hopefully this should be fixed - the log issue. The last report does not seem to be related. Guys, would be great if you could test that. As it has been fixed on branch you will need the latest build from http://bertram.netbeans.org/hudson/job/serverplugins-next/ (at least build number 17) to do so. Thanks.

web-main serverplugins-next 7e617ff42a49
Comment 11 Quality Engineering 2011-04-22 05:04:59 UTC
Integrated into 'main-golden', will be available in build *201104220000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/7e617ff42a49
User: phejl@netbeans.org
Log: #179199 NetBeans server log output locks up Tomcat
Comment 12 soupdragon 2011-04-23 09:01:50 UTC
It this fix going to be issued for 6.9.1? I need it pretty urgently and the dev version conflicts with IvyBeans (which I'm using heavily). Besides which I don't use even beta versions of tools for work if I can possibly avoid, let alone dev versions.
Comment 13 Petr Hejl 2011-04-26 09:04:51 UTC
(In reply to comment #12)
> It this fix going to be issued for 6.9.1? I need it pretty urgently and the dev
> version conflicts with IvyBeans (which I'm using heavily). Besides which I
> don't use even beta versions of tools for work if I can possibly avoid, let
> alone dev versions.
The fix won't go to 6.9.1. You can either fix IvyBeans, which I believe should be pretty simple as NetBeans APIs should remain compatible or transplant the fix to 6.9.1 for yourself - it is just one changeset. Before doing either of these suggestions it would be good to know whether this fix really helped.

The fix will be available in 7.0.1.