Artemis question on JMS clustered topic and high availability

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Artemis question on JMS clustered topic and high availability

Bruce Ritchie
I've been investigating switching from a single activemq server to a
cluster of artemis servers on aws and I have a question on clustered jms
topics and high availability.

Firstly, I like the idea that the producers/consumers can connect to any
node in the cluster and fail over (client side) to a different node if a
node goes down without loosing any messages with the understanding that the
producers may have to retry submissions.

In my usage scenario I do not have any queues - just two jms topics.
Multiple producers, multiple consumers. What I've been trying to figure out
is if I can away with not having a <ha-policy>. The clustered topic example
seems to indicate that with a message-load-balancing set to STRICT that
it'll copy messages to other nodes in the cluster if a corresponding topic
already exists there. My understanding from reading the docs is that this a
true copy (potentially async I assume) vs something like a read-through
from one node to another when the message doesn't exist on the local node.
Is that correct?

If the above is correct and the fact that I don't have a requirement to be
able to recover messages after a full cluster restart is there any reason
to have a ha-policy set? The only reason I can think of is to sync messages
in the topic between shutdown and restart of a node in the cluster prior to
clients reconnecting to that node so that the client(s) may not miss
messages (potential dup are ok in my use case). That's pretty important but
I'm not sure I have can both the clustered jms topics in a symmetrical
cluster and have a ha-policy (ala [master0/slave1] <--> [master1/slave0]).
Is that possible?

Thanks!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Artemis question on JMS clustered topic and high availability

Bruce Ritchie
Bump. Any help appreciated :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Artemis question on JMS clustered topic and high availability

clebertsuconic
In reply to this post by Bruce Ritchie
when you have a topic subscription in cluster.. the message will be
copied to every subscription on the cluster connection (or network of
brokers)...


When you have the same subscription among different nodes.. (that
is... the same core-queue name on more than one node), then
load-balancing will have a play...


what you are looking is having a copy of the topic subscription on
every node, making it a single cluster among different nodes, and
that's not what you have here. You would need a backup to save the
acks between two servers.


you can have multiple master/slaves on your environment, and even
cross them on a colocated environment, having a phisical server with 2
live nodes in case of failures.



Don't know if that helps?

On Tue, Jan 3, 2017 at 2:30 PM, Bruce Ritchie <[hidden email]> wrote:

> I've been investigating switching from a single activemq server to a
> cluster of artemis servers on aws and I have a question on clustered jms
> topics and high availability.
>
> Firstly, I like the idea that the producers/consumers can connect to any
> node in the cluster and fail over (client side) to a different node if a
> node goes down without loosing any messages with the understanding that the
> producers may have to retry submissions.
>
> In my usage scenario I do not have any queues - just two jms topics.
> Multiple producers, multiple consumers. What I've been trying to figure out
> is if I can away with not having a <ha-policy>. The clustered topic example
> seems to indicate that with a message-load-balancing set to STRICT that
> it'll copy messages to other nodes in the cluster if a corresponding topic
> already exists there. My understanding from reading the docs is that this a
> true copy (potentially async I assume) vs something like a read-through
> from one node to another when the message doesn't exist on the local node.
> Is that correct?
>
> If the above is correct and the fact that I don't have a requirement to be
> able to recover messages after a full cluster restart is there any reason
> to have a ha-policy set? The only reason I can think of is to sync messages
> in the topic between shutdown and restart of a node in the cluster prior to
> clients reconnecting to that node so that the client(s) may not miss
> messages (potential dup are ok in my use case). That's pretty important but
> I'm not sure I have can both the clustered jms topics in a symmetrical
> cluster and have a ha-policy (ala [master0/slave1] <--> [master1/slave0]).
> Is that possible?
>
> Thanks!



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Artemis question on JMS clustered topic and high availability

Bruce Ritchie
Your reply is much appreciated. So crossing master/slave is only possible
in a colocated environment? If so I think that's doable in my situation.

"what you are looking is having a copy of the topic subscription on every
node, making it a single cluster among different nodes,"

Is there an example of this I can work from? I previously was working from
the example @
https://github.com/apache/activemq-artemis/tree/1.x/examples/features/clustered/clustered-topic


