On 29/03/2012 11:58, John D. Ament wrote:
> On Thu, Mar 29, 2012 at 6:21 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> On 28/03/2012 16:48, John D. Ament wrote:
>
> JMS_SPEC-73 Define how messages from a topic are delivered to clustered application server instances
> - I would like this to be expanded to discuss queues
>
>
> The problem as currently stated is specific to the particular nature of topics. With queues, each message is only
> ever delivered to a single MDB, so there is no ambiguity in what behaviour is required a cluster.
>
> Can you please describe what you see as the issue with queues? We may want to log this as a separate issue.
>
>
> Yeah logging this as a separate issue puts my count at 7 though :/
> I at first assumed queues should not have as much of an issue as topics do with clusters. Then I thought about some
> of the issues I've seen comparing implementations.
>
> 1. Should queues even be a cluster-aware resource?
What do you mean by "cluster-aware"? Are you referring to JMS provider clusters or application server clusters
(JMS_SPEC-73 relates to the latter only).
> 2. If I connect to nodeA to deliver a message, should I see that message actually being consumed by an MDB deployed to
> nodeC, in a non failover state? Can we add something that forces the delivery to the current node only?
This sounds as if you are referring to JMS provider clusters, and are asking whether a producer connected to one node in
a JMS provider cluster should be delivered to a consumer connected to a different node in the cluster. Is that right?
> 3. As a consumer (not MDB, but regular JavaSE), can I have a method that retrieves all messages from a cluster, rather
> than just the messages on that node?
This sounds like a variation of 2.
Defining how a clustered JMS provider should behave is not defined by JMS. Some JMS providers treat a destination as
being a cluster-wide entity, so it doesn't matter which note the client connects to. Other JMS providers explicitly
treat a destination as being local to a specific node - though you might argue that this isn't really a cluster but
multiple JMS providers. Is this the subject area you had in mind?
Nigel