WebSphere MQ messaging troubleshooting tips

These hints include a description of the scenario where a problem occurred, the probable reason for the problem and the recommended solution.

What kind of problem are you seeing?

If you see WebSphere MQ error messages or reason codes in WebSphere Application Server messages and logs, refer to the WebSphere MQ Messages document at http://publibfi.boulder.ibm.com/epubs/pdf/amqzao05.pdf.

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

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:
  • Check that the administrative resources have been configured correctly; for example, use the administrative console to check the listener port properties: Destination JNDI name and Connection factory JNDI name. Check that other properties of the listener port, destination, and connection factory are correct.
  • Check that the queue exists and has been added to the JMS server.
  • Check that the queue manager and JMS server have started.
  • Check that the Remote Queue Manager Listener has started.
  • If security is enabled, check that a component-managed authentication alias has been specified on the queue connection factory or topic connection factory used by the message-driven bean.
  • Check that the user ID used to start the MDB listener is appropriately authorized.

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:
  • If the authentication mechanism is set to Application, the application must supply valid credentials.
  • If the authentication mechanism is set to Container, configure the JMS ConnectionFactory with a container-managed Authentication Alias, and ensure that the associated username and password are valid. Alternatively when running in bindings transport mode you can exploit the connector thread identity support.

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

Queue manager fails to stop on Redhat Linux

When trying to stop an application server 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 (https://bugzilla.linux.ibm.com/show_bug.cgi?id=2336), 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 application servers 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 application servers. 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 application server to terminate.

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

If the amount of memory available to the application server'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 application server 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 application server'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 application server'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 application server'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 application server's JVM heap by setting the Initial Heap Size and Maximum Heap Size properties of the application server. For example, on the WebSphere Application Server 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. To modify an activation specification , click the activation specification name in the following administrative console collection panel: Resources > JMS Providers > Default messaging > [Activation Specifications] JMS activation specification

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 global 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 application server 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 application server where global security might not have been enabled.

Solution: To avoid this problem, complete the following steps:
  1. Create a unique queue manager with a unique port in the WebSphere MQ server.
  2. Reconfigure the JMS resources to use the new queue manager and port; for example, by using the WebSphere Application Server administrative console to change the properties of the WebSphere MQ queue connection factory, as described in Configuring a queue connection factory for the WebSphere MQ messaging provider.

  3. 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 application server

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 application server. 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. WebSphere Application Server Version 6 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 WebSphere Application Server 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.

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 Java Message Service (JMS) server queue names list. This problem can occur if a WebSphere Application Server queue destination is created, without adding the queue name to the internal JMS server queue names list.

To resolve this problem:
  1. Open the WebSphere Application Server administrative console.
  2. Click Servers > Manage Application Servers > server_name> Server Components > JMS Servers.
  3. Add the queue name to the list.
  4. Save the changes and restart the server.

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.

Failure to use the WebSphere MQ JMS provider or a WebSphere MQ server to integrate a z/OS WebSphere MQ server into the service integration bus

When you start IBM WebSphere Application Server Version 6.1, the following exception might occur:
JMSRegistrati E WMSG1603E: An internal error occurred. It was not possible to register the WebSphere MQ JMS client with the application server due to exception org.osgi.framework.BundleException: The bundle could not be resolved.
When this exception occurs, the WebSphere MQ Java™ Message Service (JMS) client cannot register with the server run time. The result is that the WebSphere MQ JMS provider cannot be used and the WebSphere MQ server functionality cannot be used in the service integration bus.

This problem occurs when two WebSphere processes, for example, an application server and a node agent, update the same open services gateway initiative (OSGi) cache when the server starts. This situation happens when the two processes start for the first time. The problem also can occur after service has been applied or after you modify the MQ_INSTALL_ROOT variable.

The solution is to clear the OSGi cache by running a script that is located in the profile_root/bin directory. Different scripts are provided for the Microsoft® Windows®, UNIX® and i5/OS® operating systems.

To avoid this problem in the future, ensure that the OSGi cache is updated consistently by completing the following procedure for each affected profile which contains a node agent either after you have applied service or after you update the MQ_INSTALL_ROOT variable:
  1. Ensure that all server processes in the profile are stopped including the node agent.
  2. Start the application server.
  3. Stop the application server.
The OSGi cache has now been updated consistently, so you can start the servers in the profile as normal.



Subtopics
Messaging errors
WebSphere MQ connection and queue connection factory creation errors
Messaging component troubleshooting tips
Related tasks
Troubleshooting service integration technologies
Troubleshooting messaging
Related reference
Default messaging provider - troubleshooting tips
rins_dircon.html
Reference topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 10:03:57 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=rmj_prob0
File name: rmj_prob0.html