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.
Related
I have to configure a backout queue for the MQ input node in my application.I created one local queue as a backout queue, but don't know how to assign it.Also, how to check the backout threshold and direct the message to backout queue if the count exceeds.
Using RUNMQSC run the following
ALTER QL(<Q1>) BOQNAME(<BACKQ>) BOTHRESH(<number>)
For example the following sets backout queue BACKQ with a threshold of 5.
ALTER QL(MAINQ) BOQNAME(BACKQ) BOTHRESH(5)
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?
We are using IBM WebSphere MQ as JMS provider with Spring MDP (Message Driven POJO).
Is there any way in JMS where we can configure time related properties in message so that message can be consumed at particular defined time only?
For example, if I am sending three messages into queue M1, M2 and M3. Where, I can configure M2 message property let say 3 AM. And consumer side, consumer can only pick this message # 3 AM only. If time is not defined, messages should be consumed in a way that JMS Receiver does.
JMS 2.0 specification has defines Delivery Delay. With this feature a message producer can specify that a message must not be delivered until after a specified time interval. The message will be available for delivery after the specified time. But this may not help you as you want to a message to be consumed at a specified time. Typically messaging applications are designed to consume messages as soon as they are made available by the messaging provider.
If you want to process messages at a specified time only, you could create another queue "queue_3am", and schedule a reader to run exactly at 3am.
A variation is to set the timestamp as a message property. So one queue could contain messages to be processed at different points in time. The reader could use message selectors to get relevant messages only.
But you should use a "message pickup timeframe" by adding two timestamps as message properties, for eaxmple set the window to 1 or 5 minutes.
The receiver can use a message selector: A selector is a condition using message properties.
Have a look at this
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.
I have a MDB which listens to WebSphere MQ. It does not picks up the messages in the order that has been received by the Queue. How can i make it read it in that order? Is it possible? Should i not use a MDB.
In general, WMQ delivers messages in the order that they were received. However, several things can impact that...
If the queue is set to priority instead of FIFO delivery and messages arrive in different priorities, they will be delivered "out of order".
Distinguish between order produced and order delivered. If the messages are produced on a remote QMgr and there are multiple paths to the local QMgr, messages may arrive out of order.
Difference in persistence - if messages are produced on a remote QMgr and are of different persistences, the non-persistent messages may arrive faster than the persistent ones, especially with channel NPMSPEED(FAST) set.
Multiple readers/writers - Any dependency on sequence implies a single producer sending to a single consumer over a single path. Any redundancy in producers, consumers or paths between them can result in messages delivered out of sequence.
Syncpoint - To preserve sequence, ALL messages must be written and consumed under syncpoint or else ALL must be written and consumed outside of syncpoint.
Selectors - These specifically are intended to deliver messages out of order with respect to the context of all messages in the queue.
Message groups - Retrieval of grouped messages typically waits until the entire group is present. If groups are interleaved, messages are delivered out of sequence.
DLQ - if the target queue fills, messages may be delivered to the DLQ. As the target queue is drained, messages start going back there. With a queue near capacity, messages can alternate between the target queue and DLQ.
So when an MDB is receiving messages out of order any of these things, or even several of them in combination, may be at cause. Either eliminate the dependency on message sequence (best choice) or else go back over the design and reconcile all the factors that may lead to out-of-sequence processing.
To add to T.Rob's list, MDBs use the application server WorkManager to schedule message delivery, so message order is also dependent on the order in which the WorkManager starts Work items. This is outside the control of WMQ. If you limit the MDB ServerSessionPool depth to one, then this limit is removed as there will only ever be one in-flight Work instance, but at the cost of reducing maximum throughput.
If you're running in WebSphere application server, then non-ASF mode with ListenerPorts can preserve message order subject to some transactional/backout caveats. There's a support technote here:
http://www-01.ibm.com/support/docview.wss?uid=swg21446463