(This time, sending with actual content :P) I'm reading the below as meaning that you would vote for B, rather than A as you ended with. If so, I would agree.
I think Adel is correct that different people will have different answers, but I expect the people who sent the message would find it unexpected that it got dropped after successfully being sent, particularly if they are aware of existing use of a reject policy and that send failure would typically relate to that. That said, I also expect it to be rare for people to reduce the limit on a live system with messages people care about. I don't think I would make it configurable, its extra complexity for whats likely to be limited or no usage. If the queue remains overfull, as you said the operator should be able to delete messages that might have been dropped if needed. To Adel's point, the operator would need to do pretty much the same the broker itself would; by making some aribtrary decision such as the first or last <x> messages on the queue. Robbie On 13 June 2017 at 10:22, Lorenz Quack <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
