Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 36540]  -
    pooled cluster replication does not seem ensure synchronized replication
 in tomcat 5.5.11
Message-Id: <20051004190152.3E265222@ajax.apache.org>
Date: Tue,  4 Oct 2005 21:01:52 +0200 (CEST)

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=36540>.
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=36540


------- Additional Comments From rainer.jung@kippdata.de  2005-10-04 21:01 -------
synchronous: send each session change to other cluster members before returning
response to client.

asychronous: same as synchronous, but use mutiple sender connections (use any
one, that is not currently busy).

fastasync: put session change message into local queue and then return response
to client. A seperate thread waits for messages coming into the queue and then
send the messages to the other cluster members.

waitforack: when ending the message, wait for an ACK type answering message from
the other cluster members before proceeding (make sending the messages more
reliable).

If one needs exact synchronization: synchronous are pooled mode with waitforack.
Application gets into trouble, when replication gets stuck.

If one can live with some latency between changes on the primary node and their
replication to the other nodes and on the other hand the cluster should
influence application performance and stability only very little: use session
stickyness in load balancers combined with fastasync and no waitforack.

synchronous/pooled without waitforack: lower latency for replication, although
synchronization is not exact.

fastasync with waitforack: decoupling replication from request/response but
ensuring that replication is checked for success.

You are right, we should make the docs more precise. The features are yet very
new and as usual documentation takes a while.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org