I know you're also looking at Artemis, but if ActiveMQ can meet your other requirements, it can fulfill the routing scenario you described.
You would need two networkConnectors. One would be for the queues and topics that should always go straight to C, with a URI like static:(failover:(tcp://C1,tcp:C2,tcp:C3)?maxReconnectAttempts=0). The second would be for the queues and topics that should go to B if available but to C if not; the URI static:(failover:(tcp://B1,tcp:B2,tcp:B3,tcp://C1,tcp:C2,tcp:C3)?maxReconnectAttempts=0&randomize=false) should work, though it won't let you automatically reconnect to B1/B2/B3 when one of them comes back up after a full outage of the B cluster. If you need that, I think you could get it with either of the following two URIs (though I haven't done this myself so it would need to be tested to confirm correct operation): static:(failover:(tcp://B1,tcp:B2,tcp:B3,tcp://C1,tcp:C2,tcp:C3)?maxReconnectAttempts=0&randomize=false&priorityBackup=true&priorityURIs=tcp://B1,tcp:B2,tcp:B3) or static:(failover:(failover:(tcp://B1,tcp:B2,tcp:B3),failover:(tcp://C1,tcp:C2,tcp:C3))?maxReconnectAttempts=0&nested.maxReconnectAttempts=0&randomize=false&priorityBackup=true) See http://activemq.apache.org/failover-transport-reference.html for more details about the failover transport and the options available on it. You would need to filter which destinations use which connections based on which use case you want them to follow, using the included and excluded destinations properties of NetworkConnector as described on http://activemq.apache.org/networks-of-brokers.html. It sounds like you're already clear on how to convert X to Y to Z, but ActiveMQ supports embedded Camel route that would allow you to do this entirely within the broker (without needing a client to connect from outside the broker process). None of this is to imply that Artemis can't also meet your needs, just to point out that ActiveMQ can meet the ones you've described and you should consider it if Artemis can't support something you need. Tim On Tue, Nov 10, 2015 at 12:54 AM, bosbeles <bosbe...@gmail.com> wrote: > Thanks for your answer. > The message conversion scenario is trivial. Shorter scenario is that: > > Site A produces a message X and sends it to site B. > If all of the clusters on site B fail, site A will send the message to site > C. > > > My scenario looks like B1 B2 B3 C1 C2 C3 are backup servers in that order > but only for the message X. > Site A sends some other messages than X directly to the site C. So for > other > messages's point of view, C clusters are not backup of B clusters. > > Normally I was planning to use netty and manage the connections as I > described. Normally i am doing failover over connections. For reliable > messages I was planning async Acks. For some cases duplicate detection > requires. Then I have heard hornetq and then artemis which does nearly all > of my requirements. > I dont want to reinvent the wheel. But I cannot figure not the queues, the > bridges, the diverts, the cluster groups required. Especially site B to > site > C failover is very likely to the artemis solution. But it is something > cülike clusters of clusters > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Artemis-message-queue-oriented-design-help-tp4703776p4703798.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
