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) ? theDefault : s;
}
Then, JSPTemplate's constructor:
public JSPTemplate(String template, HttpServletRequest request,
HttpServletResponse response)
{
this.template = template;
this.request = request;
this.response = response;
}
Note that service is always null (at the moment).
Q
On 7/10/08, Quintin Beukes <[EMAIL PROTECTED]> wrote:
> 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 receiving the following error in my logs: Response already
> committed in Search.replyBody()
>
> Let me show you how this can happen (I verified by 'n grep that this
> is the only place in the code this error occurs).
>
> Firstly, this is my doGet():
> public void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException
> {
> tmpl = new JSPTemplate("/templates/search.jsp", req, resp);
>
> // long curMillis = System.currentTimeMillis();
> String service = WebClient.getString(req, "service", null);
> if (service != null)
> {
> service = service.toLowerCase();
> if (service.equals("srchfrm"))
> {
> replySearchForm(req, resp);
> }
> else if (service.equals("log"))
> {
> }
> else if (service.equals("listeditions"))
> {
> replyJS(req, resp, Edition.getWebEditionList());
> }
> else if (service.equals("showindexes"))
> {
> replyHtml(req, resp, Edition.showIndexes());
> }
> }
> else
> {
> String itemPath = req.getRequestURI();
> if (itemPath != null)
> {
> int i = itemPath.lastIndexOf('/');
> if (i != -1) itemPath = itemPath.substring(i + 1);
> i = itemPath.indexOf('?');
> if (i != -1) itemPath = itemPath.substring(1, i);
> // System.out.println(itemPath);
>
> replyBody(req, resp); // do the search
> }
> }
> }
>
> Then replyBody's first few looks like this:
> private void replyBody(HttpServletRequest req, HttpServletResponse resp)
> {
> WebClient theClient = null;
>
> try
> {
> if (resp.isCommitted())
> {
> System.err.println("Response already committed in
> Search.replyBody()");
> resp.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
> "Please contact the webmaster with this error code:
> Search.replyBody()");
> }
>
> As you can see I am receiving a fresh response object, and checking it
> for "committedness", which it evaluates to true.
>
> Inside the tomcat code, is a fresh response object created for every
> request? Or are they shared?
>
> Q
>
>
> On 7/10/08, Konstantin Kolinko <[EMAIL PROTECTED]> wrote:
> > 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 asked somehow once in a month.
> >
> > Maybe it is even in the FAQ list. Try to search the archives.
> >
> >
> >
> > 2008/7/10 Quintin Beukes <[EMAIL PROTECTED]>:
> >
> > > 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 I can get some advice/guidance as this problem is major for
> > > us at the moment. To revert to the old ways will take too long, and
> > > we'll loose a lot of time spent in design for current and future
> > > changes, which are all based around our moving forward from the JSP
> > > templates.
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
>
> Quintin Beukes
>
--
Quintin Beukes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
