Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 75388 invoked from network); 15 Jan 2002 15:24:47 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Jan 2002 15:24:47 -0000 Received: (qmail 27417 invoked by uid 97); 15 Jan 2002 15:24:40 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 27392 invoked by uid 97); 15 Jan 2002 15:24:39 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 27381 invoked from network); 15 Jan 2002 15:24:39 -0000 Message-ID: <000b01c19dd8$2db15e20$ec960040@allegro> Reply-To: "Tom Drake" From: "Tom Drake" To: "Tomcat Developers List" References: <002d01c19db4$f5d5d3f0$6501a8c0@apache.org> Subject: Re: [PATCH] JvmRoute changes w/attachments Date: Tue, 15 Jan 2002 07:20:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. 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" 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 to | get some comments here :) | | Remy | | | -- | To unsubscribe, e-mail: | For additional commands, e-mail: | | | -- To unsubscribe, e-mail: For additional commands, e-mail: