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 Mon, 05 Apr 2004 19:11:03 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-05 19:11 -------
First: there are app. 6 System.out.print/ln in the cluster code. One of these 
(line 71 in the SmartQueue.java) prevented me from finding the solution earlier.

Here is the SOLUTION: What happens is, that the "smart" feature of the smart 
queue gets us into trouble. For my JSP two session messages are being send. One 
is of type 1 (EVT_SESSION_CREATED), and the second one is of type 13 
(EVT_SESSION_DELTA). Both are being send very close to each other during the 
only request in a session.

Most of the time the system is fast enough to handle each message individually, 
before the next message is put into the queue. Every now and then the message 
of type 1 is not read from the queue before type 13 is generated. Then the 
queue replaces the type 1 message in the queue by the type 13 message, and only 
the type 13 message is send out. Then the receiving side seems to not create 
the session, since the type 1 message is missing. I didn't check this last 
point, because I think this is much clearer for you.

Isn't there a general problem in using the Delta manager together with the 
smart queue? Since you only send out delta messages, it doesn't look like a 
good idea to replace pending messages with newer ones. In fact isn't it 
necessary to send all deltas and to furthermore make sure, that they are send 
in the original order?

At least this makes clear, why the problem will only show up in asynchronous 
mode. In synchronous mode you will allways send all messages (and in the right 
order).

Maybe it suffices to strip off the "smart" feature of the smart queue?

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