This content has been marked as final.
Show 1 reply
-
1. Re: Dependencies on start/stop events (Barrier Service)
dimitris Apr 26, 2005 6:41 PM (in response to dimitris)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" name="jboss:service=BarrierController"> <attribute name="BarrierObjectName">jboss:name=TomcatConnector,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>
(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) { id.add(sc); } } 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.