I figured it might be related to the Nio protocol I did, so I changed
it to HTTP/1.1. What a surprise!!
It all comes down after the JSP is invoked, so my perception is that
it's related to a bug in the JSP code. Jasper?
Any advice would be greatly appreciated, and I'm willing to fix it
myself if
It looks like you are keeping a reference to some object (like the
Request or Response, or OutputStream) and reusing it, while you should
not access it outside the scope of request processing.
I cannot go into details now, but all these messages and stack traces
look familiar. Such questions are
here are some steps you can take
1. Start asking on the tomcat user list, most likely you have some funky
flow in your app, for example, you can't do requestdispatcher.forward if
you've already written data (like JSPs do behind the scenes when you use
them
2. try to work out a reproducible
Hey,
That was one of my thoughts as well, as I do keep those references,
but only to make it easy when passing on, and I do this inside a
synchronization block on the keeper object, at the end of which
(inside a finally) I release them.
Eitherway, here is some more proof that it is tomcat:
I am
Hey,
Just to clear up some of the methods that receive the request or
response inside the doGet().
Firstly, WebClient.getString()
public static String getString(HttpServletRequest req, String key,
String theDefault)
{
String s = req.getParameter(key);
return (s == null) ?
Quintin Beukes wrote:
Eitherway, here is some more proof that it is tomcat:
Experience suggests that the root cause will be in the application rather
than in Tomcat. This issue is best debugged via the users list.
In the unlikely event that the debugging shows that this is a Tomcat bug,
Hey,
My own experience and insight also suggests an application error.
Though I spent hours trying to find one, which I couldn't (which in
itself is rare for myself). I have one more question suitable for this
list though.
When tomcat creates an instance of ServletRequest, ie
