Re: Stream closed- IOException exception
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Prashant,
On 3/6/14, 12:43 AM, Prashant Kadam wrote:
>> May be I failed to explain properly my understanding, I will
>> explain the scenario once again
No, I get it. You just aren't answering the questions I'm asking.
>> 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); } }
>
>> 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 ?
1. In Tomcat 7.0.37, what is the full stack trace for when
setCommitted is called?
2. In Tomcat 7.0.39, what makes you think that the response has been
committed if setCommitted(true) is never called? What makes you think
that setCommitted(true) /should/ have been called?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTGfD9AAoJEBzwKT+lPKRYH3sQALtT4AWxANO7nC/a5RuyQanr
NWXbM2V8eCHYH09f6Y2t05/i3DVpOkVkxneXPZugvHsfEZzjl7MnAYjWodzQvRnu
7dRCc67BILo3XMr/mqo6rFgTouGsQOetiT8bVfqbKrhxuqtUnV1VULNQNFmOjRnU
PMYc9ppinGSEnedL9dvrJt3k2jYYR+vef2YXC5VskEC6S1NShJAB/l1RM0DXbKku
luscrMtTqzGLtmNtj6iuKBePvlIhtGBNEnxn2GEQEiIAiD1yxuUK679e8l+2UArp
ofuiLavlwIq8mPgChivGN3aigde6R5xxm9PcuUE48sZKKD1uRORNDeZ5uHRP+gWd
8Oh4jY4nXH2RNsWwWJjU3q6aw34Oo3XiBspolurIkwYldlsBfkyzDfk7n3ZNoaCv
G5krLjFhXN9NbH7GrqjR3tB6WedOJaGkeG4EtufBAh5k0+Fil942MUo7ym3IiWuJ
7sX2peTvRJUXEpTks09UhHFPjzBtjlvl9iSFI0FjwTaL2JVe7nthzWPzCBumwQvf
j1unT4wezrh9c6KXnjN2Tf+2HW4Y1YJB7PYYBGrOEuQ6ppSbLoqBNQNlUMytPrlN
hvGh836r32zvp7NLKkooJeI6GIGCw/VyecDhBPYjwtlVC3DSXR0qOoyVyGQScvjI
ScB+CsVsZrmIjcdR3E1C
=1q0U
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Stream closed- IOException exception
> 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
> > > 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
> > >>>>> true
> > >>>>>
> > >>>>>
> > 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 bu
Re: Stream closed- IOException exception
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
> > 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
> > true
> >
> >
> 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); }
}
2. case in 7.0.39 - setC
Re: Stream closed- IOException exception
-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
> 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
> true
>
>
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...
- -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
Re: Stream closed- IOException exception
On Wed, Mar 5, 2014 at 7:11 PM, Prashant Kadam wrote:
>
>
>
> On Mon, Mar 3, 2014 at 10:55 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Prashant,
>>
>> On 3/3/14, 6:04 AM, Prashant Kadam wrote:
>> > please help ... I have removed whitespaces by adding
>> > *.jsp
>> > true
>> > 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 ?
Thanks
Prashant Kadam
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJTFLrqAAoJEBzwKT+lPKRYYx0P/jQ065OqO2xG+TiWv8Nkyht8
>> HMewLURHezpCkWM3Q2tCrV4mgTXLgvs1eOMBdi4LTjvzAdLjPNRBBQhR0bXjjIIS
>> gAu92exfyuoBgN8mkgBTgZpmIFa/xPIbj+xDdImFHYcpHCrRw7ga4V9iyum27UQF
>> JkXGz/qOegMattgF2k6Dgkz2UBN7QLwqnAqpaFo3m9XNqc6eQdTQWTzZ+MXX2tJ2
>> dndK+Bu+sdlWDeCtnegGO8ieh5GH0SB67ygSnBC/FPQOTDKojTpG7XbvrKonviUH
>> 2u8S1gBuRClGGWXYv73LTCIYM5hpZA6S86nHD8UBciNTEx/rfLFtDGfpyb0lSVo8
>> 4/kt/XIuqzmnrFkV2+Do2/xmorAs3QADlkmaK1e0cT1yVCBGUwU1FfalELj6JICj
>> Wc73VB2SPDgwnY8qS1haa8V+LHZq4KVj9M1ZVf1buA7sFQTHeMsezP7KMmySJ6GU
>> Ht70ubSvCIiEiSKT/gBeRcaTr1G6tyD4mObrKoz87BDMJbfe5yfkhguDKa3xvZLa
>> +4oVvROVYklE1ZVAvY4IUH+LHTpWIL9HJFtWxi2C+KE0ihs8wq+iA+KMdkwB4W7H
>> 9l231PiUE8ugya9K6qvDglPXhB5TvzIqpRoyb3lomESTwYuqDERYGRs3ouIVuJ3f
>> vF1I9tIciTVKPwzRNESN
>> =ukUm
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
> --
> ~ Prashant Kadam
>
--
~ Prashant Kadam
Re: Stream closed- IOException exception
On Mon, Mar 3, 2014 at 10:55 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Prashant,
>
> On 3/3/14, 6:04 AM, Prashant Kadam wrote:
> > please help ... I have removed whitespaces by adding
> > *.jsp
> > true
> > 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 ?
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTFLrqAAoJEBzwKT+lPKRYYx0P/jQ065OqO2xG+TiWv8Nkyht8
> HMewLURHezpCkWM3Q2tCrV4mgTXLgvs1eOMBdi4LTjvzAdLjPNRBBQhR0bXjjIIS
> gAu92exfyuoBgN8mkgBTgZpmIFa/xPIbj+xDdImFHYcpHCrRw7ga4V9iyum27UQF
> JkXGz/qOegMattgF2k6Dgkz2UBN7QLwqnAqpaFo3m9XNqc6eQdTQWTzZ+MXX2tJ2
> dndK+Bu+sdlWDeCtnegGO8ieh5GH0SB67ygSnBC/FPQOTDKojTpG7XbvrKonviUH
> 2u8S1gBuRClGGWXYv73LTCIYM5hpZA6S86nHD8UBciNTEx/rfLFtDGfpyb0lSVo8
> 4/kt/XIuqzmnrFkV2+Do2/xmorAs3QADlkmaK1e0cT1yVCBGUwU1FfalELj6JICj
> Wc73VB2SPDgwnY8qS1haa8V+LHZq4KVj9M1ZVf1buA7sFQTHeMsezP7KMmySJ6GU
> Ht70ubSvCIiEiSKT/gBeRcaTr1G6tyD4mObrKoz87BDMJbfe5yfkhguDKa3xvZLa
> +4oVvROVYklE1ZVAvY4IUH+LHTpWIL9HJFtWxi2C+KE0ihs8wq+iA+KMdkwB4W7H
> 9l231PiUE8ugya9K6qvDglPXhB5TvzIqpRoyb3lomESTwYuqDERYGRs3ouIVuJ3f
> vF1I9tIciTVKPwzRNESN
> =ukUm
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
~ Prashant Kadam
Re: Stream closed- IOException exception
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Prashant, On 3/3/14, 6:04 AM, Prashant Kadam wrote: > please help ... I have removed whitespaces by adding > *.jsp > true > 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. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTFLrqAAoJEBzwKT+lPKRYYx0P/jQ065OqO2xG+TiWv8Nkyht8 HMewLURHezpCkWM3Q2tCrV4mgTXLgvs1eOMBdi4LTjvzAdLjPNRBBQhR0bXjjIIS gAu92exfyuoBgN8mkgBTgZpmIFa/xPIbj+xDdImFHYcpHCrRw7ga4V9iyum27UQF JkXGz/qOegMattgF2k6Dgkz2UBN7QLwqnAqpaFo3m9XNqc6eQdTQWTzZ+MXX2tJ2 dndK+Bu+sdlWDeCtnegGO8ieh5GH0SB67ygSnBC/FPQOTDKojTpG7XbvrKonviUH 2u8S1gBuRClGGWXYv73LTCIYM5hpZA6S86nHD8UBciNTEx/rfLFtDGfpyb0lSVo8 4/kt/XIuqzmnrFkV2+Do2/xmorAs3QADlkmaK1e0cT1yVCBGUwU1FfalELj6JICj Wc73VB2SPDgwnY8qS1haa8V+LHZq4KVj9M1ZVf1buA7sFQTHeMsezP7KMmySJ6GU Ht70ubSvCIiEiSKT/gBeRcaTr1G6tyD4mObrKoz87BDMJbfe5yfkhguDKa3xvZLa +4oVvROVYklE1ZVAvY4IUH+LHTpWIL9HJFtWxi2C+KE0ihs8wq+iA+KMdkwB4W7H 9l231PiUE8ugya9K6qvDglPXhB5TvzIqpRoyb3lomESTwYuqDERYGRs3ouIVuJ3f vF1I9tIciTVKPwzRNESN =ukUm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stream closed- IOException exception
2014-03-03 15:04 GMT+04:00 Prashant Kadam : > > stuck on this issue for more than 2 weeks now and need to close it ASAP > please help. > Any help/ pointer would be highly appreciated. > If nothing else helps, try running with a debugger to find when the said response is being committed. https://wiki.apache.org/tomcat/FAQ/Developing#Debugging A breakpoint can be set 1. On the place that throws IllegalStateException 2. On places that use ActionCode.COMMIT constant (org.apache.coyote.ActionCode). E.g. in org.apache.coyote.http11.AbstractHttp11Processor.action(...) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stream closed- IOException exception
please help ... I have removed whitespaces by adding *.jsp true but still i am facing same error. I tried to increase the buffer size also as, <%@ page buffer="800kb" autoFlush="false" %> but still same error stuck on this issue for more than 2 weeks now and need to close it ASAP please help. 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 ?? Thanks Prashant Kadam On Mon, Mar 3, 2014 at 11:58 AM, Prashant Kadam wrote: > On Sat, Mar 1, 2014 at 1:33 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Prashant, >> >> On 2/28/14, 7:54 AM, Prashant Kadam wrote: >> > thanks Mark and Konstantin for your reply >> > >> > If you create the simplest possible JSP that demonstrates the >> > issue (start with the one you have and remove as much as you can) >> > and then post that JSP here, we can take a look. >> > >> >>> as you can see in stacktrace, there are many jsps forwarding >> >>> request to >> > another jsp, i am not sure how can I post jsp code. also one >> > observation is, there is a struts action forward in between means >> > jsp-> struts action -> jsp , If I remove this action call and >> > include jsp directly in jsp then its working ... whether something >> > wrong with tiles or struts or tomcat .. ? >> >> If you are doing a lot of JSP forwarding, you could be generating a >> lot of useless whitespace that is all being sent to the output buffer. >> Once that buffer fills up, the response headers will be sent to the >> client and and response is therefore committed. >> > > thanks for your reply > seems logical ... and will try by removing white spaces .. > still one question ... > > this is how it work it flows ... > 1. jsp1 includes jsp2, > 2. jsp2 forwards to jsp3 (using org.apache.struts.actions.ForwardAction) , > 3. jsp3 forwards to strutsaction1, > 4. strutsaction1 forwards to strutsaction2, > 5. strutsaction2 forwards to jsp4, > 6. and jsp4 includes jsp5 to render final view ... > > now if I remove 3,4,5 and directly include jsp4 into jsp3 it works. > > even I tried removing all business logic code in strutsaction1, > strutsaction2, it is throwing same error .. so conclusion is whenever i am > using struts action in between it is causing problem ... > any thoughts ... ? > > > > >> If my analysis is correct, the difference between the Tomcat versions >> probably comes down to some small change in the way JSPs are compiled >> which may generate more whitespace if you haven't been careful. >> >> Take a look at all the JSPs that are participating in the request -- >> you should be able to inspect them to see why they might be generating >> whitespace. Remember, newlines are whitespace ;) >> >> I can see from your stack trace that you are using *includes*. Is >> there some other error that is occurring before this one? Does it >> happen on every request to this resource? >> >> yes this happen on every request for same resource ... > > this is exception that i can see when I put try catch in one of the jsp ,,, > javax.servlet.jsp. > JspException: javax.servlet.jsp.JspException: > javax.servlet.jsp.JspException: org.apache.jasper.JasperException: > java.lang.IllegalStateException: Exception occurred when flushing data > > > >> - -chris >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1 >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCAAGBQJTEOt7AAoJEBzwKT+lPKRY6fYP+wWFNBtLRjUi1m6NPPpxajyp >> NBp0SZ5TIBs9c1fwAq3oKjodMDsgGMo59HApJpzHYyQhwuKHez3VLdGPss4aeq50 >> +Yc/UNhuMor31JWkPHzy05oSEFOQeKFn8Trw//OJ8m2giZSopt/05E8NRu9MIpUw >> +9eEsetJHs0502XCEFQ206/6MLxleGLA/sM5HTWJHg0NJczobTsHo40myy201Y1j >> Q7tO/gsyRzwljbHf0XByTTYUQNaNCaTzH0ydLiVeWCaPfxCpF4DXzrzdBu+BrL8U >> n5BlaizxMp9vd5DPucbRZidC0ihQpcaMjBAXnwg3OtbltX5EsMEYOfgD/TQXh5PC >> PFTPRm21OaybgNj13hNOOfmOCDw5AAA+znyVPFl4Ao+z67w0jIgSre49HMXfzYJQ >> a2pcDzCUuvbtXl22LJBVcnqlISLETiShulRzvAF5OiYwe2bJS4fOdWNSB8Nn7L7A >> +x//HxvTOem1dG5CaFRkCxvnkvK30e4LNCwY0AfErt3eKahHj0rJA+w/qiodTg2U >> bzh8kgRv+9v0fqV3RKVV/nO7WFRlyN6QIalCvLKPC+9CdajvBPUVC+gZgizs4pjT >> osHuIcGPmXMzycj1FfXzym5ucdy/WlJPUIBtliA4XnJ/RdBu1WfdB0c6rruiNflW >> vp1dKzQjPx5Zv58BU2l1 >> =pI9J >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > > -- > ~ Prashant Kadam > -- ~ Prashant Kadam
Re: Stream closed- IOException exception
On Sat, Mar 1, 2014 at 1:33 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Prashant, > > On 2/28/14, 7:54 AM, Prashant Kadam wrote: > > thanks Mark and Konstantin for your reply > > > > If you create the simplest possible JSP that demonstrates the > > issue (start with the one you have and remove as much as you can) > > and then post that JSP here, we can take a look. > > > >>> as you can see in stacktrace, there are many jsps forwarding > >>> request to > > another jsp, i am not sure how can I post jsp code. also one > > observation is, there is a struts action forward in between means > > jsp-> struts action -> jsp , If I remove this action call and > > include jsp directly in jsp then its working ... whether something > > wrong with tiles or struts or tomcat .. ? > > If you are doing a lot of JSP forwarding, you could be generating a > lot of useless whitespace that is all being sent to the output buffer. > Once that buffer fills up, the response headers will be sent to the > client and and response is therefore committed. > thanks for your reply seems logical ... and will try by removing white spaces .. still one question ... this is how it work it flows ... 1. jsp1 includes jsp2, 2. jsp2 forwards to jsp3 (using org.apache.struts.actions.ForwardAction) , 3. jsp3 forwards to strutsaction1, 4. strutsaction1 forwards to strutsaction2, 5. strutsaction2 forwards to jsp4, 6. and jsp4 includes jsp5 to render final view ... now if I remove 3,4,5 and directly include jsp4 into jsp3 it works. even I tried removing all business logic code in strutsaction1, strutsaction2, it is throwing same error .. so conclusion is whenever i am using struts action in between it is causing problem ... any thoughts ... ? > If my analysis is correct, the difference between the Tomcat versions > probably comes down to some small change in the way JSPs are compiled > which may generate more whitespace if you haven't been careful. > > Take a look at all the JSPs that are participating in the request -- > you should be able to inspect them to see why they might be generating > whitespace. Remember, newlines are whitespace ;) > > I can see from your stack trace that you are using *includes*. Is > there some other error that is occurring before this one? Does it > happen on every request to this resource? > > yes this happen on every request for same resource ... this is exception that i can see when I put try catch in one of the jsp ,,, javax.servlet.jsp. JspException: javax.servlet.jsp.JspException: javax.servlet.jsp.JspException: org.apache.jasper.JasperException: java.lang.IllegalStateException: Exception occurred when flushing data > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTEOt7AAoJEBzwKT+lPKRY6fYP+wWFNBtLRjUi1m6NPPpxajyp > NBp0SZ5TIBs9c1fwAq3oKjodMDsgGMo59HApJpzHYyQhwuKHez3VLdGPss4aeq50 > +Yc/UNhuMor31JWkPHzy05oSEFOQeKFn8Trw//OJ8m2giZSopt/05E8NRu9MIpUw > +9eEsetJHs0502XCEFQ206/6MLxleGLA/sM5HTWJHg0NJczobTsHo40myy201Y1j > Q7tO/gsyRzwljbHf0XByTTYUQNaNCaTzH0ydLiVeWCaPfxCpF4DXzrzdBu+BrL8U > n5BlaizxMp9vd5DPucbRZidC0ihQpcaMjBAXnwg3OtbltX5EsMEYOfgD/TQXh5PC > PFTPRm21OaybgNj13hNOOfmOCDw5AAA+znyVPFl4Ao+z67w0jIgSre49HMXfzYJQ > a2pcDzCUuvbtXl22LJBVcnqlISLETiShulRzvAF5OiYwe2bJS4fOdWNSB8Nn7L7A > +x//HxvTOem1dG5CaFRkCxvnkvK30e4LNCwY0AfErt3eKahHj0rJA+w/qiodTg2U > bzh8kgRv+9v0fqV3RKVV/nO7WFRlyN6QIalCvLKPC+9CdajvBPUVC+gZgizs4pjT > osHuIcGPmXMzycj1FfXzym5ucdy/WlJPUIBtliA4XnJ/RdBu1WfdB0c6rruiNflW > vp1dKzQjPx5Zv58BU2l1 > =pI9J > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- ~ Prashant Kadam
Re: Stream closed- IOException exception
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Prashant, On 2/28/14, 7:54 AM, Prashant Kadam wrote: > thanks Mark and Konstantin for your reply > > If you create the simplest possible JSP that demonstrates the > issue (start with the one you have and remove as much as you can) > and then post that JSP here, we can take a look. > >>> as you can see in stacktrace, there are many jsps forwarding >>> request to > another jsp, i am not sure how can I post jsp code. also one > observation is, there is a struts action forward in between means > jsp-> struts action -> jsp , If I remove this action call and > include jsp directly in jsp then its working ... whether something > wrong with tiles or struts or tomcat .. ? If you are doing a lot of JSP forwarding, you could be generating a lot of useless whitespace that is all being sent to the output buffer. Once that buffer fills up, the response headers will be sent to the client and and response is therefore committed. If my analysis is correct, the difference between the Tomcat versions probably comes down to some small change in the way JSPs are compiled which may generate more whitespace if you haven't been careful. Take a look at all the JSPs that are participating in the request -- you should be able to inspect them to see why they might be generating whitespace. Remember, newlines are whitespace ;) I can see from your stack trace that you are using *includes*. Is there some other error that is occurring before this one? Does it happen on every request to this resource? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEOt7AAoJEBzwKT+lPKRY6fYP+wWFNBtLRjUi1m6NPPpxajyp NBp0SZ5TIBs9c1fwAq3oKjodMDsgGMo59HApJpzHYyQhwuKHez3VLdGPss4aeq50 +Yc/UNhuMor31JWkPHzy05oSEFOQeKFn8Trw//OJ8m2giZSopt/05E8NRu9MIpUw +9eEsetJHs0502XCEFQ206/6MLxleGLA/sM5HTWJHg0NJczobTsHo40myy201Y1j Q7tO/gsyRzwljbHf0XByTTYUQNaNCaTzH0ydLiVeWCaPfxCpF4DXzrzdBu+BrL8U n5BlaizxMp9vd5DPucbRZidC0ihQpcaMjBAXnwg3OtbltX5EsMEYOfgD/TQXh5PC PFTPRm21OaybgNj13hNOOfmOCDw5AAA+znyVPFl4Ao+z67w0jIgSre49HMXfzYJQ a2pcDzCUuvbtXl22LJBVcnqlISLETiShulRzvAF5OiYwe2bJS4fOdWNSB8Nn7L7A +x//HxvTOem1dG5CaFRkCxvnkvK30e4LNCwY0AfErt3eKahHj0rJA+w/qiodTg2U bzh8kgRv+9v0fqV3RKVV/nO7WFRlyN6QIalCvLKPC+9CdajvBPUVC+gZgizs4pjT osHuIcGPmXMzycj1FfXzym5ucdy/WlJPUIBtliA4XnJ/RdBu1WfdB0c6rruiNflW vp1dKzQjPx5Zv58BU2l1 =pI9J -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stream closed- IOException exception
thanks Mark and Konstantin for your reply If you create the simplest possible JSP that demonstrates the issue (start with the one you have and remove as much as you can) and then post that JSP here, we can take a look. >> as you can see in stacktrace, there are many jsps forwarding request to another jsp, i am not sure how can I post jsp code. also one observation is, there is a struts action forward in between means jsp-> struts action -> jsp , If I remove this action call and include jsp directly in jsp then its working ... whether something wrong with tiles or struts or tomcat .. ? >> stuck on this for long time and need to resolve it ASAP .. please help ... On Fri, Feb 28, 2014 at 2:47 PM, Mark Thomas wrote: > On 28/02/2014 09:11, Prashant Kadam wrote: > > Hi > > > > I am in process of upgrading from tomcat 7.0.33 to 7.0.52 but I am facing > > IOException: Stream closed in one of the layout jsp. Underlying > exception > > is jasper exception - *org.apache.jasper.JasperException: > > java.lang.IllegalStateException: Response has already been committed*. > > Same code is working in 7.0.33 so I doubt that it is happening due to > some > > changes in tomcat so I found out the version from this issue starts. > > Everything works perfect till v7.0.37 and problem starts with v7.0.39. > > I started looking the change log for these versions and I can see is > > "Use the newly added improved UTF-8 decoder for decoding UTF-8 encoded > URIs > > and UTF-8 encoded request bodies. Invalid UTF-8 URIs will not cause an > > error but will make use of the replacement character when an error is > > detected. This will allow web applications to handle the URI which will > > most likely result in a 404 response. The fall-back to decoding with > > ISO-8859-1 if UTF-8 decoding fails has been removed. *Invalid UTF-8 > > sequences in a request body will trigger an IOException.* The way the > > decoder is used has also been improved. The notable change is that > invalid > > sequences at the end of the input now trigger an error rather than being > > silently swallowed. (markt) " > > > > so want to confirm whether this can be the root cause ? > > It doesn't sound like it as you are writing a response body, not reading > a request body. > > > if not what would > > be the issue - as it works till version 7.0.37 and do not work after > > version 7.0.39 ? > > If you create the simplest possible JSP that demonstrates the issue > (start with the one you have and remove as much as you can) and then > post that JSP here, we can take a look. > > > and how to fix this in the code ? > > That will depend on the root cause of the problem. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- ~ Prashant Kadam
Re: Stream closed- IOException exception
also for other navigation in my application, i can see below exception line with all the already posted stack trace ... javax.servlet.jsp.JspException: javax.servlet.jsp.JspException: javax.servlet.jsp.JspException: org.apache.jasper.JasperException: java.lang.IllegalStateException: Exception occurred when flushing data On Fri, Feb 28, 2014 at 5:09 PM, Prashant Kadam wrote: > Please find below stack trace > > > Feb 28, 2014 4:50:10 PM org.apache.catalina.core.ApplicationDispatcher > invoke > SEVERE: Servlet.service() for servlet jsp threw exception > java.io.IOException: Stream closed > at > org.apache.jasper.runtime.JspWriterImpl.ensureOpen(JspWriterImpl.java:210) > at > org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:115) > at > org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:190) > at > org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:126) > at > org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:80) > at > org.apache.jsp.features.common.taskpane.viewListPane_jsp._jspService(viewListPane_jsp.java:280) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487) > at > org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412) > at > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339) > at > org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1083) > at > org.apache.struts.tiles2.TilesRequestProcessor.doForward(TilesRequestProcessor.java:159) > at > org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:396) > at > org.apache.struts.tiles2.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:211) > at > com.web.features.common.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:39) > at > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:232) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) > at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:605) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:544) > at > org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:954) > at > org.apache.jasper.runtime.PageContextImpl.doInclude(PageContextImpl.java:684) > at > org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:678) > at > org.apache.tiles.jsp.context.JspTilesRequestContext.include(JspTilesRequestContext.java:103) > at > org.apache.tiles.jsp.context.JspTilesRequestContext.dispatch(JspTilesRequestContext.java:96) > at > org.apache.tiles.renderer.impl.TemplateAttributeRenderer.write(TemplateAttributeRenderer.java:44) > at > org.apache.tiles.renderer.impl.AbstractBaseAttributeRenderer.render(AbstractBaseAttributeRenderer.java:106) > at > org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:670) > at > org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:690) > at > org.apache.tiles.impl.BasicTilesContainer.renderContext(BasicTilesContainer.java:179) > at > org.apache.tiles.template.InsertTemplateModel.end(InsertTemplateModel.java:101) > at > org.apache.tiles.jsp.taglib.InsertTemplateTag.doTag(InsertTemplateTag.java:255) > at > org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_tiles_005finsertTemplate_005f0(leftTaskPane_jsp.java:1132) > at > org.apache.jsp.features.common.leftTaskPane_jsp._jspx
Re: Stream closed- IOException exception
Please find below stack trace Feb 28, 2014 4:50:10 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.io.IOException: Stream closed at org.apache.jasper.runtime.JspWriterImpl.ensureOpen(JspWriterImpl.java:210) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:115) at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:190) at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:126) at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:80) at org.apache.jsp.features.common.taskpane.viewListPane_jsp._jspService(viewListPane_jsp.java:280) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339) at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1083) at org.apache.struts.tiles2.TilesRequestProcessor.doForward(TilesRequestProcessor.java:159) at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:396) at org.apache.struts.tiles2.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:211) at com.web.features.common.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:39) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:232) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:605) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:544) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:954) at org.apache.jasper.runtime.PageContextImpl.doInclude(PageContextImpl.java:684) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:678) at org.apache.tiles.jsp.context.JspTilesRequestContext.include(JspTilesRequestContext.java:103) at org.apache.tiles.jsp.context.JspTilesRequestContext.dispatch(JspTilesRequestContext.java:96) at org.apache.tiles.renderer.impl.TemplateAttributeRenderer.write(TemplateAttributeRenderer.java:44) at org.apache.tiles.renderer.impl.AbstractBaseAttributeRenderer.render(AbstractBaseAttributeRenderer.java:106) at org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:670) at org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:690) at org.apache.tiles.impl.BasicTilesContainer.renderContext(BasicTilesContainer.java:179) at org.apache.tiles.template.InsertTemplateModel.end(InsertTemplateModel.java:101) at org.apache.tiles.jsp.taglib.InsertTemplateTag.doTag(InsertTemplateTag.java:255) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_tiles_005finsertTemplate_005f0(leftTaskPane_jsp.java:1132) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_c_005fwhen_005f3(leftTaskPane_jsp.java:1101) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_c_005fchoose_005f3(leftTaskPane_jsp.java:1065) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_c_005fforEach_005f1(leftTaskPane_jsp.java:932) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_c_005fif_005f2(leftTaskPane_jsp.java:881) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_widgets_005fsectioncontent_005f1(leftTaskPane_jsp.java:823) at org.apache.jsp.features.common.leftTaskPane_jsp._
Re: Stream closed- IOException exception
2014-02-28 13:11 GMT+04:00 Prashant Kadam : > Hi > > I am in process of upgrading from tomcat 7.0.33 to 7.0.52 but I am facing > IOException: Stream closed in one of the layout jsp. Underlying exception > is jasper exception - *org.apache.jasper.JasperException: > java.lang.IllegalStateException: Response has already been committed*. It is odd to have an IOException to "be caused by" IllegalStateException. Is IOException thrown by your code, or by Tomcat's? What is the full exceptions chain here, with stack traces? > Same code is working in 7.0.33 so I doubt that it is happening due to some > changes in tomcat so I found out the version from this issue starts. > Everything works perfect till v7.0.37 and problem starts with v7.0.39. > I started looking the change log for these versions and I can see is > "Use the newly added improved UTF-8 decoder for decoding UTF-8 encoded URIs > and UTF-8 encoded request bodies. Invalid UTF-8 URIs will not cause an > error but will make use of the replacement character when an error is > detected. This will allow web applications to handle the URI which will > most likely result in a 404 response. The fall-back to decoding with > ISO-8859-1 if UTF-8 decoding fails has been removed. *Invalid UTF-8 > sequences in a request body will trigger an IOException.* The way the > decoder is used has also been improved. The notable change is that invalid > sequences at the end of the input now trigger an error rather than being > silently swallowed. (markt) " > > so want to confirm whether this can be the root cause ? if not what would > be the issue - as it works till version 7.0.37 and do not work after > version 7.0.39 ? and how to fix this in the code ? > > -- > ~ Prashant Kadam - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stream closed- IOException exception
On 28/02/2014 09:11, Prashant Kadam wrote: > Hi > > I am in process of upgrading from tomcat 7.0.33 to 7.0.52 but I am facing > IOException: Stream closed in one of the layout jsp. Underlying exception > is jasper exception - *org.apache.jasper.JasperException: > java.lang.IllegalStateException: Response has already been committed*. > Same code is working in 7.0.33 so I doubt that it is happening due to some > changes in tomcat so I found out the version from this issue starts. > Everything works perfect till v7.0.37 and problem starts with v7.0.39. > I started looking the change log for these versions and I can see is > "Use the newly added improved UTF-8 decoder for decoding UTF-8 encoded URIs > and UTF-8 encoded request bodies. Invalid UTF-8 URIs will not cause an > error but will make use of the replacement character when an error is > detected. This will allow web applications to handle the URI which will > most likely result in a 404 response. The fall-back to decoding with > ISO-8859-1 if UTF-8 decoding fails has been removed. *Invalid UTF-8 > sequences in a request body will trigger an IOException.* The way the > decoder is used has also been improved. The notable change is that invalid > sequences at the end of the input now trigger an error rather than being > silently swallowed. (markt) " > > so want to confirm whether this can be the root cause ? It doesn't sound like it as you are writing a response body, not reading a request body. > if not what would > be the issue - as it works till version 7.0.37 and do not work after > version 7.0.39 ? If you create the simplest possible JSP that demonstrates the issue (start with the one you have and remove as much as you can) and then post that JSP here, we can take a look. > and how to fix this in the code ? That will depend on the root cause of the problem. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
