This content has been marked as final. Show 6 replies
I don't know anything about EBS and it's AQ usage but you are correct about multiple subscribers, a message only gets removed when all of the subscribers have processed it.
I guess my first question (not knowing anything about EBS) is why aren't the other subscriber messages being consumed?
You could set the expiration time but then you are going to end up with loads of EXPIRED messages in the exception queue which seems pointless.
Just to confirm, you are seeing some movement to PROCESSED but others are READY (i.e. the same message but different consumer_name)?
Nope. All i see are events still waiting in ready state. with the DEQ_TXN_ID indicating value RETRY_EXCEEDED
So if no messages are being processed and they are all going to retry exceeded then something is going wrong in the DQ process and resulting in a failure to complete the DQ.
What does these queries give?
select queue,consumer_name,msg_state,expiration_reason,count(*) from aq$<queue_table_name> group by queue,consumer_name,msg_state,expiration_reason; select owner,name,queue_type,max_retries,retry_delay from dba_queues where queue_table = '<QUEUE_TABLE_NAME>';
Nothing is on the exception queue and EXPIRATION_REASON is null - what is leading you to think these messages are exceeding the retries (which incidentally is zero so no retries)?
What process is supposed to be consuming these messages? you may be better off in the EBS forum as there might be something applicaiton specific which is not obvious to me.
All I am seeing is a Q with many READY (i.e. unprocessed | waiting to be processed) messages.
I don't know if this issue is solved already (question is not marked answered).
But I see that the messages seem to have consumer-names that seem to be generated. Apparently there are no consuming processes that consume the messages with these consumer names. So it might have to do with how the message producing process creates those messages.
If the consumernames reflect some kind of correlation I would suggest to use the CorrelationID property instead.
Make sure that you have consuming processes that use these consumer name and make sure that all messages that are produced are consumed.
If the table get's filled more and more the queuetable may grow and might decrease your queueing performance.