On 13 June 2017 at 10:22, Lorenz Quack <quack.lor...@gmail.com> wrote: > Hello, > > I personally would expect behaviour B). > > As an application I would expect a REJECT policy I either accept or > reject a message I send. Silently "rejecting" it retrospectively > seems counter-intuitive to me. > > On the other hand, behaviour A) would bring it more in line with some of > the other overflow policies that immediately react to a change in the > limits. > That being said I would still vote for behaviour A). > > Kind regards, > Lorenz > > > On Tue, 2017-06-13 at 10:21 +0100, Lorenz Quack wrote: >> Hello all, >> >> QPID-7815 [1] proposes the addition of a Queue Overflow Reject Policy >> to the Qpid broker-j (aka Qpid Broker for Java) component. >> >> Queue's allow to define overflow limits (in term of number of messages >> and/or cumulative size of the messages). If the limit is breached the >> overflow policy determines the behaviour. There are three ways the >> limits can be breached. >> >> 1) A new message arrives at the queue pushing it over the limit. >> >> 2) An operator lowers the limit so that existing messages are in >> breach of the limit. >> >> 3) An operator changes the policy. For example from a No-op policy >> to the reject policy under discussion. >> >> The behaviour of the proposed policy in case 1) is fairly straight >> forward and I think uncontroversial. This discussion thread is to >> hash out the expected behaviour in case of operator intervention, >> i.e. case 2) and 3). >> >> I see two possible behaviours: >> >> A) The policy silently deletes messages that are in breach of the >> policy. >> >> B) The policy ignores messages that are already on the queue and >> only applies to messages that newly arrive. >> >> >> What would people expect the behaviour to be? >> Please discuss. >> >> >> Kind regards, >> Lorenz >> >> >> [1] https://issues.apache.org/jira/browse/QPID-7815 >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org >
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
