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 <howard....@gmail.com> wrote:
> Hi guys,
>
> I'm working on this story and I'd like to hear your thoughts.
>
> The Jira: https://issues.apache.org/jira/browse/ARTEMIS-2097
>
> 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:
> https://github.com/apache/activemq-artemis/pull/2371
>
> 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
>
