"chtimi2" wrote : | Here is what i do: i implement a TopologyChangeListener that uses the HA MBean notification mechanism to send business commands (serializable command pattern objects) to nodes on topology changes. | And in my case i need to be sure the commands are executed in order, and that one has been processed before the next is executed. That is, synchronously. | | I'm going to try your suggestion of executing the command asynchronously on one node to confirm the cause of the problem, but if it really is that, does that mean i can't use the notification mechanism? You'd have to do something like what people do with JMS temporary queues to turn an asynchronous messaging system into something synchronous;. i.e. execute your commands on a different thread but have that thread at the end send a message to the node that initiated the process telling them it's complete. The node that initiates the process blocks waiting for those messages to come in. Complex. Yuck. Let's find a better way. anonymous wrote : And it would be the same with mechanisms like HAPartition.callSyncMethodOnCluster() wouldn't it? Yes. anonymous wrote : | What do think about my work-around with the Interceptor, could i stay like this or is it too dirty? | | Also if i understand you right you say that when i go into the @PostConstruct thread i'm not in the same thread that i would be if used an @Interceptor? But i don't get it, in both cases the method seems to be invoked just before the facade method call? The interception is synchronous right? anonymous wrote : You seem to be saying that there is a unique JGroups thread for the node? Is that right and why? I don't see why it should be like the Swing EventDispatchThread thread? The JGroups channel guarantees that the application will receive messages in the order sent. You can't guarantee that if you allow multiple threads to deliver messages. JGroups 2.6 (used in AS 5) improves on the single-threaded JG 2.4 architecture by having a thread pool to carry messages up, but it still only allows one thread at a time per sender to be delivering messages to the application. So wouldn't help with your problem. anonymous wrote : Thanks for your help because JMS is the one thing that has caused me the most headaches (so far, touching wood) in my clustering our application. Maybe it is easier in JBoss 5? Yes, because AS 5 uses JBoss Messaging instead of JBossMQ. No more JMS server only running on one node. Instead your topics and queues are deployed on every node. So there would be no need for HA-JNDI to make a group RPC to find the JMS resources; they would be bound locally. BTW, you can install JBoss Messaging in 4.2.3 as well. See the JBoss Messaging project pages. Perhaps that's your solution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205415#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...