I have a WTX map which puts a message on WMQ "Q1". There is some other application which reads the message from "Q1" and then processes the message and places the response on the queue specified in "ReplyToQ" available on MQ Header information.
I am not able to find a command parameter to add the ReplyToQ in the message WTX map is placing on "Q1".
Any thoughts?
Thanks for taking the time to look at this question and helping out!
The ReplyToQueue is sent on the message header, so you must get the message with the header (-HDR) and parse it from there on your input card.
Here's the doc about the adapter's command:
http://pic.dhe.ibm.com/infocenter/wtxdoc/v8r4m1/index.jsp
You should have a type tree on the Examples to read the message with a header.
Regards,
Bruno.
Related
We have a PHP app that forwards messages from RabbitMQ to connected devices down a WebSocket connection (PHP AMQP pecl extension v1.7.1 & RabbitMQ 3.6.6).
Messages are consumed from an array of queues (1 per websocket connection), and are acknowledged by the consumer when we receive confirmation over the websocket that the message has been received (so we can requeue messages that are not delivered in an acceptable timeframe). This is done in a non-blocking fashion.
99% of the time, this works perfectly, but very occasionally we receive an error "RabbitMQ PRECONDITION_FAILED - unknown delivery tag ". This closes the channel. In my understanding, this exception is a result of one of the following conditions:
The message has already been acked or rejected.
An ack is attempted over a channel the message was not delivered on.
An ack is attempted after the message timeout (ttl) has expired.
We have implemented protections for each of the above cases but yet the problem continues.
I realise there are number of implementation details that could impact this, but at a conceptual level, are there any other failure cases that we have not considered and should be handling? or is there a better way of achieving the functionality described above?
"PRECONDITION_FAILED - unknown delivery tag" usually happens because of double ack-ing, ack-ing on wrong channels or ack-ing messages that should not be ack-ed.
So in same case you are tying to execute basic.ack two times or basic.ack using another channel
(Solution below)
Quoting Jan Grzegorowski from his blog:
If you are struggling with the 406 error message which is included in
title of this post you may be interested in reading the whole story.
Problem
I was using amqplib for conneting NodeJS based messages processor with
RabbitMQ broker. Everything seems to be working fine, but from time to
time 406 (PRECONDINTION-FAILED) message shows up in the log:
"Error: Channel closed by server: 406 (PRECONDITION-FAILED) with message "PRECONDITION_FAILED - unknown delivery tag 1"
Solution <--
Keeping things simple:
You have to ACK messages in same order as they arrive to your system
You can't ACK messages on a different channel than that they arrive on If you break any of these rules you will face 406
(PRECONDITION-FAILED) error message.
Original answer
It can happen if you set no-ack option of a Consumer to true that means you souldn't call ack function manually:
https://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.consume.no-ack
The solution: set no-ack flag to false.
If you aknowledge twice the same message you can have this error.
A variation of what they said above about acking it twice:
there is an "obscure" situation where you are acking a message more than once, which is when you ack a message with multiple parameter set to true, which means all previous messages to the one you are trying to ack, will be acked too.
And so if you try to ack one of the messages that were "auto acked" by setting multiple to true then you would be trying to "ack" it multiple times and so the error, confusing but hope you understand it after a few reads.
Make sure you have the correct application.properties:
If you use the RabbitTemplate without any channel configuration, use "simple":
spring.rabbitmq.listener.simple.acknowledge-mode=manual
In this case, if you use "direct" instead of "simple", you will get the same error message. Another one looks like this:
spring.rabbitmq.listener.direct.acknowledge-mode=manual
We have a compute node that copies OutputRoot from InputRoot having MQRFH2 header and then sets MQMD format as 'MQSTR ' before sending it to an MQOutput node.
On my local system(MQ and WMB 7.0) when I try to test the flow and browse output queue from RFHUTILC the message still have MQMD format as MQHRF2 with proper MQRFH2 header details.
While this same flow when tested in other test regions is giving an output message with blank MQMD format and RFH2 details comes in message payload.
What can be the reason of this difference?
The input message will have the RFH2 header at InputRoot.MQRFH2, or at InputRoot.MQRFH2C if you use the compact parser for RFH2, which will be copied to the OutputRoot, and Broker sets the MQMD Format to MQHRF2 when it sees that header in the OutputRoot.
To delete the RFH2 header you should do something like this:
SET OutputRoot.MQMD.Format = OutputRoot.MQRFH2.Format;
SET OutputRoot.MQRFH2 = NULL;
I can't think of an explanation for the different behavior you see, and I don't have a V7 Broker to test. By the way you shouldn't have one either as it is out of support.
We are using spring integration and daily in our logs we can see below stacktrace. Other JMS adapters are working fine, we think only below one is missing something:
Spring integration configuration:
<jms:message-driven-channel-adapter concurrent-consumers="1" id="jmsInLOAN" destination="queueLOAN" channel="LOANCommonDataChannel" acknowledge="transacted" />
Please find below MQ statistics of Put and Msgs read count, there should be exact count of Message read by adapter. I am worried about spring integration's message-driven-channel-adapter of reading extra messages from queue. Any help would be appreciated.
WARN 07/Jan/2016 09:04:15,438 [org.springframework.jms.listener.DefaultMessageListenerContainer#23-1] springframework.jms.listener.DefaultMessageListenerContainer - [SYSTEM_ID=HBUSLOANIQ] [MESSAGE_ID=null] Execution of JMS message listener failed, and no ErrorHandler has been set.
org.springframework.integration.MessagingException: unsupported payload type [com.ibm.jms.JMSMessage]
at org.springframework.integration.xml.DefaultXmlPayloadConverter.convertToDocument(DefaultXmlPayloadConverter.java:76)
at org.springframework.integration.xml.DefaultXmlPayloadConverter.convertToNode(DefaultXmlPayloadConverter.java:88)
at org.springframework.integration.xml.router.XPathRouter.getChannelIdentifiers(XPathRouter.java:119)
at org.springframework.integration.router.AbstractMessageRouter.determineTargetChannels(AbstractMessageRouter.java:247)
at org.springframework.integration.router.AbstractMessageRouter.handleMessageInternal(AbstractMessageRouter.java:211)
It looks like you are passing the unconverted JMS message (com.ibm.jms.JMSMessage) to the XML Payload converter...
org.springframework.integration.MessagingException: unsupported payload type [com.ibm.jms.JMSMessage]
at org.springframework.integration.xml.DefaultXmlPayloadConverter.convertToDocument(DefaultXmlPayloadConverter.java:76)
Perhaps you have set extract-payload to false ?
Although it's not in the configuration you show.
Turning on DEBUG logging will show the payload type of messages passing through the system.
The issue was because of valid and poisonous(which has a payload type [com.ibm.jms.JMSMessage]) messages we were getting onto queue. Valid messages processed well, but poisounous messages not able to digest by application and send to the BackoutQueue.
In our case, BOQ threshold is 3 that means 3 times my application will try to consume a perticular message and if the message backout 3 times then it will be moved to BOQ queue and (msgs read - msgs put)/3 on LOAIQ == the msgs put on to BOQ queue at that sampling interval. From msgs put on BOQ queue, we can see how many messages are backout from LOAIQ queue. That is why the message read count is more than that of msg received.
£ and ê in a XML message is parsed successfully in broker but when one of the Queue manager tries to put the output message in another Queue manager, It throws 'Unconvertable character' exception and message goes to dead letter queue.
Channel conversion is turned on and CCSID in both the queue managers is set to '819'.
What shall be done to avoid this?
Need Help on this..!!
Update Nov 15
There is more thing that we can check If we are facing this issue.
I was posting the message from RFHUTIL, and in MQMD tab, value in code page field was set to 457. So this was one of the reasons in faillure.
I posted the same message again with code page value as 819 and then the same XML message worked fine.
So, if you are facing the same issue, you might wanna check the RFHUTIL settings as well.
The mentioned characters doesn't come under CCSID 819.
And as the channel conversion is ON, queue manager will try your message to convert the message into it's own CCSID(819), which will fail to do so as the characters are not supported.
Solutions could be:
1) Turn off channel conversion.
2) Change the CCSID of your queue managers to 1208.
Huge topic data conversion, and it depends on the language you use. A general summary is make sure the codedcharsetid for the message in the MD matches the characters codepoints in the message. Then, make sure when you get the message you get/convert and make sure you are either running in a locale which can display those characters OR put a ccsid in the MD prior to the get. If you use .net or Java then there are implications although the same remains true.
What is the address I should use to binding to a queue to a header exchange using Qpid? I want the queue to only receive messages that have a specific header and value?
drain -f "qName ; { create:receiver , node: { durable:False, x-declare: {auto-delete:'false', type:headers}, x-bindings:[{arguments:{x-match:any, 'header1':'value1'},key:qName, queue:qName, exchange:'amqmatch'}]}}"
If your address doesn’t look like this, it will not work. I got an error saying that x-match needed to be included even when I included it.
AMQP Broker: Qpid 0.12