Multiple Diverts as an Active/Active solution for durable subscribers

[yairogen]

Hi,

I want to use durable subscribers but in an active/actuive model. Well, that's not possible due to JMS limitations that prevent multiple registrations under the same Id.

I am thinking of a wotkaround using diverts. Question is how to do it?

I was thinknig that consumers will listen to a queue and not a topic. This will enable regsitering multiple listeners on teh same queue. Hornet will verify only one gets a message at any given time.

Problem is that diverts do not allow multiple forwarding addresses. Can I create multiple diverts for the same source queue? Here is an example:

<diverts>
      <divert name="divertA">                 
         <address>jms.queue.queueA</address>
         <forwarding-address>jms.queue.queueB</forwarding-address>         
         <exclusive>false</exclusive>
      </divert>
      <divert name="divertB">                 
         <address>jms.queue.queueA</address>
         <forwarding-address>jms.queue.queueC</forwarding-address>         
         <exclusive>false</exclusive>
      </divert>
      <divert name="divertC">                 
         <address>jms.queue.queueA</address>
         <forwarding-address>jms.queue.queueD</forwarding-address>         
         <exclusive>false</exclusive>
      </divert>
</diverts>

Should this work?

Yair

[ataylor]

I want to use durable subscribers but in an active/actuive model. Well, that's not possible due to JMS limitations that prevent multiple registrations under the same Id.

what do you mean by active/active model, this doesnt really mean much to me, could you provide some context?

[yairogen]

Assume 5 nodes running different instances of the same application. In an http world, for example, you can load balance between them using round robin and other strategies.

If by chance these instances also need to listen to a topic, you can't have them all listen to the same topic since although any of the instances can process a message from the topic, you want the message to be processes by ONE instance at a time (can be different arbitrary instances for arbitary messages - what's important is that only one instance gets the message and not all of them).

So, in queue land they can all listen and only one will get the message. In Topic land they wil all get the message which is not desired.

[ataylor]

If by chance these instances also need to listen to a topic, you can't have them all listen to the same topic since although any of the instances can process a message from the topic, you want the message to be processes by ONE instance at a time (can be different arbitrary instances for arbitary messages - what's important is that only one instance gets the message and not all of them).

well thats not really a topic then, the whole point of a topic is that anyone subscribed to it receives the message and the whole point of a queue is only a single consumer receives it.

[yairogen]

Sorry, it is a topic becase the above mentioned application is one of many consumers of the same topic. I.e. I have 5-6 application types like this that all need to consume the same message copy. Within the application type only one instance need to read.

That's why I think Diverts can assist - use a queue and distribute it in a topic-like manner. This drives my original question. Can it be done?

[ataylor]

Sorry, it is a topic becase the above mentioned application is one of many consumers of the same topic. I.e. I have 5-6 application types like this that all need to consume the same message copy. Within the application type only one instance need to read.

Im not really sure what you are saying here but i took your original post to mean that you wanted to have multiple nodes in a cluster, send a message to a topic but only the consumers on a single node would receive that, my point was that this is not what a topic is, with a topic evryone subscribed to it would receive the messge what ever node they were on.

That's why I think Diverts can assist - use a queue and distribute it in a topic-like manner. This drives my original question. Can it be done?

you can divert a message from a particular address to any other address you want either inclusively or exclusively, using your own core bridges you could come up with any topolgy you wanted

[yairogen]

Would I be able to divert from one queue to multiple queues? If so, can you share an example?

[ataylor]

you divert between addresses, when a message is received by a server it is routed to an address, this address has either a single queue or 1 or more subscriptions. If the address also has a divert and it is exclusive then  it will routed to this address instead of the original, if it in not exclusive then it is routed to to both the original address and the divert address. This divert address could be an address on the same node that could also have a queue or subscriptions ot it could be a bridge to another node, once sent to another node it will follow the same logic.

Take a look at teh Divert Example in the distro this uses 2 servers and a bridge.

[yairogen]

I looked at the example. see the xml in my first post. Would that work?

[ataylor]

I looked at the example. see the xml in my first post. Would that work?

I still don't really know what you are trying to acheive but the example you should would mean the same message would get routed to address jms.queue.queueA, jms.queue.queueB, jms.queue.queueC and jms.queue.queueD and so to any queues or subscriptions or bridges bound to these addresses.

[yairogen]

That's exactly what I need. Producer sends to A, and it will be sent automatically as a copy to B,C and D in addition to A.

Thanks.