Re: 7.0.21 Redirects failing randomly

2011-09-27 Thread Jacob Champlin

Konstantin,

Ok, so I see now why you added the flushBuffer() from spec:

http://java.sun.com/javaee/6/docs/api/javax/servlet/http/HttpServletResponse.html#sendRedirect%28java.lang.String%29

"Sends a temporary redirect response to the client using the specified 
redirect location URL and clears the buffer."


Its just we have been running Tomcat, for 5 years and we have lots of 
code that relied on the fact that sendRedirect did not flush the buffer.


I will drop it, but going to be a while before we can go to 7.0.21.

Jacob

On 09/27/2011 02:32 PM, Jacob Champlin wrote:

Konstantin,

I believe the new flushBuffer() call you added to Response.java
sendRedirect() line #1340. Is breaking all ServletFilters but sending
buy flushing the response before filters have a chance to modify the
response.

Jacob



On 09/27/2011 10:35 AM, Jacob Champlin wrote:

Last night we went to 7.0.21, and this morning I had to roll it back
because very randomly redirects were failing. It was very much like all
parameters to the redirect were lost.

I am still trying to debug this, but its clear its not happening in
7.0.20, which leads me to believe its:

41718: Include a response body when sending a redirect. (markt)

or one of the AJP changes.

We are running Apache 2.2.21 with mod_ajp.

Our servlet framework is Stripes MVC and it seems to conform to the
requirement in 41718.

Is anyone else having this issue?

Thank you,
Jacob Champlin



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: 7.0.21 Redirects failing randomly

2011-09-27 Thread Jacob Champlin

Konstantin,

I believe the new flushBuffer() call you added to Response.java 
sendRedirect() line #1340.  Is breaking all ServletFilters but sending 
buy flushing the response before filters have a chance to modify the 
response.


Jacob



On 09/27/2011 10:35 AM, Jacob Champlin wrote:

Last night we went to 7.0.21, and this morning I had to roll it back
because very randomly redirects were failing. It was very much like all
parameters to the redirect were lost.

I am still trying to debug this, but its clear its not happening in
7.0.20, which leads me to believe its:

41718: Include a response body when sending a redirect. (markt)

or one of the AJP changes.

We are running Apache 2.2.21 with mod_ajp.

Our servlet framework is Stripes MVC and it seems to conform to the
requirement in 41718.

Is anyone else having this issue?

Thank you,
Jacob Champlin



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: 7.0.21 Redirects failing randomly

2011-09-27 Thread Konstantin Kolinko
2011/9/27 Jacob Champlin :
> We have finished debugging this issue.  It turns out that what is happening
> is in 7.0.21 responses are returning to the client before the filter chain
> is complete.  In 7.0.20 all filters complete before the response is returned
> to the client.

It depends on the size of your response and on the size of buffers.
See ServletResponse#isCommitted().

I do not see any issue with that, but maybe I do not fully understand you.
Can you provide a simple web application that demonstrates this?

>
> In our particular case, we have a TransactionFilter managing our DB
> transactions, so the response page was rendering before the DB transaction
> was commited giving the appearance that the post didn't succeed.
>
> I think this is a MAJOR regression in 7.0.21.
>
> Jacob Champlin

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: 7.0.21 Redirects failing randomly

2011-09-27 Thread Jacob Champlin
We have finished debugging this issue.  It turns out that what is 
happening is in 7.0.21 responses are returning to the client before the 
filter chain is complete.  In 7.0.20 all filters complete before the 
response is returned to the client.


In our particular case, we have a TransactionFilter managing our DB 
transactions, so the response page was rendering before the DB 
transaction was commited giving the appearance that the post didn't succeed.


I think this is a MAJOR regression in 7.0.21.

Jacob Champlin

On 09/27/2011 10:35 AM, Jacob Champlin wrote:

Last night we went to 7.0.21, and this morning I had to roll it back
because very randomly redirects were failing. It was very much like all
parameters to the redirect were lost.

I am still trying to debug this, but its clear its not happening in
7.0.20, which leads me to believe its:

41718: Include a response body when sending a redirect. (markt)

or one of the AJP changes.

We are running Apache 2.2.21 with mod_ajp.

Our servlet framework is Stripes MVC and it seems to conform to the
requirement in 41718.

Is anyone else having this issue?

Thank you,
Jacob Champlin



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: 7.0.21 Redirects failing randomly

2011-09-27 Thread Konstantin Kolinko
2011/9/27 Jacob Champlin :
> Last night we went to 7.0.21, and this morning I had to roll it back because
> very randomly redirects were failing.  It was very much like all parameters
> to the redirect were lost.
>
> I am still trying to debug this, but its clear its not happening in 7.0.20,
> which leads me to believe its:
>
> 41718: Include a response body when sending a redirect. (markt)

The change itself was
http://svn.apache.org/viewvc?rev=1156533&view=rev
http://svn.apache.org/viewvc?rev=1156603&view=rev

This sample page works for me:
(to be placed as /examples/testRedirect.jsp )
<%
response.sendRedirect(response.encodeRedirectURL(request.getContextPath() +
"/servlets/servlet/RequestParamExample?firstname=bar&lastname=baz"));
%>

Though I tried it with HTTP connector and not with AJP one.


>
> or one of the AJP changes.
>
> We are running Apache 2.2.21 with mod_ajp.
>
> Our servlet framework is Stripes MVC and it seems to conform to the
> requirement in 41718.
>
> Is anyone else having this issue?
>

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org