-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxExXAACgkQ9CaO5/Lv0PDeegCgvZeiKaApROcZguagjOmEcDhB
GbcAnjg48ECuBvfYBRau0hMjnZlyYYi3
=UnUy
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
