You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <hg...@apache.org> on 2004/02/05 10:30:12 UTC
Re: failover-problem and session mixup: jakarta-tomcat-connectors:
jk_ajp_common.c
jean-frederic clere a écrit :
> Henri Gomez wrote:
>
>> Alexander Schwartz a écrit :
>>
>>> Hello Tomcat-Developers,
>>>
>>> we are currently experiencing some problems with mod_jk with
>>> loadbalancing:
>>> (A) when a post-request fails while receiving data from tomcat, the
>>> loadbalancer tries to send the request to the other tomcat, but
>>> "forgets" the post body content (i.e. login and password submitted by
>>> the user). The size of the body content is only a few bytes (< 100), so
>>> it's not the "known" problem with bodies longer than 8k.
>>> (B) it seems that sometimes after a POST-failover body data from an
>>> old request is sent to the other tomcat when the first connection
>>> failed. This leads to a session mix-up & user mix-up!
>>>
>>> The setup is a simple cluster configuration: one apache httpd with
>>> mod_ssl in front, mod_jk with one configured loadbalance worker with
>>> sticky sessions and two child ajp13 workers in the middle, two tomcats
>>> in the back.
>>> Versions involved: mod_jk 1.2.4, Tomcat 4.1.27 (but also tested with
>>> mod_jk 1.2.5 and Tomcat 4.1.29). Apache on AIX, version 1.3.29. The
>>> latest version of jk_ajp_common.c in CVS don't seem to have relevant
>>> changes. We have searched the mailinglists, the only source I have found
>>> is in tomcat-user-mailinglist where Jean-Philippe Belanger describes a
>>> similar problem in the mails from 14 Jan 2004 (the empty POST body) and
>>> 12 Jan 2004 (the empty POST body and the session mixup). He didn't
>>> investigate further but got himself a cisco load balancer. Another post
>>> is here, but I found no replies/solutions.
>>>
>>> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg48833.html
>>>
>>> (A) can be reproduced quite easily using "netcat" as a simulator of the
>>> first tomcat and a second real tomcat. If you kill netcat after it has
>>> accepted a POST-connection from a mod_jk, mod_jk will forward the
>>> request to the other tomcat without the POST-body
>>> But we can't reproduce (B), but it has definitely happened. We suspect
>>> that POST-Recovery code might send an old request body while executing
>>> the following statements. Please note that the log statement refers to
>>> op->reply while the following if statement refers to op->post! (this is
>>> cut and paste from the orginal source):
>>
>>
>>
>> It used to works but it was before the content-header add-on code.
>>
>> This piece of is a nightmare, and I see no easier solution than
>> copying the HEAD+POST in temp buffer but I'd like to have Bill, Mladen
>> and JFC advices...
>
>
> That is what I am doing in the modified mod_jk2 I use to connect to
> embbed tomcats.
Hi JF,
Do you means that you're using separate buffers for HEAD/POST ?
Could it be backported to jk ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: failover-problem and session mixup: jakarta-tomcat-connectors:
jk_ajp_common.c
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere a écrit :
> Henri Gomez wrote:
>
>> jean-frederic clere a écrit :
>>
>>> Henri Gomez wrote:
>>>
>>>> Alexander Schwartz a écrit :
>>>>
>>>>> Hello Tomcat-Developers,
>>>>>
>>>>> we are currently experiencing some problems with mod_jk with
>>>>> loadbalancing:
>>>>> (A) when a post-request fails while receiving data from tomcat, the
>>>>> loadbalancer tries to send the request to the other tomcat, but
>>>>> "forgets" the post body content (i.e. login and password submitted by
>>>>> the user). The size of the body content is only a few bytes (<
>>>>> 100), so
>>>>> it's not the "known" problem with bodies longer than 8k.
>>>>> (B) it seems that sometimes after a POST-failover body data from an
>>>>> old request is sent to the other tomcat when the first connection
>>>>> failed. This leads to a session mix-up & user mix-up!
>>>>>
>>>>> The setup is a simple cluster configuration: one apache httpd with
>>>>> mod_ssl in front, mod_jk with one configured loadbalance worker with
>>>>> sticky sessions and two child ajp13 workers in the middle, two tomcats
>>>>> in the back.
>>>>> Versions involved: mod_jk 1.2.4, Tomcat 4.1.27 (but also tested with
>>>>> mod_jk 1.2.5 and Tomcat 4.1.29). Apache on AIX, version 1.3.29. The
>>>>> latest version of jk_ajp_common.c in CVS don't seem to have relevant
>>>>> changes. We have searched the mailinglists, the only source I have
>>>>> found
>>>>> is in tomcat-user-mailinglist where Jean-Philippe Belanger describes a
>>>>> similar problem in the mails from 14 Jan 2004 (the empty POST body)
>>>>> and
>>>>> 12 Jan 2004 (the empty POST body and the session mixup). He didn't
>>>>> investigate further but got himself a cisco load balancer. Another
>>>>> post
>>>>> is here, but I found no replies/solutions.
>>>>>
>>>>> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg48833.html
>>>>>
>>>>>
>>>>> (A) can be reproduced quite easily using "netcat" as a simulator of
>>>>> the
>>>>> first tomcat and a second real tomcat. If you kill netcat after it has
>>>>> accepted a POST-connection from a mod_jk, mod_jk will forward the
>>>>> request to the other tomcat without the POST-body
>>>>> But we can't reproduce (B), but it has definitely happened. We suspect
>>>>> that POST-Recovery code might send an old request body while executing
>>>>> the following statements. Please note that the log statement refers to
>>>>> op->reply while the following if statement refers to op->post!
>>>>> (this is
>>>>> cut and paste from the orginal source):
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It used to works but it was before the content-header add-on code.
>>>>
>>>> This piece of is a nightmare, and I see no easier solution than
>>>> copying the HEAD+POST in temp buffer but I'd like to have Bill,
>>>> Mladen and JFC advices...
>>>
>>>
>>>
>>>
>>> That is what I am doing in the modified mod_jk2 I use to connect to
>>> embbed tomcats.
>>
>>
>>
>> Hi JF,
>>
>> Do you means that you're using separate buffers for HEAD/POST ?
>
>
> No: I am storing all until I get the end (max 30000 bytes).
>
>>
>> Could it be backported to jk ?
>>
>
> I need time to answer the question...
> But I think we have already something in common/jk_ajp_common.c
> otherwise what op->request and op->post were for?
I added the post for such purpose, so I still wonder where is the problem
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: failover-problem and session mixup: jakarta-tomcat-connectors:
jk_ajp_common.c
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> jean-frederic clere a écrit :
>
>> Henri Gomez wrote:
>>
>>> Alexander Schwartz a écrit :
>>>
>>>> Hello Tomcat-Developers,
>>>>
>>>> we are currently experiencing some problems with mod_jk with
>>>> loadbalancing:
>>>> (A) when a post-request fails while receiving data from tomcat, the
>>>> loadbalancer tries to send the request to the other tomcat, but
>>>> "forgets" the post body content (i.e. login and password submitted by
>>>> the user). The size of the body content is only a few bytes (< 100), so
>>>> it's not the "known" problem with bodies longer than 8k.
>>>> (B) it seems that sometimes after a POST-failover body data from an
>>>> old request is sent to the other tomcat when the first connection
>>>> failed. This leads to a session mix-up & user mix-up!
>>>>
>>>> The setup is a simple cluster configuration: one apache httpd with
>>>> mod_ssl in front, mod_jk with one configured loadbalance worker with
>>>> sticky sessions and two child ajp13 workers in the middle, two tomcats
>>>> in the back.
>>>> Versions involved: mod_jk 1.2.4, Tomcat 4.1.27 (but also tested with
>>>> mod_jk 1.2.5 and Tomcat 4.1.29). Apache on AIX, version 1.3.29. The
>>>> latest version of jk_ajp_common.c in CVS don't seem to have relevant
>>>> changes. We have searched the mailinglists, the only source I have
>>>> found
>>>> is in tomcat-user-mailinglist where Jean-Philippe Belanger describes a
>>>> similar problem in the mails from 14 Jan 2004 (the empty POST body) and
>>>> 12 Jan 2004 (the empty POST body and the session mixup). He didn't
>>>> investigate further but got himself a cisco load balancer. Another post
>>>> is here, but I found no replies/solutions.
>>>>
>>>> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg48833.html
>>>>
>>>> (A) can be reproduced quite easily using "netcat" as a simulator of the
>>>> first tomcat and a second real tomcat. If you kill netcat after it has
>>>> accepted a POST-connection from a mod_jk, mod_jk will forward the
>>>> request to the other tomcat without the POST-body
>>>> But we can't reproduce (B), but it has definitely happened. We suspect
>>>> that POST-Recovery code might send an old request body while executing
>>>> the following statements. Please note that the log statement refers to
>>>> op->reply while the following if statement refers to op->post! (this is
>>>> cut and paste from the orginal source):
>>>
>>>
>>>
>>>
>>> It used to works but it was before the content-header add-on code.
>>>
>>> This piece of is a nightmare, and I see no easier solution than
>>> copying the HEAD+POST in temp buffer but I'd like to have Bill,
>>> Mladen and JFC advices...
>>
>>
>>
>> That is what I am doing in the modified mod_jk2 I use to connect to
>> embbed tomcats.
>
>
> Hi JF,
>
> Do you means that you're using separate buffers for HEAD/POST ?
No: I am storing all until I get the end (max 30000 bytes).
>
> Could it be backported to jk ?
>
I need time to answer the question...
But I think we have already something in common/jk_ajp_common.c otherwise what
op->request and op->post were for?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org