IBM JMSExceptions CWSIT0006E and CWSIA0241E on bus connect - United States  TECHNOTE (TROUBLESHOOTING)

PROBLEM(ABSTRACT)
 Your application throws JMS exceptions CWSIT0006E and CWSIA0241E when trying to connect to a WebSphere Application Server (WAS) Service Integration Bus (SIBus). 

SYMPTOM
Application throws the following JMS exceptions in the stack trace while trying to connect to the SIBus: 

JMSException caught
javax.jms.JMSException: CWSIA0241E: An exception was received during the call to the method
JmsManagedConnectionFactoryImpl.createConnection:
com.ibm.websphere.sib.exception.SIResourceException: CWSIT0006E: It is not possible to contact
a messaging engine in bus YOURBUS..
at
com.ibm.ws.sib.api.jms.impl.JmsManagedConnectionFactoryImpl.createConnection(JmsManagedConnectionFactoryImpl.java:225)
at
com.ibm.ws.sib.api.jms.impl.JmsManagedConnectionFactoryImpl.createConnection(JmsManagedConnectionFactoryImpl.java:148)


CAUSE
This can be caused by a stopped messaging engine, a wrong or misspelled bus name (case-sensitive) in the connection factory settings or, the HA manager is not able to find the running messaging engine.


RESOLVING THE PROBLEM
The error messages CWSIA0241E and CWSIT0006E indicate that when the connection was attempted, there were no running messaging engines available on the specified bus. To see why the messaging engines were not available, check the SystemOut.log for applicable messages. Examine the SystemOut.log file starting at the time period when the application experienced the problem and search backward. 


Check for the CWSID0016I which indicates status of the Messaging Engine activity. You may see messages like this:

SibMessage I [:] CWSID0016I: Messaging engine [mename]is in state Stopping.
SibMessage I [:] CWSID0016I: Messaging engine [mename]is in state Stopped.

The solution for this problem is to start the messaging engine.

If the messaging engine is running and you still see these errors at the application side, other possible reasons for this problem are:

1) Check provider end points. The value for the provider endpoints should be in the format of host_name:port_number:BootstrapBasicMessaging.

In the JMS connection factory, you can define a list of provider endpoints that govern which servers the application will attempt to connect to. If you have defined these endpoints, ensure that the messaging engines for these servers have all started and that the port and transport chains defined in the endpoint list are correct. Also, ensure that the values for the Connection proximity (bus, cluster, host or server) and the Target groups and Target significance settings are appropriate. For example, if the Target significance value is Required and no suitable messaging engine could be located, then this would cause a connection failure. Please refer to the following links for how to set provider endpoints:

Default messaging provider queue connection factory [Settings] : [https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/SIBJMSQueueConnectionFactory_DetailForm.html]

Default messaging provider topic connection factory [Settings]: [https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/SIBJMSTopicConnectionFactory_DetailForm.html]

Restart the server after making the change.

2) If your environment is heavily loaded, the HA manager might not be able to locate the running messaging engine within three seconds. In this case, check if there are any hung threads in the SystemOut.log, and resolve them if possible. Next, consider increasing the value of sib.trm.linger from three to give the HA manager more time to locate a messaging engine.

Tune the sib.trm.linger property value in the sib.properties file to set the messaging engine lookup delay so that the Work Load Manager (WLM) waits for a longer period of time before returning an error. Please refer to information below on how to set this property in the sib.properties. 

1)<WAS_HOME>/properties : The properties declared under this location would be applicable to all the profiles in that installation.

2)<PROFILE_ROOT>/properties : The properties declared here are applicable for all the servers on this profile

If a property is defined at both <PROFILE_ROOT>/properties and <WAS_HOME>/properties, then the property defined at <PROFILE_ROOT>/properties would take precedence.

After resetting the property you must restart the server.




Cross reference information Segment Product Component Platform Version Edition Business Integration WebSphere MQ Not Applicable Business Integration WebSphere Process Server Business Integration WebSphere Service Registry and Repository Business Integration IBM Business Process Manager Standard Business Integration WebSphere Enterprise Service Bus Business Integration WebSphere Partner Gateway Advanced Edition Configuration Business Integration WebSphere MQ Configuration 
PRODUCT ALIAS/SYNONYM
 WebSphere Application Server WAS SIB SIBUS SI BUS

Question: WAS 8.5.x - Writing a JMS message to a remote queue takes a long time. How to write the message faster? 

We are writing a jms message from a websphere cell (cellA) to a queue hosted by another websphere cell (cellB). Sometimes we noticed that writing a message is very slow. Usually when a local queue will be used the time to write this messages is about 8 ms, but if the queue is located on a other cell is took significant longer (about 3000ms+ ).

Our findings: After enabling following trace "=info: com.ibm.ws.sib.trm.=finest" the problem is related to:
- com.ibm.ws.cluster.selection.NoAvailableTargetExceptionImpl
- WaitForWLMDat 3 (com.ibm.ws.sib.trm.wlm.client.WaitForWLMData) [:] Sleeping for 2999 ms "

Because of the sleep time the writing to the queue is slowed down. How to prevent the sleeping time of 3 seconds, when writing a message to a remote queue?

Answer: If your environment is heavily loaded, the HA manager might not be able to locate the running messaging engine within three seconds. In this case, check if there are any hung threads in the SystemOut.log, and resolve them if possible. Next, consider increasing the value of sib.trm.linger from three to give the HA manager more time to locate a messaging engine.

Tune the sib.trm.linger property value in the sib.properties file to set the messaging engine lookup delay so that the Work Load Manager (WLM) waits for a longer period of time before returning an error. Please refer to information below on how to set this property in the sib.properties. 

1)<WAS_HOME>/properties : The properties declared under this location would be applicable to all the profiles in that installation.

2)<PROFILE_ROOT>/properties : The properties declared here are applicable for all the servers on this profile

If a property is defined at both <PROFILE_ROOT>/properties and <WAS_HOME>/properties, then the property defined at <PROFILE_ROOT>/properties would take precedence.

After resetting the property you must restart the server.