Thanks!


On Wed, Jan 11, 2017 at 11:53 AM, Clebert Suconic <[hidden email]
> wrote:

> when you have a topic subscription in cluster.. the message will be
> copied to every subscription on the cluster connection (or network of
> brokers)...
>
>
> When you have the same subscription among different nodes.. (that
> is... the same core-queue name on more than one node), then
> load-balancing will have a play...
>
>
> what you are looking is having a copy of the topic subscription on
> every node, making it a single cluster among different nodes, and
> that's not what you have here. You would need a backup to save the
> acks between two servers.
>
>
> you can have multiple master/slaves on your environment, and even
> cross them on a colocated environment, having a phisical server with 2
> live nodes in case of failures.
>
>
>
> Don't know if that helps?
>
> On Tue, Jan 3, 2017 at 2:30 PM, Bruce Ritchie <[hidden email]>
> wrote:
> > I've been investigating switching from a single activemq server to a
> > cluster of artemis servers on aws and I have a question on clustered jms
> > topics and high availability.
> >
> > Firstly, I like the idea that the producers/consumers can connect to any
> > node in the cluster and fail over (client side) to a different node if a
> > node goes down without loosing any messages with the understanding that
> the
> > producers may have to retry submissions.
> >
> > In my usage scenario I do not have any queues - just two jms topics.
> > Multiple producers, multiple consumers. What I've been trying to figure
> out
> > is if I can away with not having a <ha-policy>. The clustered topic
> example
> > seems to indicate that with a message-load-balancing set to STRICT that
> > it'll copy messages to other nodes in the cluster if a corresponding
> topic
> > already exists there. My understanding from reading the docs is that
> this a
> > true copy (potentially async I assume) vs something like a read-through
> > from one node to another when the message doesn't exist on the local
> node.
> > Is that correct?
> >
> > If the above is correct and the fact that I don't have a requirement to
> be
> > able to recover messages after a full cluster restart is there any reason
> > to have a ha-policy set? The only reason I can think of is to sync
> messages
> > in the topic between shutdown and restart of a node in the cluster prior
> to
> > clients reconnecting to that node so that the client(s) may not miss
> > messages (potential dup are ok in my use case). That's pretty important
> but
> > I'm not sure I have can both the clustered jms topics in a symmetrical
> > cluster and have a ha-policy (ala [master0/slave1] <-->
> [master1/slave0]).
> > Is that possible?
> >
> > Thanks!
>
>
>
> --
> Clebert Suconic
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Artemis question on JMS clustered topic and high availability

clebertsuconic
You are using AWS. Do you have the storage disk? or is it transient?


What I have been suggesting to cloud user is to just monitor their
system, and have the system restarting itself in case of a failure.
That is the best scenario you can get since the infra-structure would
give you the needed HA.


If you don't, you will need to setup a backup/live pair for each system.


The only difference is that you can do that with just 2 boxes...

Box1: LiveA and BackupB
Box2: LiveB and BackupA


That's a possible example / solution.



We have a colocated topology that was developed for wildfly or
embedded systems, but I would recommend you keeping it as simple as
possible... either have the infra-structure restarting itself if you
have the storage... or have a backup pair like I'm suggesting here.




I feel like I missed answering something here.. let me know if I am...





On Wed, Jan 11, 2017 at 12:07 PM, Bruce Ritchie <[hidden email]> wrote:

