One last thought: if the queue is overfull with persistent messages following the reconfiguration, and the broker is restarted, what happens to the queue during recovery?
On 13 June 2017 at 17:18, Robbie Gemmell <[email protected]> wrote: > (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]
