Hi Robbie, That is an excellent question. I haven't checked but I fear it will apply the policy to the existing messages. Thanks for bringing this up.
Kind regards, Lorenz On Tue, 2017-06-13 at 17:19 +0100, Robbie Gemmell wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
