activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: Artemis question on JMS clustered topic and high availability
Date Thu, 12 Jan 2017 00:43:55 GMT
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 <bruce.ritchie@gmail.com>
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 <
> clebert.suconic@gmail.com>
>
> 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 <bruce.ritchie@gmail.com
> >
>
> > 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 <
>
> > clebert.suconic@gmail.com
>
> > >> 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 <
> bruce.ritchie@gmail.com>
>
> > >> 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
>
> >
>
>

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