Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Subject: Re: failover-problem and session
	mixup:	jakarta-tomcat-connectors/mod_jk: jk_ajp_common.c
From: Alexander Schwartz <alexander.schwartz@gmx.net>
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
In-Reply-To: <40220BCD.4070502@apache.org>
References: <1075151098.1353.44.camel@centre.schwartz.local>
	 <4016993A.1080206@apache.org>
	 <1075928563.1340.28.camel@centre.schwartz.local>
	 <40220BCD.4070502@apache.org>
Content-Type: multipart/mixed; boundary="=-mwrT5GQG+oOVAqiEOk4p"
Message-Id: <1076010981.957.29.camel@centre.schwartz.local>
Mime-Version: 1.0
Date: Thu, 05 Feb 2004 20:56:21 +0100

--=-mwrT5GQG+oOVAqiEOk4p
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

> > I'd really like to use mod_jk open source software in our production
> > environment, but I need to make sure it's strong enough for production.
> > I need some advice on the two issues (as far as I can see there has been
> > no commit on CVS and/or discussion results)
> > 
> >    * do you think the POST-recovery caused the session mix-up?
> > 
> >    * does our patch successfully eliminate the problem by disabling 
> >      POST-recovery?
> 
> I'd like to see this recovery fixed instead of removing it.

but I need something working now :( -- thefore I asked if my code is a
working, although i know it is not perfect seen with your eyes.

> The idea is to use buffers to store request datas (headers/datas).

OK, understood.

> What's the exact problem.
> You send request (headers / datas) to tomcat1.
> This one fail when sending reply or didn't reply at all ?

I don't know when the session mix up happens, and I was unable to
reproduce it. But I was to reproduce the following: 

   (a) mod_jk sends the request and data to tomcat1. Tomcat1 closes the
connection. mod_jk tries to recover and sends the request with no data
to the second tomcat. Sending no data is definitely wrong. I also argue
that this is dangerous as a transaction may be triggered twice by
sending the request a second time. 

Use netcat ("nc -l -p 8080") to simulate a tomcat1 on port 8080
receiving the headers. Press ^C to simulate the failure of tomcat1. Use
a "real" tomcat2 for failover.

   (b) mod_jk sends the request and data to tomcat1. mod_jk receives
header and data from tomcat, but the response is not yet complete.
tomcat1 closes the connection. mod_jk tries to recover and sends the
request with no data to the second tomcat. The output of the second
tomcat is appended to the output of the first tomcat. This is definitely
wrong.

I used the attached filter to set up a test case for this. Use two
tomcats, and shut down the first tomcat when it is processing its
request.

Alex.

> 
> > ------------------------------------------------------------------------
> > 
> > --- jk_ajp_common.c.old	Fri Jan 23 16:26:12 2004
> > +++ jk_ajp_common.c	Fri Jan 23 16:28:02 2004
> > @@ -963,10 +963,16 @@
> >       * or Tomcat crashed. In any case we cannot recover this.
> >       */
> >  
> > +    // as+gj/20040123: we don't want to try the buggy POST recovery as it
> > +    // seems to repost buggy data 
> > +    // BUT: doesn't work!
> > +    // op->recoverable = JK_FALSE;
> > +
> >      jk_log(l, JK_LOG_DEBUG,
> >             "ajp_send_request 2: "
> > -           "request body to send %d - request body to resend %d\n", 
> > -           ae->left_bytes_to_send, jk_b_get_len(op->reply) - AJP_HEADER_LEN);
> > +           "request body to send %d - request body to resend %d/%d\n", 
> > +           ae->left_bytes_to_send, jk_b_get_len(op->reply) - AJP_HEADER_LEN,
> > +           jk_b_get_len(op->post) - AJP_HEADER_LEN);
> >  
> >      /*
> >       * POST recovery job is done here.
> > @@ -977,10 +983,18 @@
> >       * remote Tomcat
> >       */
> >      if (jk_b_get_len(op->post) > AJP_HEADER_LEN) {
> > -        if(!ajp_connection_tcp_send_message(ae, op->post, l)) {
> > -            jk_log(l, JK_LOG_ERROR, "Error resending request body\n");
> > -            return JK_FALSE;
> > -        }
> > +      // as+gj/20040123: seems to be buggy, doesn't fit the debug output
> > +      // above, customers complain about seeing wrong user's data when doing
> > +      // a login-POST
> > +      //  if(!ajp_connection_tcp_send_message(ae, op->post, l)) {
> > +      //      jk_log(l, JK_LOG_ERROR, "Error resending request body\n");
> > +      //      return JK_FALSE;
> > +      //  }
> > +      
> > +      // as+gj/20040123 recovery is disabled above shoudn't happen!
> > +      jk_log(l, JK_LOG_ERROR, "Shouldn't be here resending request body! (as+gj/20040123)\n");
> > +      op->recoverable = JK_FALSE;
> > +      return JK_FALSE;
> >      }
> >      else {
> >          /* We never sent any POST data and we check if we have to send at
> > @@ -1009,6 +1023,8 @@
> >              s->content_read = len;
> >              if (!ajp_connection_tcp_send_message(ae, op->post, l)) {
> >                  jk_log(l, JK_LOG_ERROR, "Error sending request body\n");
> > +                // as+gj/20040123
> > +                op->recoverable = JK_FALSE;
> >                  return JK_FALSE;
> >              }  
> >          }
> > @@ -1279,6 +1295,9 @@
> >                       * receiving upload data and we must consider that
> >                       * operation is no more recoverable
> >                       */
> > +                    // as+gj/20040123:
> > +                    // don't want to recover
> > +                    op->recoverable = JK_FALSE;
> >                      if (! op->recoverable) {
> >                          *is_recoverable_error = JK_FALSE;
> >                          jk_log(l, JK_LOG_ERROR,

-- 
Alexander Schwartz (alexander.schwartz@gmx.net)
http://www.ahus1.de

--=-mwrT5GQG+oOVAqiEOk4p
Content-Disposition: attachment; filename=EchoFilter.java
Content-Type: text/x-java; name=EchoFilter.java; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

package com.direkt1822.joba.filter;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * This is a filter that sends all data sent from the client back to the client
 * @author Alexander Schwartz (1822direkt) 2004
 * @version $Id: EchoFilter.java,v 1.1 2004/01/22 12:10:39 ahus1 Exp $
 */
public class EchoFilter implements Filter {
    
    public void init(FilterConfig filterConfig) throws ServletException {
    }

    public void doFilter(
        ServletRequest request,
        ServletResponse response,
        FilterChain chain)
        throws IOException, ServletException {

        final HttpServletRequest httpRequest =
            (HttpServletRequest)request;
        final HttpServletResponse httpResponse =
                (HttpServletResponse)response;
        BufferedReader reader = httpRequest.getReader();
        PrintWriter writer = httpResponse.getWriter();
        String line;
	try {
	for(int i=0; i<10; ++i) {
  	  Thread.sleep(1000);
	  writer.print(".");
	  writer.flush();
	} } catch (InterruptedException e) {
	}
        while((line = reader.readLine())!=null) {
          writer.println(line);
        }
    }

    public void destroy() {
    }
}


--=-mwrT5GQG+oOVAqiEOk4p
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--=-mwrT5GQG+oOVAqiEOk4p--