1 Reply Latest reply on Apr 26, 2005 6:41 PM by Dimitris Andreadis

    Dependencies on start/stop events (Barrier Service)

    Dimitris Andreadis Master

      There have been a few people that want to depend on the tomcat startup, eg:


      Can we make the tomcat connector emit start/stop notification and create a barrier service controlling a dependent mbean, so that people can easily depend on that?

      If I remember Scott has already drafted that somewhere?

        • 1. Re: Dependencies on start/stop events (Barrier Service)
          Dimitris Andreadis Master

          I've made an org.jboss.system.BarrierController service based on Scott's StartGroup idea about a programmatically controlled barrier mbean.

          The main differences are:

          (a) The barrier being more "jboss like" so it exposes "State/StateString" attributes and produces AVCs

          (b) I've used the generic ListenerServiceMBeanSupport to subscribe to any mbean/notification combination and utilized the subscription 'handback' to associate the reception of any notification from that subscription with the starting/stoping of the barrier. This allows for very flexible usage scenarios, for example, I can trigger a start when the tomcat connectors are created, and a stop when the server shuts down:

           <mbean code="org.jboss.system.BarrierController"
           <attribute name="BarrierObjectName">jboss:name=TomcatConnector,type=Barrier</attribute>
           <attribute name="StartBarrierHandback">start</attribute>
           <attribute name="StopBarrierHandback">stop</attribute>
           <attribute name="SubscriptionList">
           <mbean name="jboss.web:service=WebServer" handback="start">
           <filter factory="NotificationFilterSupportFactory">
           <enable type="jboss.tomcat.connectors.started"/>
           <mbean name="jboss.system:type=Server" handback="stop">
           <filter factory="NotificationFilterSupportFactory">
           <enable type="org.jboss.system.server.stopped"/>

          (c) Another difference is that I bring intially the Barrier to the CREATED state, instead of just registering it. This seems a little more natural to me, because the services that depend on the "Barrier" essentially wait for an event to trigger their complete start (or stop). This maps well with the manual startBarrier()/stopBarrier() too.

          In addition we can easily avoid the deployment error printout by the Scanner/MainDeployer by changing the ServiceController to *not* report as incompletely deployed those services in the CREATED state:

           public List listIncompletelyDeployed()
           List id = new ArrayList();
           for (Iterator i = installedServices.iterator(); i.hasNext();)
           ServiceContext sc = (ServiceContext) i.next();
           if (sc.state != ServiceContext.RUNNING && sc.state != ServiceContext.CREATED)
           return id;

          I haven't committed this last bit yet, but it seems sensible to me that services in the CREATED state are not really in error. In addition, as it is now, this can happen only through programmatic deployments, like this barrier trick, since normal deployment (through the MainDeployer) will always try to bring the deployment to RUNNING or FAILED state (or CONFIGURED in presence of a dependency).

          Any objections for this?

          I find the usage of a handback string instead of a notification type, rather interesting as well, because you can have more than one events from different MBeans triggering the start/stop of the barrier.

          I think I'll add the ability to specify the initial state of the barrier (started or stopped), to cater for those cases where you might have lost the starting notification. For more complex scenarios this should be overridable by subclassing the BarrierControler.