activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Artemis message queue oriented design help
Date Tue, 10 Nov 2015 14:32:38 GMT
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 <bosbeles@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message