activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <>
Subject Re: Marking a destination read-only?
Date Thu, 05 Feb 2015 02:24:18 GMT
On Wed, Feb 4, 2015 at 1:29 PM, Tim Bain <> wrote:

> 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.
That’s actually the way we handled it on our end but we did it via

We’re planning on using an cluster of brokers but right now just have 1.
We’re going to use our confirmation management system to update a conf file
marking a box “read only” but this is really only a suggestion.

A hard read only is needed for errand/insane clients.

> 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),

Yes.  exactly.  producers fail to the deprecated broker.

> 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)

One issue are delay queues.

So if you have something scheduled for a week from now, they wouldn’t be
consumed immediately.  :-(

So this confuses this elegant system.

I was thinking it might be valuable to expose delay queues as totally
normal queues.  Maybe with a prefix.. then you could consume them and write
them to the new broker.

However, what I need this for is so that I can close out a destination and
be certain that nothing can write to it so that I can know that it’s closed
and not serviced in the future.


Location: *San Francisco, CA*
… or check out my Google+ profile

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