Hi Mark,
Thanks for your quick response. The string 'getOutputStream' actually is
retrieved from org/apache/catalina/connector/LocalStrings.properties using
key 'responseBase.getWriter.ise' by
org.apache.catalina.ResponseBase.getWriter().
getOutputStream() is called from
org.apache.jasper.runtime.JspWriterImpl.initOut()
which is called from same class flushBuffer() method.
flushBuffer() is in turn called by PageContextImpl.release() which is method
I included in my previous email.
The ViewAttachment.jsp (8th line down in the prev. stack trace) is the where
the problem originates. This JSP writes to output stream the file attachment,
but since the JSP already has an output stream active, this causes the
exception
(I think.) I could rewrite the application as a servet, as a fix.
However, before doing that I wanted to find out if the memory leak is:
a) a known limitation
b) whether a patch is available for example to add a finally block to
PageContextImpl.
release() which would solve the leak problem.
Thanks,
Matthew
> ----Original Message----
> From: [EMAIL PROTECTED]
> Date: May 30, 2005 9:07:35 PM
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Subj: Re: Is there Patch for 4.1 PageContextImpl unhandled
> IllegalStateException?
>
> Hmm. Looks like PageContextImpl.release() code could do with a clean up
;)
>
> Ignoring that for now, do you have any idea what is calling
> getOutputStream()? Is it called in ViewAttachment.jsp?
>
> Mark
>
> [EMAIL PROTECTED] wrote:
> > Hello Tomcat Users and Committers,Platform: Tomcat 4.1, Linux ES 2.1,
jdk1.4.1.06
> Here is a snippet of the stack trace we regularly in our Tomcat 4.1.24
logs.
> ----- Root Cause -----
> java.lang.IllegalStateException: getOutputStream() has already been
> called for this response
> at
> org.apache.catalina.connector.ResponseBase.getWriter(ResponseBase.java:
756)
> at
> org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:174)
> at
> org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:173)
> at
> org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:
166)
> at
> org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:184)
> at
> org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:
198)
> at
> org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:193)
> at
> org.apache.jsp.ViewAttachment_jsp._jspService(ViewAttachment_jsp.java:
76)
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:
210)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:
684)
> at
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:
356)
>
> We intend to migrate to Tomcat 5.x later this year.
> In the interim, we recently linked this exception event to leaked memory.
> That is, the PageContextImpl.release() method (6th from top in stack
> trace, body below)
> never completes as it does not catch the IllegalStateException that
> happens when
> ResponseBase.getWriter()is called in the scope of flushBuffer().
> public void release() {
> out = baseOut;
> try {
> if (isIncluded) {
> ((JspWriterImpl)out).flushBuffer();
> // push it into the including jspWriter
> } else {
> // Do not flush the buffer even if we're not included
(i.e.
> // we are the main page. The servlet will flush it and
> close
> // the stream.
> ((JspWriterImpl)out).flushBuffer();
> }
> } catch (IOException ex) {
> loghelper.log("Internal error flushing the buffer in release()");
> }
> servlet = null;
> config = null;
> context = null;
> needsSession = false;
> errorPageURL = null;
> bufferSize = JspWriter.DEFAULT_BUFFER;
> autoFlush = true;
> request = null;
> response = null;
> depth = -1;
> baseOut.recycle();
> session = null;
> attributes.clear();
> }
>
> The tear-down activity session=null is skipped because of the exception,
> which creates a problem since the session so referenced becomes
> ineligible for garbage
> collection after processing the request.Does anyone know:
> a) is this documented somewhere (I read 102 matches for ‘memory leak’
on
> the Tomcat 4.1 list archives,
> but I did not find this exact problem, except for an entry in the 4.1
> release notes where it is reported
> fixed in 4.1.20).
> b) is there a patch available to fix this in Tomcat 4.x?
> Thanks very much for your time,
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
