Hi Paul, There is some logging in this area indicating that the broker did encounter the overflow condition but it is not configurable and not as extensive as you suggest.
The reason is that logging (most commonly to disk) can be quite expensive and we want to minimize this on the critical (message delivery) path. Kind regards, Lorenz On Tue, 2017-06-13 at 15:45 +0000, Flores, Paul A. wrote: > Hi Lorenz, > > I am not one usually to "pipe in" to discussion so I am be a bit off topic. > I did read Adel's discussion replies which I found interesting. > > I am not all that familiar with the configuration details so please forgive > my ignorance. > > Is it possible to opt to have a specific message placed into a log (perhaps > queue specific) to indicate any or all of the following?: > * queue name > * time > * that the message queue limit was exceeded and > ** that the queue was configured to either > - push an older message off of "the top" of the queue > or > - ignore/ not place a new message onto the queue > or > - push a message with a specific characteristics such as importance > * Impacted Message details to include: > ** sender information > ** timestamp when message was originally received > ** message characteristic used in determination action > Just an idea. > > Paul > > From: Lorenz Quack <quack.lor...@gmail.com> > Sent: Tuesday, June 13, 2017 3:21 AM > To: Qpid Users > Subject: [DISCUSSION] Queue Reject Policy Behaviour > > 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 > > > > This communication (including any attachments) may contain information that > is proprietary, confidential or exempt from disclosure. If you are not the > intended recipient, please note that further > dissemination, distribution, use or copying of this communication is strictly > prohibited. Anyone who received this message in error should notify the > sender immediately by telephone or by return > email and delete it from his or her computer. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
