qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: [DISCUSSION] Queue Reject Policy Behaviour
Date Tue, 13 Jun 2017 18:52:33 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message