> Your reply is much appreciated. So crossing master/slave is only possible
> in a colocated environment? If so I think that's doable in my situation.
>
> "what you are looking is having a copy of the topic subscription on every
> node, making it a single cluster among different nodes,"
>
> Is there an example of this I can work from? I previously was working from
> the example @
> https://github.com/apache/activemq-artemis/tree/1.x/examples/features/clustered/clustered-topic
>
>
> Thanks!
>
>
> On Wed, Jan 11, 2017 at 11:53 AM, Clebert Suconic <[hidden email]
>> wrote:
>
>> when you have a topic subscription in cluster.. the message will be
>> copied to every subscription on the cluster connection (or network of
>> brokers)...
>>
>>
>> When you have the same subscription among different nodes.. (that
>> is... the same core-queue name on more than one node), then
>> load-balancing will have a play...
>>
>>
>> what you are looking is having a copy of the topic subscription on
>> every node, making it a single cluster among different nodes, and
>> that's not what you have here. You would need a backup to save the
>> acks between two servers.
>>
>>
>> you can have multiple master/slaves on your environment, and even
>> cross them on a colocated environment, having a phisical server with 2
>> live nodes in case of failures.
>>
>>
>>
>> Don't know if that helps?
>>
>> On Tue, Jan 3, 2017 at 2:30 PM, Bruce Ritchie <[hidden email]>
>> wrote:
>> > I've been investigating switching from a single activemq server to a
>> > cluster of artemis servers on aws and I have a question on clustered jms
>> > topics and high availability.
>> >
>> > Firstly, I like the idea that the producers/consumers can connect to any
>> > node in the cluster and fail over (client side) to a different node if a
>> > node goes down without loosing any messages with the understanding that
>> the
>> > producers may have to retry submissions.
>> >
>> > In my usage scenario I do not have any queues - just two jms topics.
>> > Multiple producers, multiple consumers. What I've been trying to figure
>> out
>> > is if I can away with not having a <ha-policy>. The clustered topic
>> example
>> > seems to indicate that with a message-load-balancing set to STRICT that
>> > it'll copy messages to other nodes in the cluster if a corresponding
>> topic
>> > already exists there. My understanding from reading the docs is that
>> this a
>> > true copy (potentially async I assume) vs something like a read-through
>> > from one node to another when the message doesn't exist on the local
>> node.
>> > Is that correct?
>> >
>> > If the above is correct and the fact that I don't have a requirement to
>> be
>> > able to recover messages after a full cluster restart is there any reason
>> > to have a ha-policy set? The only reason I can think of is to sync
>> messages
>> > in the topic between shutdown and restart of a node in the cluster prior
>> to
>> > clients reconnecting to that node so that the client(s) may not miss
>> > messages (potential dup are ok in my use case). That's pretty important
>> but
>> > I'm not sure I have can both the clustered jms topics in a symmetrical
>> > cluster and have a ha-policy (ala [master0/slave1] <-->
>> [master1/slave0]).
>> > Is that possible?
>> >
>> > Thanks!
>>
>>
>>
>> --
>> Clebert Suconic
>>



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Artemis question on JMS clustered topic and high availability

Bruce Ritchie
Thanks for the response. The paired LiveA/BackupB + LiveB/BackupA is what I
was wondering out with the JMS clustered topic. I'd like to not rely on
infrastructure to restart because of the latency that involves - I'd like
to keep any hiccups to < 1 sec if possible.

On Wed, Jan 11, 2017 at 1:46 PM, Clebert Suconic <[hidden email]>
wrote:

