DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28161>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28161 Replication messages get lost with AsyncSocketSender ------- Additional Comments From [EMAIL PROTECTED] 2004-04-02 16:45 ------- I respect your sugestion to not use asynchronous, although it looked to me like the right way to do it. Just for your information: The messages really get lost, even after we stop load the missing messages don't get replicated. So it's not just a problem of messages getting replicated too late. There are definitely only debug log stetments all the time, except for a few info messages giving mean values for replication data size. No other non debug log statements on any cluster node. Also from what I see I'm pretty sure, that the replication data is written to the Socket. Concerning mod_jk: For this test case we used each session only once. So the correctness of the response through mod_jk somehow didn't matter. We could easily reproduce the same situation using build in Tomcat HTTP Connector (although we didn't do so until now). We will retry using pooled, although I don't like the idea of having up to 25 connections (code constant) and threads for each pair of nodes in the cluster. Also I had the impression, that in pooled mode TCP conections are only used a very short time (I think I remember for only 100 messages? This application will be under heavy load in production). Why do I think asynchronous fits better? In any synchronous situation if the replication is not fast enough I immediately get negative consequences for the application from the user point of view, because the request blocks ressources needed for accepting new requests as long as the replication hasn't finished. So if replication is slow for a few seconds I'm in danger of loosing all free Apache-Slots resp. Tomcat worker threads for incoming requests. When I do asynchronous replication I only loose timely replication of the sesion changes. If I route my request to the primary container, then I still profit from the cluster with respect to availability and servicability (I can shutdown one of the containers without users loosing sessions). For these features it doesn't really matter, if all request are replicated within milliseconds all the time. I'm sorry to bother you, but I think it's an important discussion. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
