Alexander Schwartz a écrit :

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.

Could you send a complete mod_jk.log in DEBUG mode ?


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.

netcat should handle AJP13, not HTTP, so it should be 8009.


   (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.

Strange, also I need a complete mod_jk.log for study.


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.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to