> You are using AWS. Do you have the storage disk? or is it transient?
>
>
> What I have been suggesting to cloud user is to just monitor their
> system, and have the system restarting itself in case of a failure.
> That is the best scenario you can get since the infra-structure would
> give you the needed HA.
>
>
> If you don't, you will need to setup a backup/live pair for each system.
>
>
> The only difference is that you can do that with just 2 boxes...
>
> Box1: LiveA and BackupB
> Box2: LiveB and BackupA
>
>
> That's a possible example / solution.
>
>
>
> We have a colocated topology that was developed for wildfly or
> embedded systems, but I would recommend you keeping it as simple as
> possible... either have the infra-structure restarting itself if you
> have the storage... or have a backup pair like I'm suggesting here.
>
>
>
>
> I feel like I missed answering something here.. let me know if I am...
>
>
>
>
>
> On Wed, Jan 11, 2017 at 12:07 PM, Bruce Ritchie <[hidden email]>
> wrote:
> > Your reply is much appreciated. So crossing master/slave is only possible
> > in a colocated environment? If so I think that's doable in my situation.
> >
> > "what you are looking is having a copy of the topic subscription on every
> > node, making it a single cluster among different nodes,"
> >
> > Is there an example of this I can work from? I previously was working
> from
> > the example @
> > https://github.com/apache/activemq-artemis/tree/1.x/
> examples/features/clustered/clustered-topic
> >
> >
> > Thanks!
> >
> >
> > On Wed, Jan 11, 2017 at 11:53 AM, Clebert Suconic <
> [hidden email]
> >> wrote:
> >
> >> when you have a topic subscription in cluster.. the message will be
> >> copied to every subscription on the cluster connection (or network of
> >> brokers)...
> >>
> >>
> >> When you have the same subscription among different nodes.. (that
> >> is... the same core-queue name on more than one node), then
> >> load-balancing will have a play...
> >>
> >>
> >> what you are looking is having a copy of the topic subscription on
> >> every node, making it a single cluster among different nodes, and
> >> that's not what you have here. You would need a backup to save the
> >> acks between two servers.
> >>
> >>
> >> you can have multiple master/slaves on your environment, and even
> >> cross them on a colocated environment, having a phisical server with 2
> >> live nodes in case of failures.
> >>
> >>
> >>
> >> Don't know if that helps?
> >>
> >> On Tue, Jan 3, 2017 at 2:30 PM, Bruce Ritchie <[hidden email]>
> >> wrote:
> >> > I've been investigating switching from a single activemq server to a
> >> > cluster of artemis servers on aws and I have a question on clustered
> jms
> >> > topics and high availability.
> >> >
> >> > Firstly, I like the idea that the producers/consumers can connect to
> any
> >> > node in the cluster and fail over (client side) to a different node
> if a
> >> > node goes down without loosing any messages with the understanding
> that
> >> the
> >> > producers may have to retry submissions.
> >> >
> >> > In my usage scenario I do not have any queues - just two jms topics.
> >> > Multiple producers, multiple consumers. What I've been trying to
> figure
> >> out
> >> > is if I can away with not having a <ha-policy>. The clustered topic
> >> example
> >> > seems to indicate that with a message-load-balancing set to STRICT
> that
> >> > it'll copy messages to other nodes in the cluster if a corresponding
> >> topic
> >> > already exists there. My understanding from reading the docs is that
> >> this a
> >> > true copy (potentially async I assume) vs something like a
> read-through
> >> > from one node to another when the message doesn't exist on the local
> >> node.
> >> > Is that correct?
> >> >
> >> > If the above is correct and the fact that I don't have a requirement
> to
> >> be
> >> > able to recover messages after a full cluster restart is there any
> reason
> >> > to have a ha-policy set? The only reason I can think of is to sync
> >> messages
> >> > in the topic between shutdown and restart of a node in the cluster
> prior
> >> to
> >> > clients reconnecting to that node so that the client(s) may not miss
> >> > messages (potential dup are ok in my use case). That's pretty
> important
> >> but
> >> > I'm not sure I have can both the clustered jms topics in a symmetrical
> >> > cluster and have a ha-policy (ala [master0/slave1] <-->
> >> [master1/slave0]).
> >> > Is that possible?
> >> >
> >> > Thanks!
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >>
>
>
>
> --
> Clebert Suconic
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Artemis question on JMS clustered topic and high availability

clebertsuconic
You are still bound to connect retries and TTLs. So I would say that a good
reaction time would be 30s.  You can decrease that but I am not sure I
recommend it.



It's up to you thought.  If I was implementing my own system I would prefer
the cloud infra since you are AWS.  I believe that's what most cloud
systems do on their back end when you hire Messaging for instance.  Just
trying to help.





On Wed, Jan 11, 2017 at 5:28 PM Bruce Ritchie <[hidden email]>
wrote:

