activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Marking a destination read-only?
Date Wed, 04 Feb 2015 21:29:32 GMT
If such a capability was built, maybe it could be extended to handle
deprecating a broker to allow clients to migrate off of it in preparation
for taking it offline during an upgrade, which is something Art has
highlighted previously as an Achilles heel for ActiveMQ upgrades.

You'd stand up a new broker that's federated to the old one, then mark the
entire old broker as read-only (which would get applied to all the
destinations).  Producers connected to the old broker would immediately be
fed a command to disconnect and the broker wouldn't accept any more
connections for producers (including due to failover attempts from those
just-disconnected producers), so they'd fail to the new broker
immediately.  Consumers attached to the old broker would consume until
their destination ran dry, and then they would be fed a similar disconnect
command and the broker would not accept any new connections for consumers
(including due to failover attempts), so they too would fail to the new
broker.  Once that had happened for all producers and consumers on all
destinations, it would be safe to shut down the old broker, without having
lost any messages.

The only complicated thing would be figuring out how to set up
subscriptions on the new broker for the existing consumers on a topic while
they're still connected to the old broker, so that messages published to
the new broker would be available once the consumer failed over to the new
broker, and I'm not sure I've got an approach for that, though hopefully
someone else will know of a way to make that easy.


On Wed, Feb 4, 2015 at 10:53 AM, Kevin Burton <> wrote:

> Is there a way to mark a destination as read only?
> This way I could accept messages on a destination temporarily, and then
> mark it read only.
> This could be used to decommission a queue or to have clients start writing
> to another queue after their messages fail.
> Kevin
> --
> Founder/CEO
> Location: *San Francisco, CA*
> blog:
> … or check out my Google+ profile
> <>
> <>

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