-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark,
On 7/19/2010 6:00 PM, Mark Thomas wrote: > On 19/07/2010 22:36, Christopher Schultz wrote: >> Mark, >> >> On 7/19/2010 1:07 PM, Mark Thomas wrote: >>> Testing shows that it is caused by using async session replication. If >>> you use synchronous replication that ensures messages are processed on >>> the receiving nodes in the order they are sent. Asynchronous replication >>> in conjunction with the fact the the receiving node uses a thread pool >>> to process messages means that it is possible for messages to be >>> processed out of sequence. If a session invalidate is processed before >>> and update then you'll see this error. >> >> I am by no means an expert on Tomcat clustering (nor any other container >> clustering for that matter), but it seems to me that a potential >> solution would be to use a replication queue something like this: >> >> Client event -> server queue -> event handled >> ^ ^ >> server thread pool server replication thread pool >> >> If the queue were synchronized and a priority queue (based upon >> timestamp) or queueing were guaranteed on the basis of event reception, >> then the use of asynchronous versus synchronous replication should >> always result in deterministic replication behavior. > > Not sure what you are proposing here. > > Async replication means that multiple messages for a single session may > be sent from node A before node B has a chance to process them. Duh. No amount of queuing can fix that. I obviously wasn't thinking very clearly... I was thinking about a server (meaning the receiving node) processing the events out-of-order after it had received them (or as part of a non-deterministic event-processing thread priority) rather than the client failing to send them in a timely manner. > I think this comes down to a simple trade-off between performance > (async) and deterministic (sync) behaviour. I think the constraints you > would have to impose to make the async deterministic would remove most > of the benefits. Agreed. Something that could be done is that this error message might be demoted from SEVERE to WARNING if async replication is being used. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxEzIwACgkQ9CaO5/Lv0PDjogCeNhn487GRHsNUG4ys1FA7Gsss VNAAnibzqtKWhVx7GSw1wNbqj9aMM4XK =q+n/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
