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. The issue is that if multiple session update messages from node A are in node B's input queue and B processes that queue with multiple threads, it is possible - depending on thread prioritisation - for node B to process the messages out of order even if node B removes them from its queue in order. Fixing it would require limiting node B to processing a single message per session from node A at a time. (assuming messages were send and received in order). 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. As an aside, if a UA sends multiple requests in parallel to a single node then you have little control of the order that events will occur in the session anyway. > I'm interested to know why synchronous replication solves this > problem... is it a client event queuing problem when asynchronous > replication is used? Or does either the client or the server serialize > processing of replication events in some way only when synchronous > replication is being used? Synchronous replication essentially ensures that node B only ever has at most one message from node A for a single session and therefore has to process them in order. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
