3 Replies Latest reply on Jan 15, 2007 9:43 AM by aluca

    How to detect that a NotificationListener was lost after net

    aluca

      Here is the probleme to solve:
      A webapp is registering toward a jmx service to receive a notification.
      How to figure out when we lost the listener?

      The normal behaviour of the JBossNotificationBroadcasterSupport is to cancel the listener from the list during the next notification sending is there was a network problem i.e. a tcp failure.

      But the web-app is not aware of that and then doesn't receive any notif any more w/o knowing.

      Our current temporary solution is :
      -first introduce a keepalive methode in the jmx service with the handback as a param,
      -second to overload all the methodes of JBossNotificationBroadcasterSupport that access to the registery (which is private) containing all the listener to access to a local registery instead, to be able to double check if the handback given in the keep alive param still corresponds to a listener in the registery map. If not answer false to the keepalive. Then the web-app reregister. Problem is a strong glueing w/ the current jboss version/code.

      Well, our problem seems pretty common and we are surprised not to be able to determine what is the standard pattern for that.

      Does anyone know it.

      Season's greetings

        • 1. Re: How to detect that a NotificationListener was lost after
          aluca

          The initial subject was: How to detect that a NotificationListener was lost after network failure or server failure?

          The question mark is important because I don't have the answer.

          Please anybody encountered similar issue or have any knowledge about NotificationListener resiliency. Is that really an issue of jboss or something not covered at all.

          • 2. Re: How to detect that a NotificationListener was lost after
            dimitris

            Are both the broadcaster and listener in the same JVM ? If not, I don't think you can get strong guarantess about notificaiton delivery (jsr-160 may have more to say about this)

            If you really want resilience you need to revert to JMS.

            • 3. Re: How to detect that a NotificationListener was lost after
              aluca

              Thx for replying Dimitris.

              No, the jboss server that register the Listener which is more or less the client and is remote (not the same JVM). Moreover they can be multiple clients.

              That means that if I want to use JMS, I must implement a complex mecanism of registering a client queue toward the service at client startup and unregister it when the client stops.

              The notification pattern does actually fits our need as it implements a broadcasting pattern from service to clients. We just added a keepalive mecanism (a simple methode of the MBean) that the clients calls on a regular basis indicating its "signature" as a parameter. Then the service (service MBean) dig into the listener registery to findout if the listener is still their and return true if ok.

              The problem is that there is no getter to the listener registery.

              As explained in my first post, we currently overrode the methodes that access to the registery attribute of the JBossNotificationBroadcasterSupport class to get access to a ListenerRegistry attribute which is also redefined. That way we can monitor what listener is still there and which disapeared. We identify the listeners using their handback "signature" attribute in which we put a id string (hostname + ...).

              The issue is if we further upgrade to a newer version of jboss we could encounter maintenace problem as the listener mecanism could evolve.