qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Re: [DISCUSSION] Queue Reject Policy Behaviour
Date Tue, 13 Jun 2017 20:20:26 GMT
In the Qpid C++ broker you *can* reload the policy on-the-fly. C++ broker
policy allows existing connections or other quotas that are in excess of the
new policy limits to persist. As old connections or queues are disposed 
eventually the user goes within the new policy limits and at that point new
items may be created. This behavior is Lorenz' original type B.

An administrator is free to delete queues or close connections as he wishes.
Having the policy itself delete queues or close connections would be
indeterminate. That's why we stuck with strategy B. That makes the most
sense to me for similar decisions.

-Chuck

----- Original Message -----
> From: "Jakub Scholz" <jakub@scholz.cz>
> To: users@qpid.apache.org
> Sent: Tuesday, June 13, 2017 2:52:33 PM
> Subject: Re: [DISCUSSION] Queue Reject Policy Behaviour
> 
> 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.lorenz@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message