tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Drake" <>
Subject Re: [PATCH] JvmRoute changes w/attachments
Date Tue, 15 Jan 2002 15:20:33 GMT
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,

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.

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.


----- Original Message -----
From: "Remy Maucherat" <>
To: "Tomcat Developers List" <>
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
| get some comments here :)
| Remy
| --
| To unsubscribe, e-mail:
| For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message