6 Replies Latest reply on Apr 26, 2006 2:09 AM by starksm64

    Ungraceful exit of JBossCacheManager Installation

    anil.saldhana

      In the TomcatDeployer codebase, the following section:

      // Clustering
       if (metaData.getDistributable())
       {
       // Try to initate clustering, fallback to standard if no clustering is available
       try
       {
       AbstractJBossManager manager = null;
       String managerClassName = config.getManagerClass();
       Class managerClass = Thread.currentThread().getContextClassLoader().loadClass(managerClassName);
       manager = (AbstractJBossManager) managerClass.newInstance();
      
       if (manager instanceof JBossCacheManager)
       {
       // TODO either deprecate snapshot mode or move its config
       // into jboss-web.xml.
       String snapshotMode = config.getSnapshotMode();
       int snapshotInterval = config.getSnapshotInterval();
       JBossCacheManager jbcm = (JBossCacheManager) manager;
       jbcm.setSnapshotMode(snapshotMode);
       jbcm.setSnapshotInterval(snapshotInterval);
       }
      
       String name = "//" + ((hostName == null) ? "localhost" : hostName) + ctxPath;
       manager.init(name, metaData, config.isUseJK(), config.isUseLocalCache());
      
       // Don't assign the manager to the context until all config
       // is done, or else the manager will be started without the config
       server.setAttribute(objectName, new Attribute("manager", manager));
      
       log.debug("Enabled clustering support for ctxPath=" + ctxPath);
       }
       catch (ClusteringNotSupportedException e)
       {
       log.error("Failed to setup clustering, clustering disabled. Exception: " +e);
       }
       }


      can exit abruptly without giving the web application an opportunity to be retrofitted with the valves to follow (Eg: SecurityAssociationValve). In fact, this situation can arise when the user has flagged the web app as distributable and is using the Apache Tomcat SSO valve and not the JBoss clustered valve. Ideally, if there are any errors, clustering should be disabled for the webapp (original intent of the author of this block).

      An example of this issue is clearly seen in the following server log on cruisecontrol.
      http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite/20060419084946/build/output/jboss-4.0.4.GA/server/tomcat-sso/log/server.log

      Please notice the following lines:
      2006-04-19 10:17:02,716 WARN [org.jboss.system.ServiceController] Problem starting service jboss.web.deployment:id=1210098724,war=sso-form-auth2.war
      java.lang.NoClassDefFoundError: org/jboss/web/tomcat/tc5/session/FieldBasedClusteredSession
       at java.lang.Class.getDeclaredConstructors0(Native Method)
       at java.lang.Class.privateGetDeclaredConstructors(Class.java:1618)
       at java.lang.Class.getConstructor0(Class.java:1930)
       at java.lang.Class.newInstance0(Class.java:278)
       at java.lang.Class.newInstance(Class.java:261)
       at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:318)
       at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:103)
       at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:371)
      


      Basically, because of this error, the deployment of the webapp has stalled. And this setup does not use JBoss clustering. :-)

      I am fixing this issue via a JIRA issue. This is FYI.