> Thanks for the response. The paired LiveA/BackupB + LiveB/BackupA is what I
>
> was wondering out with the JMS clustered topic. I'd like to not rely on
>
> infrastructure to restart because of the latency that involves - I'd like
>
> to keep any hiccups to < 1 sec if possible.
>
>
>
> On Wed, Jan 11, 2017 at 1:46 PM, Clebert Suconic <
> [hidden email]>
>
> wrote:
>
>
>
> > You are using AWS. Do you have the storage disk? or is it transient?
>
> >
>
> >
>
> > What I have been suggesting to cloud user is to just monitor their
>
> > system, and have the system restarting itself in case of a failure.
>
> > That is the best scenario you can get since the infra-structure would
>
> > give you the needed HA.
>
> >
>
> >
>
> > If you don't, you will need to setup a backup/live pair for each system.
>
> >
>
> >
>
> > The only difference is that you can do that with just 2 boxes...
>
> >
>
> > Box1: LiveA and BackupB
>
> > Box2: LiveB and BackupA
>
> >
>
> >
>
> > That's a possible example / solution.
>
> >
>
> >
>
> >
>
> > We have a colocated topology that was developed for wildfly or
>
> > embedded systems, but I would recommend you keeping it as simple as
>
> > possible... either have the infra-structure restarting itself if you
>
> > have the storage... or have a backup pair like I'm suggesting here.
>
> >
>
> >
>
> >
>
> >
>
> > I feel like I missed answering something here.. let me know if I am...
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > On Wed, Jan 11, 2017 at 12:07 PM, Bruce Ritchie <[hidden email]
> >
>
> > wrote:
>
> > > Your reply is much appreciated. So crossing master/slave is only
> possible
>
> > > in a colocated environment? If so I think that's doable in my
> situation.
>
> > >
>
> > > "what you are looking is having a copy of the topic subscription on
> every
>
> > > node, making it a single cluster among different nodes,"
>
> > >
>
> > > Is there an example of this I can work from? I previously was working
>
> > from
>
> > > the example @
>
> > > https://github.com/apache/activemq-artemis/tree/1.x/
>
> > examples/features/clustered/clustered-topic
>
> > >
>
> > >
>
> > > Thanks!
>
> > >
>
> > >
>
> > > On Wed, Jan 11, 2017 at 11:53 AM, Clebert Suconic <
>
> > [hidden email]
>
> > >> wrote:
>
> > >
>
> > >> when you have a topic subscription in cluster.. the message will be
>
> > >> copied to every subscription on the cluster connection (or network of
>
> > >> brokers)...
>
> > >>
>
> > >>
>
> > >> When you have the same subscription among different nodes.. (that
>
> > >> is... the same core-queue name on more than one node), then
>
> > >> load-balancing will have a play...
>
> > >>
>
> > >>
>
> > >> what you are looking is having a copy of the topic subscription on
>
> > >> every node, making it a single cluster among different nodes, and
>
> > >> that's not what you have here. You would need a backup to save the
>
> > >> acks between two servers.
>
> > >>
>
> > >>
>
> > >> you can have multiple master/slaves on your environment, and even
>
> > >> cross them on a colocated environment, having a phisical server with 2
>
> > >> live nodes in case of failures.
>
> > >>
>
> > >>
>
> > >>
>
> > >> Don't know if that helps?
>
> > >>
>
> > >> On Tue, Jan 3, 2017 at 2:30 PM, Bruce Ritchie <
> [hidden email]>
>
> > >> wrote:
>
> > >> > I've been investigating switching from a single activemq server to a
>
> > >> > cluster of artemis servers on aws and I have a question on clustered
>
> > jms
>
> > >> > topics and high availability.
>
> > >> >
>
> > >> > Firstly, I like the idea that the producers/consumers can connect to
>
> > any
>
> > >> > node in the cluster and fail over (client side) to a different node
>
> > if a
>
> > >> > node goes down without loosing any messages with the understanding
>
> > that
>
> > >> the
>
> > >> > producers may have to retry submissions.
>
> > >> >
>
> > >> > In my usage scenario I do not have any queues - just two jms topics.
>
> > >> > Multiple producers, multiple consumers. What I've been trying to
>
> > figure
>
> > >> out
>
> > >> > is if I can away with not having a <ha-policy>. The clustered topic
>
> > >> example
>
> > >> > seems to indicate that with a message-load-balancing set to STRICT
>
> > that
>
> > >> > it'll copy messages to other nodes in the cluster if a corresponding
>
> > >> topic
>
> > >> > already exists there. My understanding from reading the docs is that
>
> > >> this a
>
> > >> > true copy (potentially async I assume) vs something like a
>
> > read-through
>
> > >> > from one node to another when the message doesn't exist on the local
>
> > >> node.
>
> > >> > Is that correct?
>
> > >> >
>
> > >> > If the above is correct and the fact that I don't have a requirement
>
> > to
>
> > >> be
>
> > >> > able to recover messages after a full cluster restart is there any
>
> > reason
>
> > >> > to have a ha-policy set? The only reason I can think of is to sync
>
> > >> messages
>
> > >> > in the topic between shutdown and restart of a node in the cluster
>
> > prior
>
> > >> to
>
> > >> > clients reconnecting to that node so that the client(s) may not miss
>
> > >> > messages (potential dup are ok in my use case). That's pretty
>
> > important
>
> > >> but
>
> > >> > I'm not sure I have can both the clustered jms topics in a
> symmetrical
>
> > >> > cluster and have a ha-policy (ala [master0/slave1] <-->
>
> > >> [master1/slave0]).
>
> > >> > Is that possible?
>
> > >> >
>
> > >> > Thanks!
>
> > >>
>
> > >>
>
> > >>
>
> > >> --
>
> > >> Clebert Suconic
>
> > >>
>
> >
>
> >
>
> >
>
> > --
>
> > Clebert Suconic
>
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Artemis question on JMS clustered topic and high availability

