Community
Participate
Working Groups
Build ID: I20100520-1744 (3.2RC2) 1. Help > Contents 2. Run a broken hyperlink finder on .../help/index.jsp --> Log (attachment 169872 [details] on bug 314322) gets filled with several messages about missing elements from org.eclipse.jdt.doc.user. One example is this: Error Tue May 25 15:01:28 CEST 2010 Error processing help request org.eclipse.jdt.doc.user/tasks/images/task-add_jre_std_vm.PNG External hyperlinks seem to be OK for JDT as far as I can tell, though a brief review of the link spider output might make sense. See attachment 169874 [details] (zipped .html) on bug 314322.
I made a quick check. Rather looks like the spider is not working. The output is lame too since it doesn't tell which file requested/links the file. Please open a bug if you do find broken links ;-)
>The output is lame too Sorry - only looked at the log :-(
The broken link section does not contain anything for JDT. No idea why the log is filled but that's definitely not our business ;-)
Hm... the log has been produced, as a matter of fact. Perhaps there is a scalability problem in Jetty with 30 parallel Threads hammering on the help server? This might be relevant for an infocenter, so I'm re-assigning to UA for now. Dani, can you confirm that the images referenced in the log do actually exist in the JDT user docs? It may also help doing a "Search" for one of these to see where they are actually referenced. I don't have a jdt.doc.user in source form at the moment to try this.
>Dani, can you confirm that the images referenced in the log do actually exist I tested two which confirms to me that the entries in the log does not indicate a missing resource.
Looks like a duplicate of bug 311616.
I now also see this in my normal workspace when launching a target and the target indexes the pages: !ENTRY org.eclipse.help.webapp 4 0 2010-05-27 13:59:34.525 !MESSAGE Error processing help request org.eclipse.help.webapp/advanced/breadcrumbs.css !STACK 0 org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:789) at org.mortbay.jetty.HttpGenerator.complete(HttpGenerator.java:676) at org.mortbay.jetty.HttpConnection.commitResponse(HttpConnection.java:653) at org.mortbay.jetty.HttpConnection$Output.close(HttpConnection.java:991) at org.eclipse.help.internal.webapp.servlet.EclipseConnector.transfer(EclipseConnector.java:191) at org.eclipse.help.internal.webapp.servlet.ContentServlet.doGet(ContentServlet.java:45) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManager.java:318) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:924) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by: java.io.IOException: An existing connection was forcibly closed by the remote host at sun.nio.ch.SocketDispatcher.writev0(Native Method) at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:37) at sun.nio.ch.IOUtil.write(IOUtil.java:159) at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:365) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:388) at java.nio.channels.SocketChannel.write(SocketChannel.java:360) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:232) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:211) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:712) ... 26 more
FYI: not a regression: same exceptions with 3.5.2, but not with 3.4.
Do you happen to know which JRE you were using? I have seen this before but only rarely and usually only when running the link checker. I first saw it after we switched to use Jetty 6 and non blocking I/O. I think there is another bug open, I'll look around for it.
I was using java.runtime.version=1.6.0_19-b04 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc.
(In reply to comment #9) > Do you happen to know which JRE you were using? I have seen this before but > only rarely and usually only when running the link checker. I first saw it > after we switched to use Jetty 6 and non blocking I/O. I think there is another > bug open, I'll look around for it. jdk6_20-ea-bin-b01. i Saw the problem in the runtime and also the target. Normally while it started to create the index. And always when using the link checker.
I am seeing this also, although on average only about one or two messages per occasion when I read every page of the JDT user guide using the prototype link checker in org.eclipse.ua.tests.doc (I have not advertised the existence of this link checker because it cannot handle all html files but it shows up in the help menu as "Check TOC links" if org.eclipse.ua.tests.doc is installed.) It always seems to be on a file which is pulled in by an html file, in my case almost always a .css or .js file. I have tried to create a simple test case of a servlet which can reproduce the problem but so far without luck. I suspect the problem lies in Jetty but I have no hard evidence so far.
*** Bug 316146 has been marked as a duplicate of this bug. ***
I can reproduce this in the help system, so far I have not been able to reproduce outside of the help system. I wrote a test to set up 10 threads which repeatedly tried to read from a servlet and it runs fine, even when I increase the loop count in the test so it makes over 100,000 calls to the servlet. I will add that test to the JUnit test suite (see Bug 316215) but I am not any closer to understanding this bug.
Here is an update. On WinXP I can reproduce the problem consistently when using the embedded browser or IE as an external browser, about one out of every 500-1000 reads gives an error message. With Firefox as the external browser I do not see the exception at all. I also have not seen any evidence that the error has an impact on the client side, the link checker in org.eclipse.ua.tests works by injecting the include of a JavaScript file which will open the next page in the toc and continue this way until every page in the toc has been read. Although I have seen eofExceptions in this JavaScript file they don't prevent the complete chain of pages from being read.
http://jira.codehaus.org/browse/JETTY-488 seems relevant. I think it's unfortunate that we're logging these exceptions as this seems like business as usual. We might look into catching the EOFException in our ResourceHandling in the HTTP Service although that would also imply that all servlets should also take similar precautions to avoid throwing an EOFException when writing to the servlet output stream. It might be more sensible to look at changing the default log level for Jetty from WARNING to ERROR.
I also think that we should not be logging the exceptions, the exceptions are logged by the help system, not by Jetty. It is possible to reproduce the message in the log on Eclipse 3.5 if you open and expand a large number of nodes and use the keyboard to rapidly open a large number of different pages, however it seems that after going unreported for almost a year in the last two weeks it has been reported twice in Bugzilla. It was also reported to me by a co worker who was able to reproduce the error message far more than the one in 500 reads which I am seeing. I plan to suppress the error message in the log unless debugging is turned on.
Created attachment 172441 [details] Patch Since these exceptions can occur as a result of normal processing we should not be logging an error.
Patch applied to 3.6 maintenance stream, Fixed.
(In reply to comment #19) > Patch applied to 3.6 maintenance stream, Fixed. Hi Chris. What was the fix, to not log the exception?
That was essentially the fix. Also the exception on close is caught earlier than before so that the input stream still gets closed.
I'm not seeing these messages using M20100901-0800
