How do I configure clustered JMS Topic behavior but using the core API

[justinkwaugh]

I have created a cluster and would like to configure something like a JMS Topic such that messages get forwarded to consumers on all members of the cluster rather than round robining, but I would like to use the core api.  I have successfully set up an actual JMS Topic on the cluster, but I can't find a way to use the core api to do anything other than round robin.  My cluster is such that I have nodes which consumers and producers connect to, and nodes which just forward the traffic.  I guess similar to the "chained cluster" description in the documentation.

For background, I am attempting to migrate from Tibco Rendezvous to HornetQ.   The core api is more similar to the tibco api we are using, and I would prefer to use it rather than JMS as it seems pretty simple and straightforward. 

Is it not preferred to use the core api?  Though the documentation somewhat explicitly states that it is easier to use, faster and more powerful than the JMS facade, nearly 100% of the examples are JMS based.

[clebert.suconic]

There is no such thing as topic on the core api.. Everything is a queue...

You can Multiple queues with a single Address.

JMS Topic subscriptions are mapped internally to a core-queue, bound to the main address.

[justinkwaugh]

Thanks for the response.  How do jms topics then have broadcast behavior in a cluster vs round robin? 

[clebert.suconic]

It should be done through cluster connections.

Looko at the Clustered Topic examples. The address there is <address>jms</address> as all jms queues will start with jms.

If you want to have a specific core-address on the list, just add a clustering connection matching your address, with the proper discovery group.

The PostOffice should deliver all messages from the address to the other servers.

[justinkwaugh]

I apologize if i'm sounding a bit dense here, but I'm still a little unclear.  I have successfully set up a jms topic in a cluster.  No problems there.  Messages get delivered to all the consumers on all the nodes without round robining.

But, I am interested in accomplishing the same thing using the core api.  So I've set up a clustered connection with an address.  I've created queues on all the nodes for that address.  But when I send to a queue, it round robins to the nodes (as I believe the documentation says it should).  So i'm wondering how to make it send to all nodes of the cluster, instead of round robin, without using the jms facade.

I appreciate your patience in helping me understand.

[clebert.suconic]

You just need to have queues bound to a specific address.. say MyAddress...

When you produce, you will send towards the address...   And the messages will be distributed to all the nodes accordingly to the cluster connection.

I have changed the Clustered Topic a bit to explain you how it works (attached here).

(I can't add it officially now to the list of examples as I would need to tight up the example, change variable names.. tight up the readme.. etc).

Or I will add it right away if you or someone make it pretty :-)

[clebert.suconic]

Also: notice that each subscription is a queue... So you need multiple queues bound to the same address. That's probably what you needed to understand.

[timfox]

The relevant information is here:

http://hornetq.sourceforge.net/docs/hornetq-2.1.2.Final/user-manual/en/html/using-core.html#d0e1294

http://hornetq.sourceforge.net/docs/hornetq-2.1.2.Final/user-manual/en/html/jms-core-mapping.html

Once you understand how a JMS topic maps to core message concepts it should become clear,

Separating JMS queues and JMS topics was actually introducing redundancy in the JMS specification. You can model both JMS queues and topics by just having queues which are bound to addresses.

A jms queue is just an address with one core queue bound to it. A jms topic is an address with zero or more core queues bound to it (each topic subscription maps to a core queue).

This is a simpler way to model both point to point and publish subscribe messaging than JMS.