#2056 JvmRouteFilter crashes in init() method for clustered webapp

[Marco Antonioni]

Problem: JvmRouteFilter crashes in init() method for
clustered web apps.

Abstract: JvmRouteFilter crashes in init() method when
'distributable' tag is found in web.xml and cluster
configuration is used with 'jvmRoute' attribute in
'Engine' tag of server.xml tomcat5 configuration.

JBoss, JVM, OS versions:

Release ID: JBoss [Zion] 4.0.0 (build:
CVSTag=JBoss_4_0_0 date=200409200418)
Java version: 1.4.2_05,Sun Microsystems Inc.
Java VM: Java HotSpot(TM) Client VM 1.4.2_05-b04,Sun
Microsystems Inc.
OS-System: Windows XP 5.1,x86

Cluster composition/configuration:

1 Apache 2.x instance using mod_jk and sticky session
support
4 JBoss instances (2 acting as web front-end, 2 acting
as EJB back-end) on a single x86 node.
2 Tomcat5 instances (2 acting as front-end) are
configured for HTTP cluster session replication

deploy/jbossweb-tomcat50.sar/server.xml

..Engine jvmRoute="tomcat1" name="jboss.web"
defaultHost="localhost"..

Bug details:

During JBoss startup JvmRouteFilter.init() method
throws an exception
"JvmRouteFilter.init(): No AbstractJBossManager found
for clustering support."

this happens because the code

...
manager_ = (AbstractJBossManager)
filterConfig.getServletContext().getAttribute(AbstractJBossManager.class.getName());
...

returns null, there is no object registered with the key
"org.jboss.web.tomcat.tc5.session.AbstractJBossManager"

the manager is registered under key
"org.jboss.web.tomcat.tc5.session.JBossManager"

would be better to define a generic key independent
from class implementation, i've patched
JvmRouteFilter.init() method and now it is able to find
the manager object without crashing.

There is another uncorrect behaviour from method
'handleJvmRoute'; assume two tomcat instances named
'tomcat1' and 'tomcat2' into jvmRoute value, and apache
plugin using sticky session, when for example tomcat1
instance crashes the request is forwarded to tomcat2
instance, see log ...

...
DEBUG [org.jboss.web.tomcat.tc5.JvmRouteFilter]
doFilter(): check if need to re-route based on
JvmRoute. Session id: wZcAUdUzKc20wZ7BvlMH0g**.tomcat2
jvmRoute: tomcat1
DEBUG [org.jboss.web.tomcat.tc5.JvmRouteFilter]
handleJvmRoute(): We have detected a failover with
differen jvmRoute. old one: tomcat2 new one: tomcat1.
Will reset the session id.
DEBUG [org.jboss.web.tomcat.tc5.JvmRouteFilter]
handleJvmRoute(): NEW sid:
[wZcAUdUzKc20wZ7BvlMH0g**.tomcat1] response.class:
[org.apache.coyote.tomcat5.CoyoteResponseFacade]
DEBUG
[org.jboss.web.tomcat.tc5.session.JBossCacheManager]
Setting cookie with session
id:wZcAUdUzKc20wZ7BvlMH0g**.tomcat1 & name:JSESSIONID
...

this should happen only once, the first time the method
detect a different tomcatID in jvmRoute, because the id
is changed as from code

...
manager_.setNewSessionCookie(sid, response);
...

after the 'sid' have been changed from
'wZcAUdUzKc20wZ7BvlMH0g**.tomcat2' to
'wZcAUdUzKc20wZ7BvlMH0g**.tomcat1', but the session id
doesn't change and any subsequent request detect a
failover and try to change the sid.

I've no clear vision of tomcat package architecture and
cannot give a clear and valid solution to this bug, my
simple patch for 'getAttribute' works fine but i'm
still unable to remove the subsequent detections of
failover.

Note: the web app i've used works fine in JBoss 3.2.4
with same cluster configurations.

Marco.

[Scott M Stark]

Logged In: YES
user_id=175228

I integrated your patch for 4.0.1.