We Keep Coding

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.

IMB PCF agent returns error while inquiring channel status

I have a problem with PCF message agent while inquiring channel in order to obtain informations about hosts connected to a given queue manager. The code of PCFAgent is
MQGetMessageOptions getMessageOptions = new MQGetMessageOptions();
getMessageOptions.options = MQC.MQGMO_BROWSE_NEXT + MQC.MQGMO_NO_WAIT + MQC.MQGMO_FAIL_IF_QUIESCING;
messageAgent = new PCFMessageAgent(MQEnvironment.hostname, MQEnvironment.port, MQEnvironment.channel);
and code of options is
inquireOptions = new PCFMessage(CMQCFC.MQCMD_INQUIRE_CHANNEL_STATUS);
inquireOptions.addParameter(CMQCFC.MQCACH_CHANNEL_NAME, "*");
inquireOptions.addParameter(CMQCFC.MQIACH_CHANNEL_INSTANCE_TYPE, CMQC.MQOT_CURRENT_CHANNEL);
inquireOptions.addParameter(CMQCFC.MQIACH_CHANNEL_INSTANCE_ATTRS, new int[]{
CMQCFC.MQCACH_CHANNEL_NAME, CMQCFC.MQCACH_CONNECTION_NAME, CMQCFC.MQIACH_MSGS,
CMQCFC.MQCACH_LAST_MSG_DATE, CMQCFC.MQCACH_LAST_MSG_TIME, CMQCFC.MQIACH_CHANNEL_STATUS
});
responses = messageAgent.send(inquireOptions);
Not always, but occasionally the application resturns an exception that says "Completion Code 2, Reason 2100" and my host (the one on which the application is running) leaves a pending connection on the server that is never closed until the MQManager is restarted.
I've read that this exception is due to a conflict in creating dynamic queues, but in my code I don't create any queue.
Someone could help me? Sorry, I've no previous experiences with queue managers.
Thank you

2100 (MQRC_OBJECT_ALREADY EXISTS) is indeed a problem with creating a dynamic queue.
Explanation
An MQOPEN call was issued to create a dynamic queue, but a queue with the same name as the dynamic queue already exists.
Completion code
MQCC_FAILED
Programmer response
If supplying a dynamic queue name in full, ensure that it obeys the naming conventions for dynamic queues; if it does, either supply a different name, or delete the existing queue if it is no longer required. Alternatively, allow the queue manager to generate the name.
If the queue manager is generating the name (either in part or in full), reissue the MQOPEN call.
Under the covers, the PCFMessageAgent will create a PCF Format message using the details you supply in the PCFMessage and will open a model queue to create a temporary queue in order to receive the reply from the Command Server. These temporary queues are named by the queue manager by producing a unique portion using a timestamp, resulting in a name something like AMQ.5E47207E2227AA02. If you have lots of concurrent applications doing this, it is possible that you could end up with a clash of names, and the second request in, at the same time might get a name conflict.
If you have a way to make the temporary queue name more unique should such concurrency be a problem in your system, you can set the prefix used for the temporary queue name using the setReplyQueuePrefix method. You could, for example, user the user ID each application is running under, if that is unique.
public void setReplyQueuePrefix(java.lang.String prefixP)
Sets the string used as the first part of the agent's reply queue name. The reply queue used by the PCFAgent is a temporary dynamic queue. By default, the reply queue prefix used by the PCFAgent is the empty string (""). When this is used, the name of the reply queue is generated entirely by the queue manager. If the method is called with a prefix specified, then the PCFAgent will pass that prefix to the queue manager whenever it needs to create a temporary queue. The queue manager will then generate the rest of the temporary queue name. This means that the queue manager generates a unique name, but the PCFAgent still has some control. The prefix specified should be fewer than 33 characters. If the prefix contains 33 characters or greater, then this method will truncate the prefix to be 32 characters in length. If the prefix does not contain an asterisk (*) character at the end, then an asterisk will be added to the end.

Ensure Ordering of Few Messages in given Set of messages

Suppose i have 51 msgs produced by MobileApp .
I want that 51th msg should hit the Application server after all 50 are processed . but i don't need ordering for other 50 msgs.
They can hit in any order(Should be parallel) .
Currently i am using Kafka as message broker .
Major Restriction :- I cannot put any callback mechanism on mobile App to give 51th message only after i received 50th message .
Any ideas around this or links/pointers ??

If you can send (synchronously with commits) the 51 messages in order and use the partitioner to send all messages in a sequence to the same partition (perhaps by making the userid the message's key), you will be assured of reading those messages in order.

COD received has correlationID and body as null

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.

ActiveMQ getClientId and removeinfo objectid don't match

i have an ActiveMQ java client that needs to detect other client connect/disconnect events.
by subscribing to connection advisory topic that is provided by AdvisorySupport.getConnectionAdvisoryTopic(), i've noticed that i get different client/connection/removeinfo ids.
for example, calling .getClientId() directly on the connection object returns an id like this:
ID:computername-60117-1388179017343-0:1
receiving the connection id via advisorySupport topic subscription, i see an id that is almost the same, like this:
ID:computername-60117-1388179017343-1:1
(note second to last number is one greater)
finally, looking at the id returned by a disconnection event, via removeInfo.getObjectId, i also get an id like this:
ID:computername-60117-1388179017343-1:1
so my question is: why are the ids in the messages received via advisorySupport topic subscriptions always one greater than the id returned by connection.getClientId()?