Hello Lorenz,
In my opinion, it depends on the context and there is no general rule for this. For example, if your queue has some sensitive data and your producers considers the messages available. So they will never send them back. If you delete the messages which overflow the queue, you will lose this important information (which could be Bank accounts for example). If on the other hand, your system is capable of overcoming message loss by resending the messages then you have no problem in silently deleting them. So instead of forcing a behavior, I think the choice should be left to the operator when defining the policy (per queue would be even better): A) He would explicitly choose to silently delete all overflowing messages immediately B) He would explicitly choose to ignore current overflowing messages C) He would explicitly define a period after which current overflowing messages would be deleted (A would be a specific implementation of C) Regards, Adel ________________________________ From: Lorenz Quack <quack.lor...@gmail.com> Sent: Tuesday, June 13, 2017 11:22:31 AM To: Qpid Users Subject: Re: [DISCUSSION] Queue Reject Policy Behaviour 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
