activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Ritchie <bruce.ritc...@gmail.com>
Subject Re: Artemis question on JMS clustered topic and high availability
Date Thu, 12 Jan 2017 12:38:24 GMT
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 <clebert.suconic@gmail.com>
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 <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