The fact that some destinations should always be routed to C makes me think a full datacenter failover isn't being requested anyway. The goal is not for C to take over for B, the goal is for C to take over the receipt and processing of select destinations from B. Those are different scenarios.
I'm not clear what you mean about "it seems it would be in load balance (not diverting them)". Based on what I've understood of the scenario, there's no need for special logic to ack the messages; X messages are consumed (acked) on whichever broker the client (e.g. embedded Camel route) consumes them, and Y messages are published (if consumed on B) or Z messages are published (if consumed on C). No special acking logic required. On Tue, Nov 10, 2015 at 8:22 AM, Clebert Suconic <clebert.suco...@gmail.com> wrote: > 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 >
