> Date: Thu, 6 Mar 2014 11:13:22 +0530
> Subject: Re: Stream closed- IOException exception
> From: prashantkada...@gmail.com
> To: users@tomcat.apache.org
>
> On Wed, Mar 5, 2014 at 9:34 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Prashant,
> >
> > On 3/5/14, 9:14 AM, Prashant Kadam wrote:
> > > On Wed, Mar 5, 2014 at 7:11 PM, Prashant Kadam
> > > <prashantkada...@gmail.com>wrote:
> > >
> > >>
> > >>
> > >>
> > >> On Mon, Mar 3, 2014 at 10:55 PM, Christopher Schultz <
> > >> ch...@christopherschultz.net> wrote:
> > >>
> > > Prashant,
> > >
> > > On 3/3/14, 6:04 AM, Prashant Kadam wrote:
> > >>>>> please help ... I have removed whitespaces by adding
> > >>>>> <jsp-config> <jsp-property-group>
> > >>>>> <url-pattern>*.jsp</url-pattern>
> > >>>>> <trim-directive-whitespaces>true</trim-directive-whitespaces>
> > >>>>>
> > >>>>>
> > </jsp-property-group> </jsp-config> but still i am facing same
> > >>>>> error.
> > >
> > > This may or may not do anything.
> > >
> > >>>>> I tried to increase the buffer size also as, <%@ page
> > >>>>> buffer="800kb" autoFlush="false" %> but still same
> > >>>>> error....
> > >
> > > Hm. With a huge buffer, the only reason the response would have
> > > been committed is if a flush() was being called somewhere. You said
> > > you gutted the struts actions, but it's possible that somewhere,
> > > Struts is internally flushing the buffer. (That would surprise me,
> > > honestly). Are you sure there are no errors occurring anywhere?
> > > Often, an error will cause the response to be committed.
> > >
> > > BTW you probably never want to use autoFlush="false" unless you
> > > are watching the buffer very carefully. For debugging, it's fine,
> > > but you certainly don't want to do that on a regular basis.
> > >
> > >>>>> stuck on this issue for more than 2 weeks now and need to
> > >>>>> close it ASAP please help.
> > >
> > > Remember that this is a community made up of volunteers. This
> > > problem / ticket is *yours* and not ours to be solved ASAP.
> > > Everybody's issues need to be solved ASAP, of course. If you want
> > > something done ASAP and you can't do it yourself, then you'll have
> > > to pay someone else to do it.
> > >
> > >>>>> Any help/ pointer would be highly appreciated.
> > >>>>>
> > >>>>> one more things, we are using struts version 1 and tiles
> > >>>>> 2.2. as struts1 doesn't work with tiles2, we have used
> > >>>>> struts-tiles2-1.4.0-SNAPSHOT.jar, can this create any
> > >>>>> problem, but this combination work with tomcat version
> > >>>>> below 7.0.37 and giving issues from version 7.0.39.
> > >>>>>
> > >>>>> Can anybody please tell me what are the changes in between
> > >>>>> these two versions which can produce this errror ??
> > >
> > > You could take a look at the Changelog for version 7.0.39 (or .38)
> > > to see if anything looks probable. I recommend using a debugger as
> > > Konstantin suggests and trap the condition. You'll be able to
> > > unwind the stack to see what code is causing the response to be
> > > committed.
> > >
> > >>>
> > >>>
> > >>> hi Thanks for your reply. I started debugging the code and
> > >>> found some pointers but not able to fully identify the root
> > >>> cause. What I found is,
> > >>>
> > >>> In TilesRequestProcessor class
> > >>>
> > >>> protected void doForward( String uri, HttpServletRequest
> > >>> request, HttpServletResponse response) throws IOException,
> > >>> ServletException {
> > >>>
> > >>> if (response.isCommitted()) { this.doInclude(uri, request,
> > >>> response);
> > >>>
> > >>> } else { super.doForward(uri, request, response); } }
> > >>>
> > >>> with version 7.0.39, somewhere
> > >>> org.apache.jasper.runtime.ServletResponseWrapperInclude.*isCommited*
> > >>> is setting to false, causing forward but response is already
> > >>> commited and throws IO Exception. with version 7.0.37,
> > >>> particularly for this request this flag sets to true and it
> > >>> works.
> > >>>
> > >>> any pointers on this ? how can I find from where this is
> > >>> setting to false ?
> > >>>
> > >>>
> > >>>
> > >> I found the class *org.apache.coyote.Response* ... where this
> > >> flag is being set, public void setCommitted(boolean v) {
> > >> this.commited = v; }
> > >
> > >> its default value is false and in my case it does not come here
> > >> when I debug, so remains false. But when I use 7.0.37, this
> > >> method gets called and it sets this flag to true.
> > >
> > >> Is there any changes in tomcat which can cause this behavior ?
> >
> > I'm not sure. What did the stack trace look like when
> > setCommitted(true) was called? That's more important than knowing
> > /that/ it was called...
> >
>
> hi Chris thanks for reply
>
> May be I failed to explain properly my understanding, I will explain the
> scenario once again
>
> I am including one jsp in another jsp, there are different behaviors for 2
> tomcat versions as below
>
> 1. case in 7.0.37 - setCommitted(true) was called and thus in tiles code
> (pasted below), it includes the jsp and works fine with no exception thus
> no stack strace
>
> TilesRequestProcessor class
> protected void doForward( String uri, HttpServletRequest
> request, HttpServletResponse response) throws IOException,
> ServletException {
> if (response.isCommitted()) {
> this.doInclude(uri, request, response);
> } else {
> super.doForward(uri, request, response); }
MG>DO NOT COMMIT THE RESPONSE HERE IN THIS SERVLET
MG>ALLOW URL YOU ARE FORWARDING TO COMMIT THE RESPONSE
MG>THE GENERATED RESPONSE WILL PASS BACK TO THE REQUESTING CLIENT
> }
>
> 2. case in 7.0.39 - setCommitted() was not being called and thus default is
> false, and in this case it tries to forward and thus call
> super.doForward(uri, request, response) as per above code. Now as response
> is already committed but due to this flag value being false, it tries to
> flush again giving issue of flushing of already flushed response.
> so the problem is, if response is already committed why this
> org.apache.coyote.Response.isCommitted not being set to true ?
>
> Thanks
> Prashant Kadam
>
>
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQIcBAEBCAAGBQJTF0ryAAoJEBzwKT+lPKRY3UMQAMsYCwZmfwTNxD0nq6mshdIw
> > 96btHgXF5ddUFGR3BnWHZNTPs3z3L9KVcnp7wEb9NQk3hlwUVIt4DXd0CFfSe3IJ
> > 8CTh+Lrp3zlXpbUziDeouKI5SdBvPQin901siU9jt8xMQn9uvK9WoPb6b3+n6vD4
> > y1ROT0yjb+4ClOb0F0anGWsg34SdFqoojX2GOOxxnQ0jXnf9ek09HxcNmXxMg0cr
> > sYa6E0ORI6Xw9OikxW3gCjfIQuJ530Mn20mz0efJ37eRvmNsEjAHEbZjv+oeYj9O
> > d6j02hwybfPqIMIru2OLFNTSpOvRht0C3lF1mWNqGhI6sdeQCkMA/nAduz7R4E0H
> > ESPvm5i4ICl7MLQbyQWos8oxU7lyf7Mqs5f/u3hUGgT24ndt7dHbPOErWGeEh0fi
> > z9fTm9+GtmgsB0Ka3gOzBa3tbb/zW+0rGxG9MCVYe/ffNX5XvyMETP1y/Zf5di2l
> > hhAGa5t5vgAQzg+jpgt4EuYvk6mP+no31aUCgxzNLW+PmjMxB5nRtOqAWuxlZzx5
> > c0OWeefLG4oYlQqAWRBzt+B8/rPZ1Ozfkwo19VNRinKjCCf9gN+MO/M6GIJ79vhe
> > hSmxihGAsaGBgX4zFyhDJpFF27LzjQ+MQXfA4xvOaFIkMYuJbzavX/N4u+hVtllL
> > Gq5bmSbroAuBqTP/ORxe
> > =RyM3
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
>
> --
> ~ Prashant Kadam
