2 Replies Latest reply on Jan 17, 2013 9:23 PM by Yong Hao Gao

    Propose A Management Notification Change

    Yong Hao Gao Master

      I'd like to make a little change to our current notification service. For the moment we have two ways of sending notifications. One is via a special notification address. Whenever a noticiation is generated, it sends the notification to that address. Anyone who listens to that address will get notified. The other way is via JMX notification mechanism. JMSServerControl and HornetQServerControl send their notifications using JMX. All others are using notification address.

       

      The problem with JMX notification is that all operations must be called through JMSServerControl and HornetQServerControl in order to generate a notification. Otherwise the notification won't get sent out. For example in AS7 integration creating/deploying a queue is done by directly calling HornetQServer's createQueue() method, bypassing the HornetQServerControl. So when a queue is such created/deployed, no JMX notification will be sent.

       

      What I think a better way to avoid such issue is to further unify the notification mechanism so that:

       

      1) All notifications are generated at their root sources. For example 'queue-create' notification is generated at HornetQServer who is actually created queue. This can avoid missing notifications if the caller reaches the root via different code routes. As a consequence all Notifications are core notifications.

       

      2) Internally JMX notifications are just transformed core notifications. It doesn't generate any JMX notifications. Rather it listens to the core notification service and transform any worthy notifications into JMX notification format and send it.

        • 1. Re: Propose A Management Notification Change
          Jeff Mesnil Master

          Yong Hao Gao wrote:

           

          I'd like to make a little change to our current notification service. For the moment we have two ways of sending notifications. One is via a special notification address. Whenever a noticiation is generated, it sends the notification to that address. Anyone who listens to that address will get notified. The other way is via JMX notification mechanism. JMSServerControl and HornetQServerControl send their notifications using JMX. All others are using notification address.

           

          The problem with JMX notification is that all operations must be called through JMSServerControl and HornetQServerControl in order to generate a notification. Otherwise the notification won't get sent out. For example in AS7 integration creating/deploying a queue is done by directly calling HornetQServer's createQueue() method, bypassing the HornetQServerControl. So when a queue is such created/deployed, no JMX notification will be sent.

           

          What I think a better way to avoid such issue is to further unify the notification mechanism so that:

           

          1) All notifications are generated at their root sources. For example 'queue-create' notification is generated at HornetQServer who is actually created queue. This can avoid missing notifications if the caller reaches the root via different code routes. As a consequence all Notifications are core notifications.

           

          2) Internally JMX notifications are just transformed core notifications. It doesn't generate any JMX notifications. Rather it listens to the core notification service and transform any worthy notifications into JMX notification format and send it.

          +1 for the change.

           

          When I initially wrote this code, I did not take into account that JMX notifications would be triggered by operations outside of HornetQ managemenet API (through JMX or core messages). However that's not the case with AS7 which has a reference on the HornetQServer instance and use it directly without going through its management API.

           

          Having the notifications sent by the "closest" resource impacted by the notifications will be cleaner and should cover the AS7 use case.

          1 of 1 people found this helpful