IBM XMS .NET - Receiving Error - Reason Code 2003

Question

We have .NET application which reads from various queues using the XMS API. For this particular application we read from 3 queues and every so often receive the error with reason code 2003 on 2 of the 3 queues. All 3 of the queues are setup to have persistent messages.

From everything I have researched, it appears that a long running transaction being rolled back causing this error. The reason for the long running transaction being rolled back appears to be from exhausted log space. When the transaction gets rolled back, it puts the messages we have previously read onto the queue so we end up reading duplicates.

In the API, when we create our "Session" to read from the queues, we specify false for the transacted parameter. Therefore we never call "Commit" on the session. We also use the auto-acknowledge mode on the session. This leads me to believe that we don't have any sort of unit of work sepcified explicitly, but could there be an implicit transaction of some sort? The tricky part is that we are able to read fine on 1 of the 3 queues without ever receiving the error.

Any ideas on where I could look next to troubleshoot such an issue?

Creating the connection:

cf.SetStringProperty(XMSC.WMQ_HOST_NAME, hostName);
cf.SetIntProperty(XMSC.WMQ_PORT, port);
cf.SetStringProperty(XMSC.WMQ_CHANNEL, channelName);
cf.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT_UNMANAGED);
cf.SetStringProperty(XMSC.WMQ_QUEUE_MANAGER, managerName);
cf.SetStringProperty(XMSC.WMQ_SSL_KEY_REPOSITORY, EncryptionSettings.SSLRepositoryPath);
cf.SetStringProperty(XMSC.WMQ_SSL_CIPHER_SPEC, EncryptionSettings.CipherType);
cf.SetIntProperty(XMSC.WMQ_FAIL_IF_QUIESCE, XMSC.WMQ_FIQ_YES); 

Creating the session:

MQConnection.CreateSession(false, AcknowledgeMode.AutoAcknowledge)

Creating the destination:

MQSession.CreateQueue(queueName)

Creating the consumer:

 MQSession.CreateConsumer(MQDestination)

Reading from the queue:

var rawMessage = messageConsumer.Receive((long)TimeSpan.FromSeconds(15).TotalMilliseconds);

Answer 1

It turns out that there was an internal unit of work that was not being committed which would cause the messages to be rolled back on the queues upon a 2003 or 2024 failure. The solution to the problem was to set the flag on the MQ connection factory for WMQ_SYNCPOINT_ALL_GET to true. The default is false.

Setting the flag:

SetBooleanProperty(XMSC.WMQ_SYNCPOINT_ALL_GETS, true);

Answer 2

XMS .NET reads persistent messages under a local a transaction as the Session is created as non-transacted and auto acknowledge. This is to avoid any message loss during delivery of a messages to an application. Hence XMS .NET internally calls a Commit to tell the queue manager to remove a message from a queue.

Your code is very simple, I don't see a problem.

Are there any malformed messages in any of the queues? Messages having headers that XMS does not understand, would be backed out to backout(BOQUEUE) queue after the backout threshold (BOTHRESH) is reached.

Have you defined a backout queue or dead letter queue for the queues from which your reading messages? Are messages piling up in backout queue?

Finally I would suggest to raise a PMR with IBM to resolve the issue.