This sounds like one way to do it. Most users need secured brokers and they can adopt this method.
Thanks On Wed, Oct 17, 2018 at 1:59 PM michael.andre.pearce <michael.andre.pea...@me.com.invalid> wrote: > Because our brokers are fully secured, if we need to stop incoming > messages we simply remove the produce authorisation for users using > security settings. > This seems to work. Is this maybe an option for you? > > > Sent from my Samsung Galaxy smartphone. > -------- Original message --------From: Howard Gao <howard....@gmail.com> > Date: 17/10/2018 04:02 (GMT+01:00) To: dev@activemq.apache.org Subject: > Re: [discussion] About blocking producers > 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). > > Howard > > On Tue, Oct 16, 2018 at 6:57 PM Gary Tully <gary.tu...@gmail.com> 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 <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 > > > > > >
