tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28161] - Replication messages get lost with AsyncSocketSender
Date Fri, 02 Apr 2004 16:45:40 GMT
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 rainer.jung@kippdata.de  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message