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); }
}
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
