WebSphere MQ messaging troubleshooting tips

 

+

Search Tips   |   Advanced Search

 

These hints include a description of the scenario where a problem occurred, the probably reason for the problem and the recommended solution. What kind of problem are you seeing?

If you do not see a problem that resembles yours, or if the information provided does not solve your problem, see Messaging component troubleshooting tips.

If you see WebSphere MQ error messages or reason codes in WebSphere Application Server messages and logs, refer to the WebSphere MQ Messages document

If you are still unable to resolve the problem, see Troubleshooting help from IBM.

  1. An MDB listener fails to start
  2. Problems running JMS applications with security enabled
  3. Queue manager fails to stop on Redhat Linux
  4. Application server fails to start in zh_TW.EUC locale on Solaris
  5. Server memory consumption and java.lang.OutOfMemoryError exception when processing JMS messages
  6. TopicConnectionFactory attributes clash error when using "Basic" WebSphere MQ broker (MA0C SupportPac broker)
  7. Message WSEC5061E: The SOAP Body is not signed is issued when running a secured Web services application using JMS transport and WebSphere MQ
  8. Message MQJMS1006: invalid value for tempQPrefix is issued when trying to use a V5.1 client with a V5 Default Messaging queue connection factory on a V6 appserver
  9. When you use WebSphere MQ as an external JMS provider, messages sent within a user-managed transaction arrive before the transaction commits

For information about messaging problems that are specific to WebSphere Application Server nodes, see the following links:

 

An MDB listener fails to start

If an MDB listener deployed against a listener port fails to start, you should see the following message:

WMSG0019E: Unable to start MDB Listener {0}, JMSDestination {1} : {2} 
To troubleshoot the cause of an MDB listener not starting, check the following factors:

 

Problems running JMS applications with security enabled

When trying to run a JMS application with security enabled, you can encounter authentication problems indicated by error messages; for example:

WMSG0019E: Unable to start MDB Listener PSSampleMDB, JMSDestination Sample/JMS/listen : javax.jms.JMSSecurityException: this example indicates that the security credentials supplied are not valid).

The problem can be removed by doing one of the following:

 

MQJMS2013 invalid security authentication supplied for MQQueueManager:

If using WebSphere MQ as a JMS Provider, with JMS connection using bindings transport mode, and the user specified is not the current logged on user for the WAS process, the JMS bindings authentication by WebSphere MQ generates the error...

MQJMS2013 invalid security authentication supplied for MQQueueManager

To use WebSphere MQ as a JMS Provider with JMS connection using bindings transport mode, set the property...

Transport type=BINDINGS

...on the WebSphere MQ queue connection factory. You must also choose one of the following options:

For more information about messaging security, see Asynchronous messaging - security considerations.

 

Queue manager fails to stop on Redhat Linux

When trying to stop an appserver on Redhat Linux, the queue manager can hang with a Java core dump, and the last message in the SystemOut.log file is Stopping Queue manager....

This is caused by a known RedHat problem that was introduced in libstdc++-2.96-116.7.2 and beyond.

The workaround is to go back to the libstdc++-2.96-108.1 level.

 

Application server fails to start in zh_TW.EUC locale on Solaris

If you have set the locale to zh_TW.EUC on Solaris, and are using WebSphere MQ as a JMS provider, you can encounter problems that stop appservers starting up.

If you intend using WebSphere MQ as a JMS provider on Solaris, do not set the LANG and LC_ALL variables to zh_TW.EUC (Traditional Chinese locale) to avoid problems when starting appservers. Set the LANG and LC_ALL variables to zh_TW instead of zh_TW.EUC.

 

Server memory consumption and java.lang.OutOfMemoryError exception when processing JMS messages

Intensive processing of JMS messages using the default JMS provider (for example, significant concurrent processing of large messages) can cause a...

java.lang.OutOfMemoryError

...exception and cause the appserver to terminate.

Processing of JMS messages by the default provider is performed by a messaging engine within the appserver process, and therefore consumes memory from the appserver's JVM heap. This is in contrast with V5 where the support for the embedded JMS provider run in a separate process.

If the amount of memory available to the appserver's JVM heap has not been configured large enough to handle the effect of the number of concurrent producers or consumers of messages and the message size, then a java.lang.OutOfMemoryError exception is thrown and the appserver terminates.

Solution: When preparing to deploy applications that process JMS messages using the default messaging provider, you should plan for the potential consumption of the appserver's memory for message processing. You should take into account the potential number of concurrent processors or consumers of messages and the message size, then set the size of the appserver's JVM heap to handle the effect.

For example, when preparing to deploy a message-driven bean that is to be used to process messages concurrently, you should plan for the potential consumption of the appserver's memory by concurrent endpoints. Each endpoint that is concurrently processing a message request adds at least two times the message size to the server's JVM heap and can add more, especially if a two-phase transaction is in place.

You can configure the amount of memory available to the appserver's JVM heap by setting the Initial Heap Size and Maximum Heap Size properties of the appserver. For example, on the WAS administrative console panel:

Servers | Application servers | server_name | Java and Process Management | Process Definition | Java Virtual Machine

You can configure the number of concurrent MDB endpoints that can process messages by setting the Maximum concurrent endpoints property of the activation specification used to deploy the message-driven bean. For example, on the console panel:

Resources | JMS Providers | Default messaging | JMS activation specification | activationspec_name

 

TopicConnectionFactory attributes clash error when using "Basic" WebSphere MQ broker (MA0C SupportPac broker)

When creating a JMS topic subscriber using the WebSphere MQ messaging provider, the following error message occurs in the SystemOut.log file:

