I'm developing a solution to retrieve poison messages from a backout queue in Websphere 6.1.
My question is: when this msg (ie. TextMessage) is re-queue from a regular queue to backout queue, what is the queue name in msg.getJMSDestination() and msg.getJMSReplyTo()?
For example:
I've got a msg with destination to myQueue. However, for some reason, this msg could not be processed (poison message) and, because websphere is configured for that, this msg is re-queued to backout queue named myBOQueue. If I retrieve this msg from myBOQueue (using MDB), and I execute ((Queue) msg.getJMSDestination()).getQueueName(), what do i go: myQueue or myBOQueue? And if I execute ((Queue) msg.getJMSReplyTo()).getQueueName(), what do I got?
Message document: http://download.oracle.com/javaee/1.4/api/javax/jms/Message.html
Thx,
Andre
You want to look in vendor-specific docs. I think retry counts and poison message queues are a vendor-specific feature not included in the JMS spec.
Related
I have a question about MSMQ. If I use a non-transactional queue and send message to it with recoverable parameter, message is stored on disc and in case of some problem secure. But if I want pull message from non-transactional queue, is there some mechanism to secure messages to stay in queue in case of some problem (server error, db off...)?
For some reasons I don't want to use transactional queue. Thanks a lot for response.
You could implement a peek-then-receive process to simulate a transaction.
Peek message to get content.
Use the content as you wish.
If step 2 completes then Receive message to effectively delete it.
If step 2 fails, execute cleanup code and goto step 1.
I'm pretty new to this queue service and I don't know what really means poisoned message.
I read that is a message you cant consume, but It means you can Peek() and see the details but not Receive() or what?
From my point of view, I would say a poisoned message is a message on top of the queue that because of its format or even corrupted format is not consumible because the business in charge of handle it can't do it and it maybe generates a exception that in a transactional scenario is catched and handled with a rollback, so the message stays on top forever.
What do you think? Am I totally wrong?
I've had to deal with poison MSMQ messages before, ugh! I'd say your definition is close.
A poison message is basically a message that is repeatedly read from a queue when the service reading the message cannot process the message because of an exception or some other issue and terminates the transaction under which the message is read. In such cases, the message remains in the queue is retried again upon next read from the queue. This can theoretically go on forever if there is a problem with the message.
For example, the message contained data that would violate a database constraint. I sometimes would create an error queue and have the service processing the messages throw the "poison" message into that if an exception occurred during processing. This would at least remove the message from the queue and give me an opportunity to view it later without effecting the main production queues.
Here is some advice and information on poison message handling.
Our Transactional Dead-letter queue is filling up in MSMQ. I can't find documentation on particular.net that points to why this could be happening.
It looks like every single message that is being processed (successfully) is ending up at the that queue.
What is the reason items are sent to the Transactional Dead Letter queue?
If you open dead letter queue in Computer Management, each message has a reason why it ended up there. It's under "class" column. That should point you where to look. For example one of reasons could be "The time-to-be-received has elapsed.", if message wasn't received within time specified in its "TimeToBeReceived" property.
I have Distributor/Worker model.
Machine A - Distributor
Machine B - Worker
When the worker B is trying the send message to Distributor on a wrong Q name, its putting the message into Transactional Dead Letter Q.
I was expecting the message to delivered to error q.
This is the correct behavior.
NServiceBus uses the error queue when the processing of an incoming message fails.
This is not the same as trying to send a message to a queue which does not exist.
There maybe an exception to this is if the message send is performed from inside a handler, though I have not tested this scenario.
I am using the HornetQ for jms in Jboss 5.1.0 environment. I have various queues, each has its re-delivery count and delays configured in the hornetq-configuration.xml. If the messages cannot be processed in the given retry count then they are moved into a common queue "/jms/deadqueue". An mdb of this deadqueue will process all the messages. Before moving into a deadqueue I wish to add an additional property into that message(I use ObjectMessage). Is that possible?
and also, Is it possible to get current attempted count inside the mdb onmessage method, that is, if the message is redelivered 2nd time I should get 2?
regards
V
Check out the new book on HornetQ
http://www.amazon.com/dp/1849518408/?tag=packtpubli-20