2 Replies Latest reply on Jan 13, 2006 6:38 AM by Dimitris Andreadis

    BarrierController Service and Dependent Service

    Jimmy Wilson Apprentice

      I am using JBoss 4.0.2 with the BarrierController service in order to have some custom MBeans depend upon the starting of the Tomcat connectors. Upon startup, everything works just as expected, but upon shutdown of the application server, the "stop" method of my custom MBeans is never called.

      To verify that my MBean is working correctly, I removed the dependency on the BarrierController service (the MBean it dynamically creates), and all works as expected including the stop method.

      I've added my BarrierController XML and a simple Test MBean code below (in case I am doing something crazy), but could I have happened upon a bug? In the Test MBean code below, the "Stopping..." log message is never printed when the dependency to the BarrierController is added.

      <server>
       <mbean code="org.jboss.system.BarrierController"
       name="jboss:service=BarrierController">
      
       <attribute name="BarrierEnabledOnStartup">false</attribute>
       <attribute name="DynamicSubscriptions">true</attribute>
       <attribute name="BarrierObjectName">
       com.acxiom.grid.jboss.services:name=TomcatConnectors,type=Barrier
       </attribute>
       <attribute name="StartBarrierHandback">start</attribute>
       <attribute name="StopBarrierHandback">stop</attribute>
       <attribute name="SubscriptionList">
       <subscription-list>
       <mbean name="jboss.web:service=WebServer" handback="start">
       <filter factory="NotificationFilterSupportFactory">
       <enable type="jboss.tomcat.connectors.started"/>
       </filter>
       </mbean>
       <mbean name="jboss.system:type=Server" handback="stop">
       <filter factory="NotificationFilterSupportFactory">
       <enable type="org.jboss.system.server.stopped"/>
       </filter>
       </mbean>
       </subscription-list>
       </attribute>
       </mbean>
      </server>


      package com.acxiom.grid.jboss.services.test;
      
       public interface TestMBean
       {
       void start();
      
       void stop();
       }


      package com.acxiom.grid.jboss.services.test;
      
      import org.apache.log4j.Logger;
      
      public class Test implements TestMBean
      {
       Logger logger;
      
       public Test()
       {
       logger = Logger.getLogger(getClass());
       }
      
       public void start()
       {
       logger.info("Starting...");
       }
      
       public void stop()
       {
       logger.info("Stopping...");
       }
      }


        • 1. Re: BarrierController Service and Dependent Service
          Dimitris Andreadis Master

          Yeap, this is bug! The problem appears when the BarrierController is destroyed *before* the 'stop' notification has been received:

           protected void destroyService()
           {
           // unsubscribe for notifications
           unsubscribe();
          
           try
           {
           // implicitly call the ServiceController
           barrier.destroy();
          
           // remove from MBeanServer
           getServer().unregisterMBean(barrierName);
           }
           catch (Throwable e)
           {
           log.debug("Unexpected error during destroy", e);
           }
          
           // cleanup
           barrier = null;
           }
          

          barrier.destroy() should implicitly stop the barrier first, but that was another bug that was fixed in JBoss 4.0.3RC2: http://jira.jboss.com/jira/browse/JBAS-2022

          The obvious workaround is to add a barrier.stop() before the destroy, but I'll try to see if can use an additional notification as the stop signal, stay tuned:


          • 2. Re: BarrierController Service and Dependent Service
            Dimitris Andreadis Master

            I can think now of many solutions, but none without some coding. A relatively easy one is to write an extra mbean with just an exposed stop() operation that emits a notification of yours. Then deploy this mbean in the same file with the BarrierController, and point to that mbean/notification instead of the one that comes from the Server upon shutdown.