activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Gao <>
Subject Re: [discussion] About blocking producers
Date Wed, 17 Oct 2018 02:02:50 GMT
Thanks Gary, you are quite right. This seems not a simple problem as I
think is. The pause/resume is even harder to implement.

And also the credit thing, some client support it (but may or may not use
it), some are totally without it (like mqtt and stomp).


On Tue, Oct 16, 2018 at 6:57 PM Gary Tully <> wrote:

> There may be two different use cases here;
> 1) the pause/resume use case, where it makes some sense to leave producers
> active stop reading/deny credit/buffer etc; the corollary to the pause
> consumers
> 2) the take down for maintenance case, where it would be nice to drain the
> broker.
>      In the past, users have tackled the "maintenance" use case with
> separate acceptors, one for producers and one for consumers. with the
> ability to disable an acceptor via a management operation. That is not
> ideal b/c it requires cooperation with the applications to use the correct
> acceptors etc.
>    However it is a coarse grained option that is a step to shutdown, a one
> way step that won't be undone via resume. That can more easily be
> implemented with a management op that kills off producers and blocks all
> send operations with some deny interceptor (along the lines of the
> authorisation interceptors). something like shutdownSenders
> If the use case is more like shutdownSenders keeping it coarse (on or off
> for the entire server) will be best.
> For the pause/resume case it gets tricky;
>  - for example if the same connection is used for producing and consuming,
> any exception can be fatal for the connection, causing retries etc and
> looping.
>  - blocking will only work for sync send operations and async operations
> may accumulate. It may require protocol specific smarts.
>  - same for of credit, only where flow control is respected by the client.
> I guess my point is that pause/resume may not be the way to go if the use
> case is actually shut down for maintenance.
> On Tue, 16 Oct 2018 at 04:19 Howard Gao <> wrote:
> > Hi guys,
> >
> > I'm working on this story and I'd like to hear your thoughts.
> >
> > The Jira:
> >
> > This is to provide a functionality of the broker to block on producers so
> > that user can consume all the existing messages (for maintaining their
> > servers for example), regardless of how the address setting's address
> full
> > policy is configured. The unblock
> > functionality should also be provided to complete this feature.
> >
> > Here is my current implementation:
> >
> >
> > The idea is to keep a list of blocked/unblock addresses set by the user.
> > Any incoming messages will be checked against the list and if its address
> > is blocked, it will be rejected and an exception will be thrown to the
> > clients.  It works for all types of clients (core, openwire, jms, mqtt
> > etc).
> >
> > Any comments are welcome.
> >
> > Thanks
> > Howard
> >

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