Clearly, the jvmRoute must uniquely identify each TC instance in a cluster. The fact that it is an 'attribute' of the Engine object means that it may be specified in server.xml (as an attribute of the Engine tag). However, there is no reason it couldn't be assigned in a different, more automatic, way.
It's conceivable that Apache / mod_webapp could assign this value (a sequential number) to each worker that it knows about. The mod_webapp protocol would need to support this. <newSubject> Having said that, it would be nice if we could dynamically add new tc instances to an Apache managed cluster. The fail-over session management code I've written already does this, but Apache needs to know about new workers too. This means that when you add a new tc instance (session repository) to the cluster, it will discover the other tc's, announce it's arrival, and request a copy of all known sessions, all tc's will begin sending it new / updated sessions. However, if Apache doesn't know about the new worker, it will never send it any web traffic. Tom ----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, January 15, 2002 3:08 AM Subject: Re: [PATCH] JvmRoute changes w/attachments | > Couldn't we have an automatic jvmRoute generated from | > misc entropy if the entry is not present in server.xml ? | > for example just the server hostname or ip address ? | > | > Adding the hostname/adress should be fine for the majority of case | > where only one JVM will be make run TC 4.x by system. | > | > Or may be just the md5 of the hostname which could be pretty | > long. | > | > The goal is to avoid touching server.xml when you deploy | > TC 4.x on many boxes and you don't want admin to touch ALL | > server.xml | > | > And since you keep the server.xml setting you could tune | > easily specific case (ie, many TC 4.x on the same machine) | | Or maybe we can just use the engine name, if we state that in that case it | should be uinque inside the cluster. | Notice that I didn't port the patch to the 4.0 branch yet; I just wanted to | get some comments here :) | | Remy | | | -- | To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> | For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> | | | -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
