We have a GlassFish 3.1.2 cluster with 2 instances (on jelastic.com). The application is supposed to generate (lots of) output messages that we want to publish to the outside world using JMS.
The original idea was to have external JMS clients consume the_output_queue (or the_output_topic). That works if we have 1 instance and access the physical destination directly (on my PC at localhost:7676).
Jelastic has a feature "Public IPv4" that provides an externally visible IP address for each instance of a cluster.
Now, with 2 clustered instances there seem to be 2 physical destinations and an external JMS client would have to connect on 2 sockets to get all the output messages. In our case it would be something like 81.81.81.1:27676 and 82.82.82.2:27676. Of course this is ugly and it breaks completely when we scale up to 3 or 4 instances as all the clients would have to change.
How should we access the_output_queue properly when using a cluster?
What would be a natural way to have a clustered GlassFish application publish JMS messages?
Is it a stupid idea in the first place to access a JMS physical destination from the outside? I guess ACC (Application Client Container) would be a solution, but we were hoping for light-weight and portable JMS clients.
Or if we give up on JMS for the publishing: What other technologies would make sense for this purpose? Volume and throughput have to be considered, let's say 1000 messages/s.
UPDATE:
Actually my question could be independent of GlassFish and Jelastic: How should a client access a queue in a Message Queue Broker Cluster? Should a client not be able to connect to "the cluster" instead of to "a specific broker in the cluster"?
I also found this interesting note:
In a broker cluster, you create a physical destination on one broker and the cluster propagates it to all the others. Because the brokers cooperate to route messages across the cluster, client applications can consume messages from destinations on any broker in the cluster. However the persistence and acknowledgment of a message is managed only by the broker to which a message was originally produced.
What exactly does "cooperate to route messages across the cluster" mean? Can I assume that a message written to queueA through broker1 is visible on the "same" queueA in broker2 and can be consumed there as well?