Bruce Ritchie
Ok, that makes sense. I'll play around with things some more and see what I
come up with. Thanks for the help!

On Wed, Jan 11, 2017 at 7:43 PM, Clebert Suconic <[hidden email]>
wrote:

> You are still bound to connect retries and TTLs. So I would say that a good
> reaction time would be 30s.  You can decrease that but I am not sure I
> recommend it.
>
>
>
> It's up to you thought.  If I was implementing my own system I would prefer
> the cloud infra since you are AWS.  I believe that's what most cloud
> systems do on their back end when you hire Messaging for instance.  Just
> trying to help.
>
>
>
>
>
> On Wed, Jan 11, 2017 at 5:28 PM Bruce Ritchie <[hidden email]>
> wrote:
>
> > Thanks for the response. The paired LiveA/BackupB + LiveB/BackupA is
> what I
> >
> > was wondering out with the JMS clustered topic. I'd like to not rely on
> >
> > infrastructure to restart because of the latency that involves - I'd like
> >
> > to keep any hiccups to < 1 sec if possible.
> >
> >
> >
> > On Wed, Jan 11, 2017 at 1:46 PM, Clebert Suconic <
> > [hidden email]>
> >
> > wrote:
> >
> >
> >
> > > You are using AWS. Do you have the storage disk? or is it transient?
> >
> > >
> >
> > >
> >
> > > What I have been suggesting to cloud user is to just monitor their
> >
> > > system, and have the system restarting itself in case of a failure.
> >
> > > That is the best scenario you can get since the infra-structure would
> >
> > > give you the needed HA.
> >
> > >
> >
> > >
> >
> > > If you don't, you will need to setup a backup/live pair for each
> system.
> >
> > >
> >
> > >
> >
> > > The only difference is that you can do that with just 2 boxes...
> >
> > >
> >
> > > Box1: LiveA and BackupB
> >
> > > Box2: LiveB and BackupA
> >
> > >
> >
> > >
> >
> > > That's a possible example / solution.
> >
> > >
> >
> > >
> >
> > >
> >
> > > We have a colocated topology that was developed for wildfly or
> >
> > > embedded systems, but I would recommend you keeping it as simple as
> >
> > > possible... either have the infra-structure restarting itself if you
> >
> > > have the storage... or have a backup pair like I'm suggesting here.
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > I feel like I missed answering something here.. let me know if I am...
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > On Wed, Jan 11, 2017 at 12:07 PM, Bruce Ritchie <
> [hidden email]
> > >
> >
> > > wrote:
> >
> > > > Your reply is much appreciated. So crossing master/slave is only
> > possible
> >
> > > > in a colocated environment? If so I think that's doable in my
> > situation.
> >
> > > >
> >
> > > > "what you are looking is having a copy of the topic subscription on
> > every
> >
> > > > node, making it a single cluster among different nodes,"
> >
> > > >
> >
> > > > Is there an example of this I can work from? I previously was working
> >
> > > from
> >
> > > > the example @
> >
> > > > https://github.com/apache/activemq-artemis/tree/1.x/
> >
> > > examples/features/clustered/clustered-topic
> >
> > > >
> >
> > > >
> >
> > > > Thanks!
> >
> > > >
> >
> > > >
> >
> > > > On Wed, Jan 11, 2017 at 11:53 AM, Clebert Suconic <
> >
> > > [hidden email]
> >
> > > >> wrote:
> >
> > > >
> >
> > > >> when you have a topic subscription in cluster.. the message will be
> >
> > > >> copied to every subscription on the cluster connection (or network
> of
> >
> > > >> brokers)...
> >
> > > >>
> >
> > > >>
> >
> > > >> When you have the same subscription among different nodes.. (that
> >
> > > >> is... the same core-queue name on more than one node), then
> >
> > > >> load-balancing will have a play...
> >
> > > >>
> >
> > > >>
> >
> > > >> what you are looking is having a copy of the topic subscription on
> >
> > > >> every node, making it a single cluster among different nodes, and
> >
> > > >> that's not what you have here. You would need a backup to save the
> >
> > > >> acks between two servers.
> >
> > > >>
> >
> > > >>
> >
> > > >> you can have multiple master/slaves on your environment, and even
> >
> > > >> cross them on a colocated environment, having a phisical server
> with 2
> >
> > > >> live nodes in case of failures.
> >
> > > >>
> >
> > > >>
> >
> > > >>
> >
> > > >> Don't know if that helps?
> >
> > > >>
> >
> > > >> On Tue, Jan 3, 2017 at 2:30 PM, Bruce Ritchie <
> > [hidden email]>
> >
> > > >> wrote:
> >
> > > >> > I've been investigating switching from a single activemq server
> to a
> >
> > > >> > cluster of artemis servers on aws and I have a question on
> clustered
> >
> > > jms
> >
> > > >> > topics and high availability.
> >
> > > >> >
> >
> > > >> > Firstly, I like the idea that the producers/consumers can connect
> to
> >
> > > any
> >
> > > >> > node in the cluster and fail over (client side) to a different
> node
> >
> > > if a
> >
> > > >> > node goes down without loosing any messages with the understanding
> >
> > > that
> >
> > > >> the
> >
> > > >> > producers may have to retry submissions.
> >
> > > >> >
> >
> > > >> > In my usage scenario I do not have any queues - just two jms
> topics.
> >
> > > >> > Multiple producers, multiple consumers. What I've been trying to
> >
> > > figure
> >
> > > >> out
> >
> > > >> > is if I can away with not having a <ha-policy>. The clustered
> topic
> >
> > > >> example
> >
> > > >> > seems to indicate that with a message-load-balancing set to STRICT
> >
> > > that
> >
> > > >> > it'll copy messages to other nodes in the cluster if a
> corresponding
> >
> > > >> topic
> >
> > > >> > already exists there. My understanding from reading the docs is
> that
> >
> > > >> this a
> >
> > > >> > true copy (potentially async I assume) vs something like a
> >
> > > read-through
> >
> > > >> > from one node to another when the message doesn't exist on the
> local
> >
> > > >> node.
> >
> > > >> > Is that correct?
> >
> > > >> >
> >
> > > >> > If the above is correct and the fact that I don't have a
> requirement
> >
> > > to
> >
> > > >> be
> >
> > > >> > able to recover messages after a full cluster restart is there any
> >
> > > reason
> >
> > > >> > to have a ha-policy set? The only reason I can think of is to sync
> >
> > > >> messages
> >
> > > >> > in the topic between shutdown and restart of a node in the cluster
> >
> > > prior
> >
> > > >> to
> >
> > > >> > clients reconnecting to that node so that the client(s) may not
> miss
> >
> > > >> > messages (potential dup are ok in my use case). That's pretty
> >
> > > important
> >
> > > >> but
> >
> > > >> > I'm not sure I have can both the clustered jms topics in a
> > symmetrical
> >
> > > >> > cluster and have a ha-policy (ala [master0/slave1] <-->
> >
> > > >> [master1/slave0]).
> >
> > > >> > Is that possible?
> >
> > > >> >
> >
> > > >> > Thanks!
> >
> > > >>
> >
> > > >>
> >
> > > >>
> >
> > > >> --
> >
> > > >> Clebert Suconic
> >
> > > >>
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > Clebert Suconic
> >
> > >
> >
> >
>
Loading...