2013/12/7 Christopher Schultz <ch...@christopherschultz.net>:
> On 12/6/13, 1:07 PM, Mark Thomas wrote:
>> On 06/12/2013 17:33, C. Benson Manica wrote:
>>> I'm sure it *is* some kind of buffer boundary - 16384 is not a
>>> random number ;-) As it happens, I *did* miss some logging (my
>>> IDE made it easy to miss). I have no idea what this exception
>>> means though:
>>>
>>> SEVERE: Servlet.service() for servlet [jsp] in context with path
>>> [] threw exception [java.lang.ArrayIndexOutOfBoundsException: 0]
>>> with root cause java.lang.ArrayIndexOutOfBoundsException: 0 at
>>> org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:785)
>>> at
>>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
>>>
>>>
>>
>>>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
>>>
>>> (rest of stack trace omitted)
>>>
>>> Presumably this is my actual problem, whatever it is?
>>
>> It means that there is a bug in your JSP. Whether that bug is in
>> code generated by Tomcat (i.e. a Tomcat bug) or an application bug
>> is TBD. You'll need to look at line 785 of the generated java file
>> for that JSP (it is in the work directory) and see.
>
> ... and the unspoken consequence of the above is that the JSP will
> abruptly stop producing output and, since the headers have already
> been sent to the client, the client sees no error at all. That would
> explain the behavior you are observing. Tomcat's chunking evidently
> does not have a problem: your JSP does instead.
>
> I wonder if your Jetty setup avoids the AOOBE due to environmental
> differences (e.g. you have data in your Jetty setup, but not in your
> Tomcat one) or perhaps your JSP triggers a bug in Tomcat which
> generates unsafe code in some situation.
>
> I'm eager to hear back from C. Benson about what's on that line of
> code... it would be nice to know if Tomcat has an obscure bug that
> needs to be fixed, or if the JSP was simply carelessly-written.
I can reproduce this behaviour with the following JSP page:
[[[
<%
for (int i=0; i<1000; i++) {
out.println(i + ": 1234567890");
}
String[] a = new String[0];
a[0] = "foo";
%>
]]]
The chunk size is 8Kb. The first 2 chunks are sent successfully, and
the exception occurs while sending the 3rd chunk.
The result is:
1). The exception is caught and properly logged into the
"localhost.${date}.log" file by
StandardWrapperValve.invoke(...):
[[[
Dec 07, 2013 0:00:00 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [jsp] in context with path []
threw exception [ (...) ]
]]]
2). Client sees 16Kb of data. There are two chunks of size 0x2000 and
terminating chunk of size 0x0.
3). The text of an error page is not rendered, as ErrorReportValve.invoke does
[[[
if (response.isCommitted()) {
return;
}
]]]
4) If I add the following line at the top of the JSP page, the usual
error page 500 is displayed.
<%@page bufferSize="40000"%>
Conclusion:
This works as expected.
The ErrorReportValve cannot send the error text to the client,
because sending some data regardless of the content type of the
response would be a bad thing.
The ErrorReportValve could be changed to log the error, but the
logging part is already handled by the StandardWrapperValve, so I see
no point is such a change.
Maybe the ErrorReportValve could be changed to adjust its behaviour
depending on the content type of the response (e.g. to check if it is
text/html and append its own text/html content if that is the case).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
