JMS adapter does not recover from error

[Former Member]

Hello everyone,

We are noticing some strange behavior with the JMS adapter, and would like your help. We have messages coming into XI from WebSphere MQ. We have configured a Sender Comm channel (MQ_SENDER) with the appropriate JMS adapter, with a specified queue name (TEST.Q) . We have installed the appropriate MQ-JMS libraries for v6.0.

Here's the problem scenario... initially the application sending the messages to the specified queue was putting an incorrectly formatted MQRFH2 structure in the message. Predictably, this caused our comm channel to fail, and it shows up on the adapter monitor in the failed state with the message "MQJMS1050: The MQRFH2 header has an incorrect format Code: MQJMS1050". This in itself is not a problem, we realized that the application was sending a malformed message. The problem occurs when we fixed the sending application to completely strip out the MQRFH2 header altogether. When the new message is sent, the comm channel seems "stuck" on the previous error, and does not even pick up the new message from the queue. The adapter monitor continues to show the same error for the comm channel. Now when we modified the comm channel to read from a DIFFERENT queue (TEST2.Q) , the comm channel got out of the error state and is able to successfully process new messages coming into that queue. However, when we revert the comm channel back to the original queue (TEST.Q) it reverts back to the original MQJMS1050 error, and does not pick up new messages on the queue.

Any assistance would be greatly appreciated...

[agasthuri_doss · Accepted solution]

Hi,

1) Try to refresh the metadata

2) Check the Queue status

3) Once again check the Queue name. try to make the Sender JMS adapter inactive .save it..again make it active and save it and activate the object.

4) Refresh the Cache :

a)Start transaction SXI_CACHE.

b)From the context menu XI Runtime Cache select Start Complete Cache Refresh.

If you still face issue try this .

Many actions require to access System Landscape Directory content from the Integration Builder. To optimize performance, this content is loaded into a cache so that the System Landscape Directory does not have to be accessed directly each time that System Landscape Directory content is required.

However, this cache is not automatically updated if changes are made to the content of the System Landscape Directory. For this reason that we delete the System Landscape Directory cache if changes have been made to content in the System Landscape Directory. The cache is then filled each time that the System Landscape Directory is accessed. If we log on to the Integration Builder after we have made a change in the SLD, we do not need to delete the SLD cache.

To clear the SLD cache, from the Integration Builder main menu, choose Environment ® Delete Cache for SLD Data.

Once we have deleted the cache for SLD data, accessing objects in the SLD may take longer than usual initially.

Regards

Agasthuri Doss

[Former Member · Accepted solution]

Thanks for the ideas, tried all of the suggested steps and still facing the same issue.

[agasthuri_doss · Accepted solution]

Hi,

Can you check the following :

message protocol- JMS 1.x

QueueConnection Factory java class

Queue Java Class

Set Xi message Id to - GUID

Set Xi converation to = no value

Quality of service-Exactly Once

time period for duplicate check for EO ( use some time period )

Mean time check with your Executing adapter wherer all the configuration resembles the same.

Regards

Agasthuri Doss

[Former Member]

We experienced the same issue, tried refreshing caches and so on.

Finally we got rid of the error by restarting the adapter engine.