A suggested implementation is:
Send the deleted messages to the alternate exchange associated with a queue. That would let any application detect them by binding to that exchange as appropriate. That is also more susceptible to ACL control.

To avoid this mechanism causing build up of messages that the ring policy is attempting to avoid, the queue bound to the alternate exchange could have be a ring queue of size 1, meaning it only ever held the last message which I think would be sufficient to notify of the dropping of messages.

So for the application, the following would happen:

• create an alternate exchange for use with the ring queue
• create the ring queue, associating it with the alternate exchange
• create an overflow ring queue with max-count=1
• bind the overflow queue with the alternate exchange

• watch the overflow queue. When a message appears, the original queue is full and has just overflowed.
• remove the overflow message

I think QMF should be able to help you

ad QMF)
An QMF event informing about the overwriting isn't a bad idea. But the problem with QMF is that it cannot be properly secured with ACL. So for some Qpid users (in our situation a broker used to connect hundreds of customers to our service) we cannot really provide the access to the QMF without causing possible security issues.

ad alt exchange)
I can imagine to create a construct using an alternate exchange as described by Ernest. But such construct will be not exactly user friendly. This will get additionally complicated when you are working with multiple ring-type queues receiving the same messages at the same time - some of them having the messages overwritten and some of them not. You would need to have for each ring type queue a separate alternate exchange with another small ring-type signal queue. Also, it is a bit "overkill" to resend all the messages to alternate exchange just to give a "signal" that they are being overwritten. When you create the ring type queue, you usually expect the messages to get lost - you just want to know when it happens.

I would maybe suggest following solutions ...

1) Assigning a new custom header to the remaining message(s) which will mark that some messages were overwritten (i.e. something similar to the redelivered flag).

or

2) Adding a queue level message sequencing which would work in a similar way as the exchange level sequencing, but the sequence IDs will be assigned only to the messages which are routed into the queue (+ the sequence will be persisted to possibly survive the restart of the broker - unlike with the exchange level sequencing). The sequence IDs can be used by the client to detect gaps. (this is from my perspective the best solution)

An approach currently under review:

https://reviews.apache.org/r/11009/

Adds mechanism to store and retrieve a queue level sequence number in message properties.

To enable storing of sequence numbers, declare queue with argument qpid.queue_msg_sequence set to user defined key.
To retrieve the sequence number from a message, get the message properties using the same user defined key.

std::string addr("my-queue;"
" {create:always, delete:always,"
" node: {type: queue, x-declare: {arguments:"
" {qpid.queue_msg_sequence:my_seq_key, qpid.policy_type:ring, qpid.max_count:4}}}}");

Sender sender = session.createSender(addr);

...

Receiver receiver = session.createReceiver("my-queue");

Message response = receiver.fetch();
uint32_t seqNo = response.getProperties()["my_seq_key"];
if (seqNo - lastSeqNo > 1)
//Gap detected. Messages were overwritten
...

Ernie's patch applied as http://svn.apache.org/r1485001

New python tests excluded from runs against the Java broker in http://svn.apache.org/r1485953

(oops, sorry Robbie!)

Not to worry, only noticed this morning that they were failing as we had previously broken the test job itself

Gordon, is there any more work remaining for this issue?

Not directly. As noted in the review linked to above, the addAnnotations() method this change uses currently has a significant impact on performance. I have put up a patch for review at https://reviews.apache.org/r/11329/ that minimises the impact.

Released in Qpid 0.24, http://qpid.apache.org/releases/qpid-0.24/index.html