qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorenz Quack <quack.lor...@gmail.com>
Subject Re: [DISCUSSION] Queue Reject Policy Behaviour
Date Tue, 13 Jun 2017 12:37:29 GMT
Hello Adel,

Thanks for your feedback.

You are right that the desired behaviour depends on the context of
your application.  However, I want to avoid adding configuration
options where it is not necessary.  IMHO, the broker-j already suffers
from an abundance of configuration options and I do not want to
exacerbate the problem.

So is the configuration you suggest necessary/useful?  Let me examine
the three options you provided:
  
  A) If an operator wishes this behaviour but we actually implement B)
     then the operator could still manually/explicitly delete messages
     from the queue until it is within the new limits.

  B) This is still my preferred behaviour.
  
  C) I have a hard time coming up with an example where this would be
     useful or desirable.  As you pointed out in the beginning of your
     email an application typically regards its messages as critical
     (no message loss acceptable) or as dispensable (message loss
     acceptable).  Choosing to discard messages but using a timeout
     period seems to indicate conflicting goals.  If the messages
     themselves become interesting TTL should be used instead.
     Do you have a use case in mind where this would be useful?

Note that I do not expect this situation to come about very often.
Typically a queue is configured and then left alone.  Changing the
overflow policy and/or the overflow limits on a live queue should be
very rare.

Kind regards,
Lorenz


On Tue, 2017-06-13 at 10:15 +0000, Adel Boutros wrote:
> 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.lorenz@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-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