This is lot easier in C++ broker where you cannot change the policy or the limits once you create the queue :-). But as a user I would have appreciated the possibility to change the limits on the fly many times, so I'm not suggesting this is the way to go.
>From your possibilities B) would be what I would expect. I assume that it is quite easy to change the limit and purge some messages in two steps if the operator wants to do that. I can also imagine another possibility, where you don't allow the operator to set the limit below the actual queue size. I.e.: - user can freely increase the limit - If the queue has limit 1000 messages and 100 actual messages inside, user can change the limit to 101 or 100. But not to 99. This would ensure that the limit is always kept and leave the task to decide what to delete or not to delete on the operator. But I guess this might be also non-trivial to implement so that it doesn't run into any race conditions etc. Regards Jakub On Tue, Jun 13, 2017 at 11:21 AM, Lorenz Quack <quack.lor...@gmail.com> 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 > >
