-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tsirkin,
On 10/25/2009 8:10 AM, Tsirkin Evgeny wrote: > However even if some > session got _ not _ to be replicated after a restart - this is far > less a problem then a case of _ all _ session not to be restored > after a restart. Yeah, it's simple: just write a file to the disk before shutdown and read it back in after shutdown. When reading-in the persisted sessions, go ahead and publish them to the cluster. Hang on, if you have 5 nodes in the cluster, you'll write 5 files and then read 5 files back into Tomcat. And then each node will broadcast those sessions to all the other nodes. If you have 100 sessions stored, you'll have 5 servers * 100 sessions = 500 messages sent throughout the cluster, where each node has to read the message and attempt to create a new session or update an old one. Should the node accept the replacement session or keep its existing one? Or, should it scan both and do some sort of diff? You're right, that's starting to sound crazy. Instead, it's a simple case of choosing a single node to act as the controller for the cluster. Just add a configuration parameter to the <Cluster> element to identify one server as the controller and have /that/ one manage the sessions when the cluster is shut down. Hang on, there's no "shutdown cluster" message that all nodes understand. So, let's add that. But wait, what happens if the cluster controller goes down? We need a backup for the cluster controller. Let's add a backup for the cluster controller, and then a backup for the backup, and then a backup for the backup for the backup... Now do you see why this hasn't been implemented? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrl6L8ACgkQ9CaO5/Lv0PDdoACfR6+VP3xSV+17TdKs2759Z0fU gjAAnA5IDckHoO8AClD7Q1X+ArGl+Qte =0cmc -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
