There are ways you could somehow achieve that with Artemis as well... but even with AMQ, it sounds like this is not fully a Datacenter failover implementation with proper tests. That to me sounds a feature request to either AMQ5 or Artemis.
The network connection will forward messages to the other site.. but it seems it would be in load balance (not diverting them). You will also need to ACK messages when they are acked into one site. On Tue, Nov 10, 2015 at 9:32 AM, Tim Bain <tb...@alumni.duke.edu> wrote: > 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. >> -- Clebert Suconic
