We Keep Coding

When source and replyTo is the same, stop Camel from consuming after route stopped

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.

How to handle incoming 'messageMediaPoll ' messages?

Hi I am writing a telegram client using https://github.com/rubenlagus/TelegramApi that listen to incoming messages but I noticed some relevant messages carried in 'Polls' could not be read.
After a few debugging, it appears when such message is received, the incoming 'MessageMedia' part of the TLMessage being deserialized is mapped to messageMediaUnsupported#9f84f49e
According to documentation it means it is 'not supported by current client version'.
Indeed, I could see no implementation for messageMediaPoll message media in org.telegram.api.message.media package, and I could add it. But, how to have the server consider my client as valid for receiving such media?

Processing messages with PossDupFlag set with QuickFixJ

In QuickFix/J we can send a ResendRequest message to the Acceptor to request messages to be resent to the Initiator, within a given MsgSeq number range. For example:
Session session = Session.lookupSession(new SessionID("FIXT.1.1:SENDER->TARGET"));
session.send(new ResendRequest(new BeginSeqNo(1), new EndSeqNo(0)));
This message will request all existing Execution Reports for any open orders in the Acceptor.
The issue we have is that these messages come with PossDupFlag set to Y in the header. QuickFix/J by default ignores these messages and doesn't call the fromApp callback. I found that the callback is called if we set
ValidateSequenceNumbers=Y
but, as per the documentation, it has a drawback
If not enabled and a mismatch is detected, nothing is done.
I was wondering:
is there a different way for these messages to be processed by the callback?
if there is no other way what are the consequences of setting ValidateSequenceNumbers=Y? Is it just detect the sequence number mismatch ourselves?
Thanks

After some digging around I found a solution for this problem. Basically, we need to tell QuickFix/J that our target MsgSeqNum is 1. The logic will detect that the actual target's MsgSeqNum is higher than the one we have set and it will send a ResendRequest to the Acceptor:
Session session = Session.lookupSession(new SessionID("FIXT.1.1:SENDER->TARGET"));
session.setNextTargetMsgSeqNum(1);
In this case, the fromApp callback is called even though the PosDupFlag is set in the messages.

Parse byteBuffer in Websphere MQ Exit

I'm trying to build a custom mq exit to archive messages that hit a queue. I have the following code.
class MyMqExits implements WMQSendExit, WMQReceiveExit{
#Override
public ByteBuffer channelReceiveExit(MQCXP arg0, MQCD arg1, ByteBuffer arg2) {
// TODO Auto-generated method stub
if ( arg2){
def _bytes = arg2.array()
def results = new String(_bytes)
println results;
}
return arg2;
}
...
The content of the message (header/body) is in the byte buffer, along with some unreadable binary information. How can I parse the message (including the body and the queue name) from arg2? We've gone through IBM's documentation, but haven't found an object or anything that makes this easy.

Assuming the following two points:
1) Your sender application has not hard coded the queue name where it puts messages. So you can change the application configuration to send messages to a different object.
2) MessageId of the archived message is not important, only message body is important.
Then one alternative I can think of is to create an Alias queue that resolves to a Topic and use two subscribers to receive messages.
1) Subscriber 1: An administratively defined durable subscriber with a queue provided to receive messages. Provide the same queue name from which your existing consumer application is receiving messages.
2) Subscriber 2: Another administratively defined durable subscriber with queue provided. You can write a simple java application to get messages from this queue and archive.
3) Both subscribers subscribe to the same topic.
Here are steps:
// Create a topic
define topic(ANY.TOPIC) TOPICSTR('/ANY_TOPIC')
// Create an alias queue that points to above created topic
define qalias(QA.APP) target(ANY.TOPIC) targtype(TOPIC)
// Create a queue for your application that does business logic. If one is available already then no need to create.
define ql(Q.BUSLOGIC)
// Create a durable subscription with destination queue as created in previous step.
define sub(SB.BUSLOGIC) topicstr('/ANY_TOPIC') dest(Q.BUSLOGIC)
// Create a queue for application that archives messages.
define ql(Q.ARCHIVE)
// Create another subscription with destination queue as created in previous step.
define sub(SB.ARCHIVE) topicstr('/ANY_TOPIC') dest(Q.ARCHIVE)
Write a simple MQ Java/JMS application to get messages from Q.ARCHIVE and archive messages.

A receive exit is not going to give you the whole message. Send and receive exits operate on the transmission buffers sent/received by channels. These will contain various protocol flows which are not documented because the protocol is not public, and part of those protocol flows will be chunks of the messages broken down to fit into 32Kb chunks.
You don't give enough information in your question for me to know what type of channel you are using, but I'm guessing it's on the client side since you are writing it in Java and that is the only environment where that is applicable.
Writing the exit at the client side, you'll need to be careful you deal with the cases where the message is not successfully put to the target queue, and you'll need to manage syncpoints etc.
If you were using QMgr-QMgr channels, you should use a message exit to capture the MQXR_MSG invocations where the whole message is given to you. If you put any further messages in a channel message exit, the messages you put are included in the channel's Syncpoint and so committed if the original messages were committed.
Since you are using client-QMgr channels, you could look at an API Exit on the QMgr end (currently client side API Exits are only supported for C clients) and catch all the MQPUT calls. This exit would also give you the MQPUT return codes so you could code your exit to look out for, and deal with failed puts.
Of course, writing an exit is a complicated task, so it may be worth finding out if there are any pre-written tools that could do this for you instead of starting from scratch.

I fully agree with Morag & Shashi, wrong approach. There is an open source project called Message Multiplexer (MMX) that will get a message from a queue and output it to one or more queues. Context information is maintained across the message put(s). For more info on MMX go to: http://www.capitalware.com/mmx_overview.html
If you cannot change the source or target queues to insert MMX into the mix then an API Exit may do the trick. Here is a blog posting about message replication via an API Exit: http://www.capitalware.com/rl_blog/?p=3304

This is quite an old question but it's worth replying with an update that's relevant to MQ 9.2.3 or later. There is a new feature called Streaming Queues (see https://www.ibm.com/docs/en/ibm-mq/9.2?topic=scenarios-streaming-queues) and one of the use-cases it is designed to support is putting a copy of every message sent to a given queue, to an alternative queue. Another application can then consume the duplicate messages and archive them separately to the application that is processing the original messages.

How to make a JMS Synchronous 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.