You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by bosbeles <bo...@gmail.com> on 2015/11/09 09:32:53 UTC
Artemis message queue oriented design help
Hi. I have problems on designing message queue oriented design on a clustered
fault tolerant system.
There are three sites A B C.
B is clustered as B1 B2 B3.
C is clustered as C1 C2 C3.
A message X (1000-5000 Xs per second actually) is sent to B cluster from
Site A.
B converts it to Y and sends it to C.
C converts it to Z and sends it to B.
If the connection between A and B fails A sends X to C. Now C converts it to
Z and sends Z to B.
If all connections of A fail then A stores Xs locally.
I have looked at the Apache Activemq Artemis.
But i cannot exactly figure out whether it fulfils my above scenario.
Could you help me? Thanks for your answers.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-message-queue-oriented-design-help-tp4703776.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Artemis message queue oriented design help
Posted by bosbeles <bo...@gmail.com>.
I havent read your suggestions yet. I will try to comprehend them. Thanks
for your answers again.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-message-queue-oriented-design-help-tp4703776p4703840.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Artemis message queue oriented design help
Posted by Clebert Suconic <cl...@gmail.com>.
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 <cl...@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 <bo...@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
Re: Artemis message queue oriented design help
Posted by Tim Bain <tb...@alumni.duke.edu>.
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 <cl...@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 <bo...@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
>
Re: Artemis message queue oriented design help
Posted by Clebert Suconic <cl...@gmail.com>.
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 <bo...@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
Re: Artemis message queue oriented design help
Posted by Tim Bain <tb...@alumni.duke.edu>.
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 <bo...@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.
>
Re: Artemis message queue oriented design help
Posted by bosbeles <bo...@gmail.com>.
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.
Re: Artemis message queue oriented design help
Posted by Clebert Suconic <cl...@gmail.com>.
I'm a bit confused by your message...
Are you describing the scenario you need and wanted to make sure it works?
Or are you implementing something that converts a message and then
move to the other site?
We have a JIRA open to support datacenter failover.. which is not
currently implemented. I think There are ways to achieve that without
implementing anything on the code, but we don't have anything for that
such as replicating remotely, etc..
It's hard to do these things and keep transactional guarantees that
are required by JMS use cases. .(that's the main reason why this
wasn't implemented)... and doing that without adding latency is a
tricky thing.
If you add some extra detail here on what you mean, I could help out more.
On Mon, Nov 9, 2015 at 3:32 AM, bosbeles <bo...@gmail.com> wrote:
> Hi. I have problems on designing message queue oriented design on a clustered
> fault tolerant system.
>
> There are three sites A B C.
>
> B is clustered as B1 B2 B3.
>
> C is clustered as C1 C2 C3.
>
> A message X (1000-5000 Xs per second actually) is sent to B cluster from
> Site A.
>
> B converts it to Y and sends it to C.
>
> C converts it to Z and sends it to B.
>
> If the connection between A and B fails A sends X to C. Now C converts it to
> Z and sends Z to B.
>
> If all connections of A fail then A stores Xs locally.
>
> I have looked at the Apache Activemq Artemis.
>
> But i cannot exactly figure out whether it fulfils my above scenario.
>
> Could you help me? Thanks for your answers.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-message-queue-oriented-design-help-tp4703776.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
--
Clebert Suconic