I have followed the steps described in the following article.
1. I have set up a queue manager on MQ with queues
OMG_OUT_LOG_QUEUE and OMG_MQ_QUEUE
2.Had to modify "schedule is necessary for transferring messages from AQ to MQ" from
source => 'apps.OMG_SAMPLE_QUEUE', to
source => 'SYS.OMG_SAMPLE_QUEUE' as this was causing error.
When I am trying to put the message on to AQ to transfer it to MQ, I am getting the following
ORA-24033: No recipients for the message.
Can anyone help with the above error?
Hi, this reply sounds strange to me.
The AQ user's guide says: Publish/subscribe describes a situation in which a publisher application enqueues messages to a queue anonymously (no recipients specified). The messages are then delivered to subscriber applications based on rules specified by each application.
Thus it should be allowed to have an empty recipient list - where consumers are defined by a dynamic subscriber list.
When a queue is a multi-consumer queue you need to either specify a recipient list on enqueue or have added a default subscriber to the queue in order to avoid the ORA-24033 error.
You can also get an ORA-24033 if you have a rules-based subscriber on the queue and the rule evaluates to false on enqueue and will result in the ORA-24033.
Yes, and the very most annoying thing is, that a similar Java setup does NOT return any information that the message is not enqueued !/(#&%!"/! So you can have a faulty setup - and a program doing mio of enqueues (and no one apart from the end user discovers that somethings was very wrong). How rude !!!
I would reaaly like to see the same Oracle return code in PL/SQL and Java ..... (and other languages for that matter, but I have only tested with pl/sql and java in this case)
Ok, then I wonder whether I could implement a broadcast model having a dynamic, undefined number of consumers.
In such a case the producer doesn't know anything concerning existing consumers, which at enqueuing time might exist or not.
Say he puts a message in the queue, then if any subscriber exists - then he's notified - otherwise the message remains queued till someone will scan the queue (assuming a persistent queue is used).
Is that pattern compatible with AQ ?
could you specify your previous settings (i.e. DBMS_MGWADM.CREATE_MSGSYSTEM_LINK, DBMS_MGWADM.REGISTER_FOREIGN_QUEUE,
DBMS_MGWADM.SCHEDULE_PROPAGATION) ? These informations are necessary for finding a solution.