What you mean be 'same topic'? Do you have a topic with the same name deployed in two different JBossMQ instances?
I think in this case you have to deploy the MDB twice with different topic configuration.
Yes, the topics have the same names and also the same semantics. However, they are deployed in different JBoss instances not in the same cluster, distributed all over the world. How can we deploy a MDB twice? Do we have to use ejb-jar.xml deployment descriptor then? I think that's very inflexible since the number of locations can grow over the time.
Let me explain the reason leading us to do those things. We have a complete application environment at location A (say Europe) as well as at location B (say Asia). European requests will be forwarded to European application servers, Asian requests to Asian ones. The DNS will decide this. We have an extra application for configuring the main application. If configurations change messages will be sent and consumed by the main application which then invalidates its configuration cache and requests the new configuration. As we need the same configurations in Europe and in Asia we are frequently synchronizing databases (merge replication). Well, the problem is, if configuration in Asia gets changed, only Asian servers get informed about the changes, but not the European ones.
Has anyone else experience with those things or are there any best practices on that?
I have had a similar situation.
Use a Topic as broadcast to all clients that master data was changed in a cluster. But we have different cluster with the same underlying database and if master data is changed in cluster1 only the topicj of cluster1 will broadcast.
I write a simple client that listen to cluster1 topic and broadcast this to the other cluster topics.
That was the simplest way for our situation.
I'm not sure if I got your suggestion correctly. We write a simple client, let's call it JMS delegator and deploy it at cluster A and B. If JMS delegator is a web application we could lookup B's JMS connection factory and all topics (how can we lookup all topics?) within a servlet context listener. Then we subscribe to each topic and set message listeners, let's call them MessageDelegator. Each MessageDelegator has to know the topic name and A's JMS connection factory to be able to re-publish incoming messages to A's topic. Did you do something like this?
A few questions on that:
1. Since delegating those messages should work bidirectionaly this would produce an infinite loop, wouldn't it?
2. What should we do if there are more and more different locations in future? Should we build up a message chain? What, if a member of this chain goes offline?
3. If setting MessageDelegators in a servlet context listener as mentioned above fails, we won't have a chance to retry connecting despite HAJNDI? We also cannot use our own ExceptionListener because it's not allowed in a JBoss environment, right? We won't get informed any more about configuration changes if the connection gets lost one time because there will be no automatic connect retries?
Thank you very much for your answers, Wolf-Dieter Fink
No, the client is a simple Java application, not within any AppServerContainer.
Here you are able to create many InitialContext for different clusters.
1. I mark the message with a property let name it 'delegated' to use it by a message filter of the Delegator.
2. You might configure your cluster and what messages are to delegate
3. With a durable topic or a simple persistence (filesystem, JavaDb) you can ensure the delivery if the delegator lost connection to one of the clusters
Ok, it's clear now. Thank you so much!