As Heiko asked me some times ago I tried to describe in deep when ws-eventing SubscriptionManager need to be clustered in our opinion. I wrote a post on our blog describing the problem and our proposed solution including a Sequence diagram to help me in the description. I reported here the text of the post, but I kindly suggest to read the post on the blog, because the Sequence Diagram is very useful IMHO. Let me know if you prefer me to transfer it to a wiki page. The post is this one: http://www.javalinux.it/blogs/index.php?title=ws_eventing_clustering_prob... Of course we would have fun to work on this issue. * 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 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989678#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...