I conducted a little experiment to facilitate testing of load-balancing, stickyness etc. I wanted to use a single Tomcat instance with multiple connectors (ports) each of which using a different jvmRoute when generating sessions for requests coming in via the respective connector. That allows to test load-balancing and stickyness bahevior using a single Tomcat with multiple connectors, thus needing less resources and also making some testing easier (only one logs directory, automatically shared webapps, only one stop/start etc., less copying of configs etc.
I used the following patch to make this possible: http://people.apache.org/~rjung/patches/named-connectors.patch It adds a new attribute to the Connector (I have chosen to call it name, the connector's name, because jvmRoute is a route for a jvm, which is the whole process). Then it adds a new method to the Manager interface which allows to hand over a chosen id suffix when creating a new session. The new method is implemented in ManagerBase as usual, so all session manager implementations we bundle inherit it, except for DeltaManager, which gets some local additions. The optional suffix is handed down to the SessionIdGenerator. The wiring is done in the Request class which has access to the connector and triggers session creation. Only addition is accessing the connector name and forwarding it when creating a session. The rest is some minor stuff in AuthenticatorBase and JvmRouteBinderValve. The behavior should be unchanged unless a request comes in via a connector that has a name explicitly set. In that case the session id gets the connector name as a suffix instead of the jvmRoute from the Engine. Not contained in the patch is docs for the new name attribute and the addition for mbeans-descriptors.xml. Somehow it is a hack. On the other hand at least for my test setup is was pretty useful. Because of the method addition in the Manager interface I guess it is a no-go for TC 7. What do people think for TC 8? Is it useful or to much of a hack? Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
