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: Marking a destination read-only?
Date Sun, 08 Feb 2015 12:52:49 GMT
Art,

What you described would handle queues but not topics (particularly ones
with non-durable consumers, where the messages will be discarded as soon as
the client-facing transport connector is shut down), and any successful
migration feature would need to handle both.  Plus you run the risk of
out-of-order delivery when you shovel the messages over to another broker
if messages are being produced on that other broker at the time, so it
would be better to let consumers keep consuming from the original broker
for as long as possible to keep messages in order as much as possible.

Your idea of two transport connectors is interesting, and allows a partial
solution: if producers always produced on on connector and consumers always
consumed on another, you could shut down the producer transport connector
(so producers would fail over before consumers) and leave up the consumer
one till they'd finished consuming messages, then shut it down so the
consumers failed over as well.  This would ensure in-order delivery while
still letting clients fail to the new broker.

But there are a number of problems with that approach:
1. Consumers fail over all at once, so you have to wait for the last
consumer to finish before the whole group fails over.  A slow or
disconnected consumer would kill this approach.
2. Broker-to-broker transport connectors could not be duplex, because you
need to be able to prevent messages from being forwarded to this broker
while allowing the broker to forward them to another broker if a consumer
shows up elsewhere in the network.
3. If the producers move to the new broker before the consumers and the old
broker is no longer accepting messages, will messages be held till the
consumer fails over if the consumer is non-durable, or will they just be
discarded?  I suspect the latter, which would be a problem.
4. As Kevin pointed out, none of these ideas handle scheduled messages.

For all of those reasons (and probably others), I think there's probably a
need for built-in support for rolling from one broker to another at a
destination-by-destination granularity, because I don't think the current
built-in features support that use case adequately.  (We wouldn't use
either what you described or what I described, since neither one guarantees
delivery of all messages, let alone in order.)

A different approach that almost works is to start the new broker as a
slave to the first, and then kill the master to let master-slave do its
thing.  We'd use that approach if we could, but we use non-persistent
messages for speed and with the abandonment of pure master-slave that's not
an option anymore.  And it doesn't work if you're using a NoB for
load-balancing purposes where you want to ease clients off of one node so
you can do maintenance on it.  But it might work for some people in some
cases.

Tim
On Feb 8, 2015 7:09 AM, "artnaseef" <art@artnaseef.com> wrote:

> One straight-forward strategy to draining a broker:
>
> * setup the broker with a separate transport connector dedicated to
> draining
> the broker
> * stand up the new broker (if not already running)
> * stand up routes (using camel or the like) or one-way bridges that move
> messages in one direction only - from the "wind-down" broker to the newly
> active broker
> * stop all of the transport connectors except the one dedicate to broker
> drainage
> * wait until all of the queues are drained
> * shutdown the broker
>
> I started a proof-of-concept tool on github that can create external,
> one-way bridges on-demand and makes it easy to manage the same.  If you're
> interested, I'll point you at it.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Marking-a-destination-read-only-tp4691065p4691187.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

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