"WSVR0017E: Error encountered binding the J2EE resource, TopicConnectionFactory, as <JNDI_NAME>
   from file:<RESOURCES_FILE> com.ibm.ws.runtime.component.binder.ResourceBindingException: invalid
   configuration passed to resource binding logic. REASON: Failed to create connection factory:
   Error raised constructing AdminObject, error code:  TopicConnectionFactory attributes clash  : 
   TopicConnectionFactory attributes clash" 

This problem is causes by the configuration of the JMS topic connection factory used to create the subscriber, which specifies a broker version of "Basic" and a message selection value of "Broker". The "Basic" WebSphere MQ broker (MA0C SupportPac broker) does not support "Broker" message selection.

Solution: Change the JMS topic connection factory to specify a message selection value of "Client", which is the only supported value for the WebSphere MQ Basic broker (MA0C SupportPac broker).

 

Message WSEC5061E: The SOAP Body is not signed is issued when running a secured Web services application using JMS transport and WebSphere MQ

When running a secured Web services application using JMS transport using the WebSphere MQ messaging provider, the following error message occurs in the SystemOut.log file:

[9/7/04 12:10:02:895 GMT-06:00] 00000039 enterprise    I   TRAS0014I: The following exception was
   logged WebServicesFault

 faultCode: {http://schemas.xmlsoap.org/ws/2003/06/secext}FailedCheck
 faultString: WSEC5061E: The SOAP Body is not signed.; null
 faultActor: null
 faultDetail: 
       stackTrace: com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5061E: The SOAP Body is not
          signed.; null
...

The problem scenario has WebSphere Application Server security enabled, and one Web services application configured with Web services security has attempted and failed to use the JMS transport to send SOAP requests to the target Web service. The JMS resource is configured with WebSphere MQ using a remote WebSphere MQ server. The queue manager exists on this WebSphere MQ server.

The cause of this problem is another identical application is also running from a different appserver but using the same queue manager and same queue name in the same WebSphere MQ server. The request sent from the original application has been processed through the same queue, but to the different appserver where security might not have been enabled.

Solution: To avoid this problem...

  1. Create a unique queue manager with a unique port in the WebSphere MQ server.

    Reconfigure the JMS resources to use the new queue manager and port; for example, by using the WAS administrative console to change the properties of the WebSphere MQ queue connection factory

  2. Rerun the application.

 

Message MQJMS1006: invalid value for tempQPrefix is issued when trying to use a V5.1 client with a V5 Default Messaging queue connection factory on a V6 appserver

When trying to use a V5.1 application client to connect to a queue connection factory defined as a "V5 Default Messaging" resource on a V6 appserver. the following message appears:

com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while the JNDI
   NamingManager was processing a javax.naming.Reference object.  
Root exception is com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred
   while the JNDI NamingManager was processing a javax.naming.Reference object.  
Root exception is javax.jms.JMSException: MQJMS1006: invalid value for tempQPrefix:

Cause: The application client is using WebSphere MQ JMS client CSD 04 JAR files. WAS V6 sets tempQprefix to blank, which cannot be handled by the CSD 04 release of the method setTempqPrefix.

Solution If the application client uses WebSphere embedded messaging JAR files, then apply the WebSphere Embedded Messaging interim fixes for WAS V5.1. If the client uses external WebSphere MQ JMS client JAR files, than apply CSD05.

 

When you use WebSphere MQ as an external JMS provider, messages sent within a user-managed transaction arrive before the transaction commits

When you use WebSphere MQ as an external JMS provider, messages sent within a user-managed transaction can arrive before the transaction commits. This occurs only when you use WebSphere MQ as an external JMS provider, and you send messages to a WebSphere MQ queue within a user-managed transaction. The message arrives on the destination queue before the transaction commits.

The cause of this problem is that the WebSphere MQ resource manager has not been enlisted in the user-managed transaction.

The solution is to use a container-managed transaction.

 

Messaging engine start error, "CWSIS1501E: The data source has produced an unexpected exception

When a messaging engine attempts to start, the following error appears in the log:

CWSIS0002E: The messaging  engine encountered an exception while starting. Exception: 
   com.ibm.ws.sib.msgstore.PersistenceException: CWSIS1501E: The data source has produced an
   unexpected exception: java.sql.SQLException: <dbname> DSRA0010E: SQL  State = 2E000, Error
   Code = -1,001DSR A0010E: SQL State = 2E000, Error Code = -1,001

Cause: The database for the messaging engine could not be found.

Solution: Review the database name on the messaging engine for accuracy and check that the database has been created.

 

javax.jms.JMSException: MQJMS2008: failed to open MQ queue in JVM log

This error can occur when the MQ queue name is not defined in the internal JMS server queue names list. This problem can occur if a WAS queue destination is created, without adding the queue name to the internal JMS server queue names list. To resolve this problem:

  1. Open the console.

  2. Click Servers > Manage Application Servers > server> Server Components > JMS Servers.

  3. Add the queue name to the list.

  4. Save the changes and restart the server.

 

javax.jms.JMSException: MQJMS3024: unable to start MDB listener

This error can occur if an uninitialized client ID is used (a ClientID that is not associated with a durable subscription). To resolve this problem, set the ClientID in one of the following three ways:

 

SVC: jms.BrokerCommandFailedExceptfailed: 3008

One possible cause for this error is that you logged on to a Windows 2000 system as an administrator.

To correct this problem, log out and log in again as a user, rather than an administrator.

For current information available from IBM Support on known problems and their resolution, see the IBM Support page.

IBM Support has documents that can save you time gathering information needed to resolve this problem. Before opening a PMR, see the IBM Support page.


Sub-topics


Messaging errors

WebSphere MQ connection and queue connection factory creation errors

Messaging component troubleshooting tips

 

Related tasks

Troubleshooting WebSphere messagingTroubleshooting service integration technologies