Hello Henri, hello mod_jk-Developers,
Am Di, den 27.01.2004 schrieb Henri Gomez um 18:00:
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!
Could you try with the latest code from CVS, since your patch seems to be for an older version ?
From what I see in the code the datas in op->post are sent to the new tomcat so I don't see where can be the problem.
I'd like to see test case and dumps.
In fact we may have to rewrite the ajp_service():
1) Init Buffers request, post, reply.
2) Feed request buffer and if needed post buffer.
3) Iterate here :
4) Try to send request and if needed post datas to a tomcat.
5) Swith to another tomcat and retry.
A problem in such case is that if there is many POST datas we'll have a HUGE POST buffer and that datas won't be send to tomcat immediatly.
So a consensus should be found here :
- Make the web-server buffering the request/post, and then send to tomcat's.
- Keep the current behaviour, where jk feed the data to tomcat as soon as he get them.
I also wonder why the tomcat failed since using the prepost_timeout ping/pong could help you there.
Questions :
- Did Tomcat failed while handling the request or was allready broken before ?
- Did you clients used chunked transfert ?
- You say that sometimes after a POST-failover body data from an old request is sent to the other tomcat when the first connection failed. Do you means that the other tomcat get POST DATA which was never sent by the browser in this request ? Strange since the op->post is reset each time we service a new request.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
