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.
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.
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.