Community
Participate
Working Groups
Build ID: 3.7M3 I got this logged on the console of our infocenter running on dsdp.eclipse.org while navigating the documentation. I'm rolling back from 3.7M3 to 3.6.1 because the infocenter doesn't seem to run reliably: 2010-11-29 05:41:47.800:WARN::ERROR: /help/nav/7_1_2_13 java.lang.ArrayIndexOutOfBoundsException: 7 at org.eclipse.help.internal.webapp.servlet.NavServlet.getTopic(NavServlet.java:91) at org.eclipse.help.internal.webapp.servlet.NavServlet.doGet(NavServlet.java:58) 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)
I don't immediately see what would cause a regression in this area - I will investigate.
Do you have any background on what was taking place when the exception occurred? This section of code is called when the user clicks on a link to a nav page, either in the table of contents or from a breadcrumb. The line where the exception is thrown is reading from the array of Tocs based on the first segment of the path. In this case it is trying to read element 7 from the array of Tocs, I'm guessing that there are no more that 7 Tocs and that the servlet was called with an invalid parameter. Without knowing the circumstances it's going to be hard to figure out why this occurred - it could even be a user with a stale bookmark. Have you seen multiple errors like this?
I had updated the infocenter on dsdp.eclipse.org to a new version, and tested it myself. Had noticed some very odd behavior in Firefox (books did not appear in the TOC at all, though search did produce hits; pressing the "Show in contents" button did then bring up the missing book). Also played with scopes a bit. When I saw that IE didn't behave that oddly, I cleared the cache in Firefox and it went back to normal. I should mention that I see very slow load times / high latency from my workplace to the server. My infocenter is very small (just 4 books), you can try it yourself on http://dsdp.eclipse.org/help/latest/ it's now running 3.7M3 again and I plan to upgrade to an I-build using Lucene 2.9.1 soon. From what you say, the exception is probably kinda expected in this situation and seems to be harmless. I'm OK with closing this "WORKSFORME". Are you generally interested in having infocenter exceptions reported? About once in a month I do see exceptions similar to this in the log. My infocenter is shutdown and restarted frequently.
I've been thinking about whether the infocenter should report messages of this kind. The convention seems to be that when the help system runs into a situation where an exception is thrown that exception is written to the log so I'll close out this bug.
