2 Replies Latest reply on Sep 7, 2005 6:44 AM by dimitris

    Barrier Service and Static SingletonMBean

    milmber

      I'm trying to use a BarrierService to detect whether my static singleton MBean has become master, and if so...to start other dependent MBeans.

      My dependent MBeans seem to be waiting correctly for the Barrier, but I'm having trouble picking up the notification that my static Singleton MBean has become master.

      Here is my jboss-service.xml:

      <?xml version="1.0" encoding="UTF-8"?>
      
      <server>
       <classpath codebase="." archives="quartz.jar"/>
       <mbean code="com.mailtrack.app.generic.service.scheduler.SchedulingService" name="promail:service=SchedulingService">
      <depends>jboss.jca:service=LocalTxCM,name=SchedulerDS</depends>
       <depends>promail:service=ConfigurationService</depends>
       </mbean>
      
       <!-- Make this MBean an singleton -->
       <mbean code="org.jboss.ha.singleton.HASingletonController"
       name="promail:service=SchedulingService-HASingletonController">
       <depends>jboss:service=DefaultPartition</depends>
       <depends>promail:service=SchedulingService</depends>
       <attribute name="PartitionName">DefaultPartition</attribute>
       <attribute name="TargetName">promail:service=SchedulingService</attribute>
       <attribute name="TargetStartMethod">startSingleton</attribute>
       <attribute name="TargetStopMethod">stopSingleton</attribute>
       <attribute name="TargetStopMethodArgument">true</attribute>
       </mbean>
      
       <!--
       In this example we have the BarrierController controlling a Barrier
       that is started when we receive the "jboss.tomcat.connectors.started"
       notification from the Tomcat mbean, and stopped when we receive the
       "org.jboss.system.server.stopped" notification from the server mbean.
      
       The dependent services need only define a dependency on the Barrier mbean!
       -->
       <mbean code="org.jboss.system.BarrierController"
       name="jboss:service=BarrierController">
      
       <!-- Whether to have the Barrier initially started or not -->
       <attribute name="BarrierEnabledOnStartup">false</attribute>
      
       <!-- Whether to subscribe for notifications after startup -->
       <attribute name="DynamicSubscriptions">true</attribute>
      
       <!-- Dependent services will depend on this mbean -->
       <attribute name="BarrierObjectName">promail:service=SchedulingService,type=Barrier</attribute>
      
       <!-- The notification subscription handback that starts the barrier -->
       <attribute name="StartBarrierHandback">Started</attribute>
      
       <!-- The notification subscription handback that stops the barrier -->
       <attribute name="StopBarrierHandback">Stopped</attribute>
      
       <!-- The notifications to subscribe for, along with their handbacks -->
       <attribute name="SubscriptionList">
       <subscription-list>
       <mbean name="promail:service=SchedulingService" handback="Started">
       <filter factory="AttributeChangeNotificationFilterFactory">
       <enable attribute-name="State"/>
       </filter>
      
       </mbean>
       <mbean name="promail:service=SchedulingService" handback="Stopped">
       <filter factory="AttributeChangeNotificationFilterFactory">
       <enable attribute-name="State"/>
       </filter>
       </mbean>
       </subscription-list>
       </attribute>
       </mbean>
      
      
      </server>
      



      The highlighted parts of my descriptor above show the bits I'm not clear about. And AttributeChangedNotification does not usually return a handback object ( I'm not 100% clear on this ) so I am not sure which values to use for StartBarrierHandback and StopBarrierHandback. I know I should look at the MasterNode or State attributes of my static singletonMBean...although the above does not work.

        • 1. Re: Barrier Service and Static SingletonMBean
          milmber

          Further investigation shows that the BarrierService is not receiving any notifications from my static singleton MBean although the subscription seems to succeed:


          DEBUG [org.jboss.system.BarrierController] Creating jboss:service=BarrierController
          DEBUG [org.jboss.system.BarrierController] Parsing subscription specification
          DEBUG [org.jboss.system.BarrierController] [SubscriptionInfo { objectName='promail:service=SchedulingService', handback=True, filter=javax.management.AttributeChangeNotificationFilter@65cfd2 }, SubscriptionInfo { objectName='promail:service=SchedulingService', handback=False, filter=javax.management.AttributeChangeNotificationFilter@2f1989 }]
          DEBUG [org.jboss.system.BarrierController] Subscribing for JMX notifications, dynamic=true
          DEBUG [org.jboss.system.BarrierController] Subscribed to: { objectName='promail:service=SchedulingService', listener='jboss:service=BarrierController', handback=True, filter=javax.management.AttributeChangeNotificationFilter@65cfd2 }
          DEBUG [org.jboss.system.BarrierController] Subscribed to: { objectName='promail:service=SchedulingService', listener='jboss:service=BarrierController', handback=False, filter=javax.management.AttributeChangeNotificationFilter@2f1989 }
          DEBUG [org.jboss.system.BarrierController] Subscribed to MBeanServerDelegate, too
          DEBUG [org.jboss.system.BarrierController] Created jboss:service=BarrierController
          DEBUG [org.jboss.system.BarrierController] Starting jboss:service=BarrierController
          DEBUG [org.jboss.system.BarrierController] Started jboss:service=BarrierController
          



          Is there something else I need to other than extend ServiceMBeanSupport in my implementation class?

          Do standard MBeans actually emit AttributeChangeNotifications or just XMBeans?

          • 2. Re: Barrier Service and Static SingletonMBean
            dimitris

            The issue here is, I don't think you can count on the AttributeValueChange (AVC) from your Scheduling service (that is if you extend ServiceMBeanSupport), because it's going to be started anyway when you deploy it.

            The HASingletonController will invoke startSingleton/stopSingleton on your service, and you can emit a pair of notifications there to indicate this fact, then you intercept those in the BarrierController.

            The hankback object is provided by whoever makes a subscription, to allow him to distinguish from which subscription a notification comes (because you can have many subscritpions). It has nothing to do with the Notification itself.

            What I see here, this is a very good use case and if we make the HASingletonController emit alternatively notifications, rather than invoke callback (e.g. through a config option), we can then just attach a Barrier and have any number of mbeans to depend on that...