if that's the case you could do the same with Bridges, Cluster Connections and Diverts on Artemis as well.
Regardless of being AMQ5 or Artemis, I don't fully understand what he's describing.. sounds a consulting gig to me to gather abstract requirements and implement them. I would need some simplification of what is meant here. Otherwise I would need to draw a solution that's beyond what we can do IMHO. On Tue, Nov 10, 2015 at 11:03 AM, Tim Bain <tb...@alumni.duke.edu> wrote: > 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 >> -- Clebert Suconic
