Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <1f3854d50807101009v1368f26bpbdad8cdaa206290a@mail.gmail.com>
Date: Thu, 10 Jul 2008 19:09:15 +0200
From: "Quintin Beukes" <quintin@last.za.net>
Sender: quintin@skywalk.co.za
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Subject: Re: Vicious Bug in the JSP code?
In-Reply-To: <427155180807100811m66456befi7082db3378fc8e27@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1f3854d50807100723l383d30bbw89e14c8ad9125c7@mail.gmail.com>
	 <1f3854d50807100759p41eb3faaw77e474ea40004833@mail.gmail.com>
	 <427155180807100811m66456befi7082db3378fc8e27@mail.gmail.com>

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 <knst.kolinko@gmail.com> 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 <quintin@last.za.net>:
>
> > 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: dev-unsubscribe@tomcat.apache.org
>  For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


-- 
Quintin Beukes

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org