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: [email protected] For additional commands, e-mail: [email protected]
