I have a message queue in IBM MQ v8 and I could see Last put date for the queue which is very recent. I could not see a Last get data for the same queue. Also the current message depth of the queue is zero. So I am trying hard to find where the message which came to the queue has disappeared? What would be a possible scenario? The UNCOM attribute value is NO and MSGAGE value is 0. Please assist!
Related
Just want to confirm the correct way the MQ delivers messages to the MQOutput node. Recently came across a situation where i a felt bit confused. Here is the scenario.
I have a local queue on Qmgr,say(A) which receives messages from applications and have a local broker associated with this qmgr(A) with a message flow deployed, which consumes messsages from this queue and drops it to another local(L.B) queue on Queue manager (B).
To successfully deliver the messages to qmgr(B) do i have to
Create a remote queue definition on Qmgr(A) with transmission queue name matching the remote queue manager name, here(B)
MQOutput node value set as, queue->remote queue definition name on (A) and queue manager value as blank
or
to create only the transmission queue that matches with the name of the remote queue manager name, here(B).
MQOutput node value set as queue-> target local queue (L.B) and Queue manager value as (B).
When i follow with the first process, noticed messages reaching the destination and when i follow with the later one, noticed messages sitting up in the local queue itself.
Is there any necessity to always create 'n' number of remote queue definitions when it needs to drop messages to 'n' number of local queues?
Kindly guide me to better understand this. Thanks in advance to each of you.
There is no necessity to create n remote queue definitions, MQ is happy to accept output marked as destined for "Queue Name" on "Queue Manager Name".
You say that when using method 2. that your messages are "sitting up in the local queue". There are a few things you must check to solve this problem.
I assume the named queue L.B is defined on QMgr B and not QMgr A?
I assume the local queue the messages are sitting on is a transmission queue?
Have you defined a channel to read messages from the transmission queue they are stuck on?
Have you started the channel which should be moving the messages off the transmission queue to QMgr B?
In the following scenario, i'm curious as to what happens as it relates to what's in the active LOG files of the queue manager in question. Linear Logging is being used.
What activity (if any) is experienced by the MQ Active LOGS, during a scenario where a queue with say, 100 messages, is being READ with a JMS context attribute (looking for a specific message) -- that, for the case of this arguement, it will NEVER find. All messages are read off the queue, but none are committed. The messages therefore were never actually deleted from the queue; does the queue manager, however, record such GET operations so as to recover these "in flight" conditions, should the queue manager Crash while this is happening? We recently experienced a situation where the dequeue rate from a specific queue was in the 4000-4500 msg / min range, while the queue depth was only about 2500. We surmise that more than 1 such process thread were trying to read off a JMS message by context (sort of like with correlation ID I suppose), but without any hope of ever actually finding a message it was looking for (due to a probable misconfiguration). During this time, the active LOGS filled up rapidly. Is it likely that such wanton dequeue rates as we saw were the culprit?
MQ writes log records for persistent messages during get and put. More details can be found here:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q023070_.htm
In MQ explorer, If I open up the properties for a particular queue (X), what property will tell me if the queue is defined as an error handling queue for another queue (Y)? i.e. If Y fails to process the message and the transaction rolls back, it will put the message on X.
Any queue designated as an error or exception queue (backout queue in WebSphere MQ terminology) is an ordinary queue. The BOQNAME on a primary queue points to the backout queue but there is no attribute of the backout queue that points back to the primary queue. This might be a one-to-many relationship because any number of primary queues might point to a single backout queue.
One way to do this in WMQ Explorer would be to make sure that BOQNAME is visible in the display and then sort the queue list on that column. Then look for all instances with your backout queue name in them.
In WAS, I have created a jms queue X. I have also created another queue Y and in MQ, I specify that Y is backout queue for X.
Now for X if I say maximum number of retries :3 and backout threshold is 2, that means that after 2 tries if the message is not consumed by X, queue manager will put message on Y. In this case, maximum number of retries (3) will never be reached because it will never try a third time. And the listener for X will never go down.
Is my understanding correct?
I'm not so sure about the jms interface, but in native WMQ, the queue manager does not automatically requeue the message to the backout queue. it is up to the application to query the backout_count, compare that to the backout_threshold, and put the messages to backout_queue.
You should read "How WebSphere Application Server handles poison messages" -- http://www.ibm.com/developerworks/websphere/library/techarticles/0405_titheridge/0405_titheridge.html
Also important to read "Best Practices: WebSphere MQ shared queues and application programs", scroll down to Issue 6 -- http://www.ibm.com/developerworks/websphere/library/techarticles/0512_elkins/0512_elkins.html
MQ JMS implementation does the job of moving a message to backout queue once the backout threshold set on the target queue is reached. If a backout queue is not specified, MQ JMS attempts to put the message onto the dead letter queue.
There is no retry concept in MQ JMS as far as I know. It might be something related to WAS/MDB.
it is weird that if it is application's decision to requeue the msg to backout queue, why the backout threshold is defined in queue's property ? should't this threshold property be defined in application.
Very confusing.
JMS Question:- Is there any way to change the messages order in JMSQUEUE based on custom rule/policy/strategy? Other then FIFO..
You can try setting JMSPriority property on the messages sent to the queue. JMSPriority can have value from 0 to 9, with 9 been the highest. If multiple messages are present in the queue then the message with the highest priority will be consumed first.
This link could be helpful for you,
http://www.techpaste.com/2012/04/prioritize-messages-enqueued-jms-queue/