WS-Eventing: event notification failure

Still working on ws-eventing and JBossWS… We noticed that event notification failures are completely lost. If an event notification fails (for example because the event sink is down) the current jbossws engine (1.0.4.GA) just logs the error and does nothing else. Of course it could be useful at least to keep track of failed notification in order to send them again later or simply to warn the sink’s owner.

So we’ve just made a patch to jbossws, saving notification failures into a list stored in the SubscriptionManager mbean.

You can find the patch on jboss jira: http://jira.jboss.com/jira/browse/JBWS-1406

ws-eventing clustering problem

We got some troubles using ws-eventing jbossws implementation in our clustered/load balanced environment (for a deeper description read here). I’ll try to describe them in this post, with some proposed solutions:


Click here for a larger image.

The previous diagram describes the two main common problems we had with ws-eventing deployed in a clustered environment:

  • Subscription on one of the clustered environment’s machine

    DESCRIPTION: when a client subscribes to our ws-eventing service the load balancer sends his requests to a real server that receives the subscription and store it locally (in current jbossws eventing implementation this is achieved using a Map owned by SubscriptionManagerMbean). An event source generates a notification and delegates its notification to jbossws; but in a cluster environment this event source could use a different real server knowing nothing about the subscriber. The notification would be lost. See messages from 1 to 5 in the above diagram. Of course a very similar situation may happen when renewing a subscription: a renew message cold be send to a server different from the one that received the first subscription, resulting in subscription renew failure. The client will receive an “Unable to renew” exception, and on the server side the subscription will expire for timeout! All notifications are lost until client re-subscribe to the right real server. See messages from 6 to 13 in the above diagram.

    PROPOSED SOLUTION: These two problems could be solved clustering the SubscriptionMap. The easiest solution would probably be arranged using HAJNDI to store subscriptions. Of course the use of a local Map instead of HAJNDI have to be configured at deploy time.

  • Shutdown of one of the cluster’s machine

    DESCRIPTION: SubscriptionManagerMbean sends notifications to remove every subscriptions when it is stopped or the real server it runs on shutdowns. But in a cluster environment other servers continue to work and potentially to send notifications. Those notifications will be lost. See messages from 14 to 26 in the above diagram.

    PROPOSED SOLUTION: SubscriptionManagerMbeans have to be clustered and have to exchange their status before they can decide to send this kind of notifications. The solution could be implemented using jGroups (of course), but it needs further investigations and discussions, mainly to understand if SubscriptionManager is the only part of jbossws needing clustered solutions

I started a thread in JbossWS Design forum aboute this issue.

LMS released

Javalinux.it team (me and Stefano :-) infact) is proud to announce the
first release of Lms.
What is Lms? Lms is an acronym for Logging Meta Service; Lms’ goal and
use are very similar to the axis’ tcp monitor ones: it logs any tcp communication
and gives developers the opportunity to review any request-response
communications.
Lms is a JBoss deployable application (an ear) and have a jmx mbean as application core and a seam user interface to make its use easy.
In the user interface you have to bind a symbolic name to a real http
address (in most cases a ws endpoint address):

Binding
LMS binding

You can start/stop the logging functionality (in stopped logging mode Lms acts just like a proxy), delete the binding, clean all
communication logs. After that, you should use the binding you’ve just defined: as a matter of fact Lms creates a virtual address given by your application server host & port followed by /Lms/servlet/auth/log/ and the name you choose for your binding.

LMS usage
LMS usage

Selecting a binding you will see all the logged communications:

Communications list
LMS Communications list

Finally clicking on Show you’ll see request/response logged in this communication:

Show
LMS Show functionality

It’ s very simple but very very useful for debugging, as you can figure
out if you are a developer. If you like it or you are simply curious and want to give it a try, download it here.
To install it proceed as follows:

  • add policy named no-auth to your login-config.xml: <application-policy name = "no-auth">
    <authentication>
    <login-module code = "org.jboss.security.ClientLoginModule"
    flag = "required">
    </login-module>
    </authentication>
    </application-policy>
  • deploy Lms.ear
  • make sure your binding target addresses can by reached from your host

Finally, if you want to take a look at the code download it here.