We are sending a message to Websphere MQ Queue. While sending the message we are setting the REPLY TO QUEUE NAME and JMSCOrrelationID. We also set the USER IDENTIFIER. The code snippet is as follows.
Message msg = session.createTextMessage((String) message);
Destination codeDestination = session.createQueue("queue://" + replyToQueueMgr + "/" + replyToQueueName);
msg.setJMSReplyTo(codeDestination);
msg.setIntProperty(JmsConstants.JMS_IBM_REPORT_COD, MQC.MQRO_COD);
msg.setJMSCorrelationID(msgCorrelId);
msg.setStringProperty(JmsConstants.JMS_IBM_MQMD_USERIDENTIFIER, "abc");
producer.send(msg);
Please note that we have ensure that all the fields which we set are not null. Also the user abc is a valid user because if not then the CODs should go to DEAD LETTER QUEUE but there are no messages in it. Still after the message is picked up we get a COD which has JMSCorrelationID as null. In COD Processor we are listening on the replyToQueuename.
String correlationID = (String)eventContext.getMessage().getInboundProperty("JMSCorrelationID");
On checking above correlation ID is null. ALso the message payload is of {null_payload} type of NullPayload class of mule. I know that body would be NULL because we set MQC.MQRO_COD. But I dont undertand how the correlationId got wiped out.
Please advise if there is any configuration at the Webview MQ end whih could cause such a behaviour? Or is there something missing in the way we are setting the header properties?
UPDATE
The queue that we are sending the message to with COD information is an alias to a TOPIC. There are 2 subscribers to this TOPIC and we observed that there were instances where we received multiple COD's when both the subscribers picked up the messages. Is there any way to ensure that the TOPIC sends a single COD after all the subscribers have picked up the message? Could this QM setup be the cause of the COD with null?
User Identifier
When a message is published, each subscriber gets a copy of the message with a unique message ID and with the identity context fields in the MQMD (UserID, AccountingToken, ApplIdentityData) all set to the subscriber's context. So it doesn't matter what you set in the MQMD UserID of the message you publish, all the copies will have the subscriber user ID in them. This user ID will, by definition, exist where he subscriber is so the CODs will be able to be put.
Correlation ID with Pub/Sub
You can ensure the correlation ID from the publisher is sent all the way through to the subscriber, by ensuring the subscription is made using MQSO_SET_CORREL_ID and setting the MQSO SubCorrelId to MQCI_NONE.
One COD for multiple messages
Since there are multiple independent messages, each with the COD Report Option set, you will get multiple report messages. There is no setting to combine these, however you could write an intermediate application to combine then if your main application wants only one.
Passing Correl ID back in a Report Message
By default the report option will send back the message ID in the Correl ID of the report message. If you want to have the Correl ID passed back, you should use MQRO_PASS_CORREL_ID.
Further Reading
Report Option
The issue is not with MQ configuration but with Mule endpoint configuration. The COD which were sent with nullpayload were actually sent by my own mule application jmsRepyToHandler. There is some default configuration in Mule which seems to be causing this behavior.
Analysis
Application sends a message to the Queue which is alias to a TOPIC with two subscribers
Once both the subscribers consume the message we get 2 COD as expected.
These COD are consumed by my MULE application and after processing the MULE application again sends COD to same queue with null correlation Id.
UPDATE: Mule Fix to avoid default ReplyTo
For the fix you need to override getReplyToHandler method of Mule JMSConnector as follows
if (disableReplyTo) {
return new DisableJmsReplyToHandler(this, getDefaultResponseTransformers(endpoint));
}else {
return super.getReplyToHandler(endpoint);
}
Set the property disableReplyTo as true so that above code provide DisableJmsReplyToHandler instead of the default one.
Related
Our system has configured to consume and send reply to the same queue, i.e., JMSDestination and JMSReplyTo are the same. I cannot change that right now.
In my integration test, if I set replyToSameDestinationAllowed=true, Camel continues to consume the reply I sent to the queue, i.e., it "captures" the source and never stop and enters a loop.
But, if I don't set it, Camel refuses to send the reply to the queue, saying this:
JMSDestination and JMSReplyTo is the same, will skip sending a reply message to itself
That causes problem for my integration test. I want to consume the message in a separate method and assert against it.
How can I stop Camel from capturing this queue, i.e., consuming only once and ignore the rest?
At the end of my route I call stop() to send reply automatically.
When receiving the second message(the reply), I see this line:
2023-01-10 14:37:22,186 DEBUG [org.apa.cam.com.jms.EndpointMessageListener]-{Camel (camel-1) thread #19 - JmsConsumer[my.queue]}-Received Message has JMSCorrelationID [ID:hostname-1673354133272-4:1:1:10:1]
Can I use this to ignore the reply? Should I stop the route? Rollback? Or what should I do?
At last I filtered out messages based on the presence of JMSCorrelationID header.
from("activemq:xxx")
.filter(simple("${header.JMSCorrelationID} == null")) // ignore reply
.to("direct:main");
Even that I don't set it in my client side code, seems that Camel will use message id to set JMSCorrelationID when sending reply if the incoming message hasn't it. If incoming message already has JMSCorrelationID, Camel will not change it, and will copy that value to the reply.(I guess that if you manually set JMSCorrelationID in client side, Camel will stop setting it for you).
So basically, message without JMSCorrelationID means it's new message which hasn't passed through my client application. I think only client side should set it, especially in my case where original message and replies are put into the same queue, where client needs a mean to filter out replies.
Also, I find that receiving can specify a message collector stating the field you want to filter. For example:
QueueReceiver receiver = jmsSession.createReceiver(myQueue, "JMSCorrelationID='" + correlationId + "'");
This is useful when you know the correlationId. But in my case (#QuarkusIntegrationTest which is a black box test), this cannot be used.
But after doing that, in my integration test Camel still "captures" the consuming and will not let another method to consume the message properly(the other method never receives anything) when I run the whole test class(with other test cases); when running individually, this test case passes. So at last I disabled the test case.
Seems that after filtering out the message, Camel behaves exactly same as if I called .stop(), executing the callback (sending reply); and will send the original message to reply queue, in my case, the original queue, so it's looping and never let go. Even I enable duplicate check, it still captures.
At the very last, we separate the queues so even capturing is happening, it does not matter any more.
I am using Apache Camel and IBM MQ to send messages. I need to receive COA when a message gets delivered to a remote queue. The general picture looks like this:
When the message reaches msg_q2 queue, I should receive the COA back. So, the problem is that I am not able to set the QMGR_REM as reply-to queue manager, which is supposed to produce COA.
https://www.ibm.com/docs/en/ibm-mq/8.0?topic=messages-reply-queue-queue-manager
I tried setting JMS_IBM_MQMD_xxx headers, but for some reason those headers either get omitted or ignored (by Camel?), and the message fails to be put on the queue with the reason that the reply-to queue is not specified. Also, I tried setting JMSReplyTo header as queue://reply-to-qmgr/reply-to-q. In this case the queue:// part gets removed, and the rest is simply set as a reply-to queue name.
I am relatively new to Apache Camel, and IBM MQ, so any input would be very appreciated. Thank you in advance!
In your application, just provide the name of your ReplyToQ as replyToQ1 and leave the ReplyToQMgr field blank. The queue manager will fill it in with the local queue manager name QMGR_LOC for you.
And on QMGR_REC do one of the following:-
If your transmission queue for the channel from QMGR_REM to QMGR_LOC is named exactly QMGR_LOC, you have nothing further to do. When QMGR_REM comes to put the COA onto queue replyToQ1 on queue manager QMGR_LOC, it will resolve it to the transmission queue that has the name QMGR_LOC and the channel will deliver it.
If your transmission queue for the channel from QMGR_REM to QMGR_LOC is not named exactly QMGR_LOC, then make the following definition on QMGR_REM:
DEFINE QREMOTE(QMGR_LOC) RNAME(' ') RQMNAME(QMGR_LOC) +
XMITQ(your-transmission-queue-going-to-QMGR_LOC)
So, basically by trial and error I figured out that adding mdWriteEnabled=true property onCamelJmsDestinationName Camel header made it working as I need.
The code is something like this:
route.setHeader("CamelJmsDestinationName", "queue:///msg_q1?targetClient=1&mdWriteEnabled=true")
Then I set reply-to queue manager via MQMD property
route.setHeader("JMS_IBM_MQMD_ReplyToQMgr", "QMGR_REM")
and reply-to queue
route.setHeader("JMSReplyTo", "replyToQ2")
I don't have a MQ Setup on my machine - I have this log from system err.
Can anyone please help me interpret this ?
The things I am looking for validation is :
(1) Should the messageId be all zeroes ?
(2) When we do an MQPUT , we use the MessageId to search
with and subsequent GET ? (validate)
(3) When we do a MQPUT , the correlationId is set as all Zeroes ?(validate)
This is an MQGET log
**MQGET**(Hconn,Hobj,MQMD,MQGMO,int,ByteBuffer,Pint,Pint,Pint) (**LocalMQ**)
[:/d1b0530f] Entry
0x146bcc9
0x6 0x163d7ed8 <null>
version:2 report:0
**msgType**:8
**expiry**:-1
feedback:0 encoding:273
codedCharSetId:0 format:''
priority:-1
persistence:2
**msgId**:000000000000000000000000000000000000000000000000
**correlId**:XXX0269A //I have truncated this
**backoutCount**:0
**replyToQ**:''
**replyToQMgr**:''
(1) It is normal practice to zero out the Message ID prior to issuing MQPUT to indicate to the queue manager that you want it to generate a unique Message ID for your message.
(2) Upon return from the MQPUT call, the MQMD will contain the generated Message ID that was created for your message. You can then use this if you need to for correlation purposes on subsequent MQGET calls.
(3) For Correlation IDs on a request message it is normal for them to be zeroed out. For replies, it is normal to copy the Message ID from the request message that this is a reply for, into the Correlation ID field.
Suppose both reply and request are being sent to the same topic, and now I'm subscribed to it. How do I identify which of them is which?
Try setting message property on the messages which you publish to the topic. You set a string property on each message, e.g. message_type=”request” or message_type=”response”. When you consume the message on the listener you can read the property to identify if the message is request or response.
Another way of doing it is by starting two listeners with message selector properties. One which will only consume messages with message_type property as “request” and another which will only consume messages with message_type property as “response”.
There is an easy way too: The request comes in first, so I can check for a smaller timestep than the response. Which will identify it as the request.
I have an webapp that is expected to fetch and display data from an External App which is accessible only via messaging (JMS).
So, if a user submits a request on a browser, the same HTTP request thread will have to interact with the Messaging system (MQ Series) such that the same request thread can display the data received from the Messaging System.
Is there a pattern I can make use of here? I saw some vague references on the net that use "Correlation ID" in this way:
Msg m = new TextMsg("findDataXYZ");
String cr_id = m.setCorrelationID(id);
sendQueue.send(m).
// now start listening to the Queue for a msg that bears that specific cr_id
Response r = receiverQueue.receive(cr_id);
Is there something better out there? The other patterns I found expect the response to be received asynchronously.. which is not an option for me, since I have to send the response back on the same HTTP request.
The request/reply messaging pattern is useful for your requirement. You typically use a CorrelationId to relate request & reply messages.
While sending request message you set JMSReplyTo destination on the message. Typically a temporary queue is used as JMSReplyTo destination. When creating a consumer to receive response use a selector with JMSCorrelationId, something like
cons = session.createConsumer(tempDestination,"JMSCorrelationId="+requestMsg.JMSMessageId);
At the other end, the application that is processing the request message must use the JMSReplyTo destination to send response. It must also use the MessageId of the request message and set it as CorrelationId of the response message.
First, open the response queue. Then pass that object to the set reply-to method on the message. That way the service responding to your request knows where to send the reply. Typically the service will copy the message ID to the correlation ID field so when you send the message, take the message ID you get back and use that to listen on the reply queue. Of course if you use a dynamic reply-to queue even that isn't neessary - just listen for the next message on the queue.
There's sample code that shows all of this. If you installed to the default location, the sample code lives at "C:\Program Files (x86)\IBM\WebSphere MQ\tools\jms\samples\simple\SimpleRequestor.java" on a Windows box or /var/mqm/toolsjms/samples/simple/SimpleRequestor.java on a *nix box.
And on the off chance you are wondering "install what, exactly?" the WMQ client install is downloadable for free as SupportPac MQC71.