Messaging troubleshooting tips
These tips are to help you troubleshoot the WebSphere messaging configuration.
To help you resolve problems with messaging, use the WAS trace and logging facilities.
If having problems deploying or running applications that use the WAS messaging capabilities, see the following topics:
- Troubleshooting messaging
- Troubleshooting message-driven beans
- Troubleshooting service integration technologies
- Default messaging provider: Troubleshooting tips
If we see WebSphere MQ error messages or reason codes in WAS messages and logs, refer to the WebSphere MQ Messages document.
Check to see if the problem has been identified and documented using the links in Diagnose and fix problems: Links.
Here is a set of tips to help you troubleshoot commonly-experienced problems. If we do not see a problem that resembles thes, or if the information provided does not solve the problem, contact IBM support for further assistance.
- When you migrate WAS profiles between maintenance level 7.0.0.0 and later levels, manually adjust the WebSphere MQ resource adapter configuration
- Messages from WebSphere MQ for z/OS are not being consumed by JMS applications that are deployed into WAS and that use connection factories or activation specifications
- A JMS application can no longer send or receive messages, or a destination becomes full and can no longer receive messages
- javax.jms.JMSException: MQJMS2008: failed to open MQ queue in JVM log
- javax.jms.JMSException: MQJMS3024: unable to start MDB listener
- SVC: jms.BrokerCommandFailedExceptfailed: 3008
- An MDB listener fails to start
- Problems running JMS applications with security enabled
- Application server does not start when the zh_TW.EUC locale is set on Solaris
- Server memory consumption and java.lang.OutOfMemoryError exception when processing JMS messages
- TopicConnectionFactory attributes clash error when using "Basic" WebSphere MQ broker (MA0C SupportPac broker)
- WSEC5061E: The SOAP Body is not signed exception is issued when running a secured Web services application using JMS transport and WebSphere MQ
- Message MQJMS1006: invalid value for tempQPrefix is issued when trying to use a V5.1 client with a V5 default messaging provider queue connection factory on a V7 appserver
- When you use WebSphere MQ as an external JMS provider, messages sent within a user-managed transaction arrive before the transaction commits
- javax.jms.JMSException: MQJMS3024: unable to start MDB listener
- javax.jms.JMSException: MQJMS3024: unable to start MDB listener
When you migrate WAS profiles between maintenance level 7.0.0.0 and later levels, manually adjust the WebSphere MQ resource adapter configuration
The code provided by the WebSphere MQ resource adapter is used by the WebSphere MQ messaging provider, and also by the WebSphere MQ link and WebSphere MQ server features of the default messaging provider. In profiles created at WAS maintenance level 7.0.0.0, the WebSphere MQ resource adapter binary files are located in each profile. In profiles created at WAS maintenance level 7.0.0.1 or later, these binary files are located in the APP_ROOT directory. When you apply maintenance to a WAS V7 installation, the maintenance pack only updates the WebSphere MQ resource adapter binary files in the APP_ROOT directory. This behavior gives rise to the following scenarios:
- When you apply maintenance to a WAS installation that contains profiles created at the 7.0.0.0 maintenance level, the WebSphere MQ resource adapter code used by those profiles does not get updated. You must manually adjust the resource adapter configuration so that the profiles use the set of WebSphere MQ resource adapter binary files from the APP_ROOT directory. This also ensures that these profiles continue to use the most recent version of the resource adapter binary files when subsequent maintenance packs are applied.
- By creating a profile at WAS maintenance level 7.0.0.1 or later, then subsequently plan to remove the maintenance pack so that the installation reverts to maintenance level 7.0.0.0, manually adjust the WebSphere MQ resource adapter configuration to ensure the resource adapter is loaded, because the set of WebSphere MQ resource adapter binaries are removed from the APP_ROOT directory as part of uninstalling the maintenance pack.
To resolve these issues, see Adjusting the WebSphere MQ resource adapter configuration when migrating profiles between maintenance level 7.0.0.0 and later levels.
Messages from WebSphere MQ for z/OS are not being consumed by JMS applications that are deployed into WAS and that use connection factories or activation specifications
There is a known restriction which means that, when you use the WebSphere MQ messaging provider to connect to a recent version of WebSphere MQ for z/OS, configure the connection factories and activation specifications to treat the WebSphere MQ for z/OS network as if it were a WebSphere MQ for z/OS V6.0 network. Specifically, configure the Provider version property of each associated connection factory or activation specification with a value of 6.0.0.0.
See about how to do this, see any of the following topics:
- Set an activation spec for the WebSphere MQ messaging provider.
- Set a unified connection factory for the WebSphere MQ messaging provider.
- Set a queue connection factory for the WebSphere MQ messaging provider.
- Set a topic connection factory for the WebSphere MQ messaging provider.
A JMS application can no longer send or receive messages, or a destination becomes full and can no longer receive messages
When you configure an application to use the default messaging provider, you associate it with either of the following resource sets:
- One or more message beans connected through JMS activation specifications.
- One or more enterprise beans connected through JMS connection factories and JMS destinations.
To help resolve this problem, use the following admin console panels to inspect the configuration of the applications and JMS resources:
- For a view of the JMS resources for a given application, see the following panel: Messaging resources for this application.
- For a view of the applications and JMS resources for a given default messaging provider destination, see the following panel: Application resources for this destination.
javax.jms.JMSException: MQJMS2008: failed to open MQ queue in JVM log
This error can occur when the WebSphere 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:
- Start the WAS admin console.
- Navigate to Servers > Server Types > V5 JMS servers
- Add the queue name to the list.
- 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 (that is a client ID not associated with a durable subscription). To resolve this problem, set the client ID in one of the following three ways:
- As a property of the tcf via jmsadmin (for example alter tcf(myTCF) clientid(myID))
- Programmatically using TopicConnection.setClientID()
- Through the client ID field on the WebSphere MQ topic connection factory resource.
See WebSphere MQ connection and queue connection factory creation errors.
SVC: jms.BrokerCommandFailedExceptfailed: 3008
One possible cause for this error is that you logged on to a Windows 2000 system as an administrator.
To resolve this problem, log out and log in again as a user, rather than an administrator.
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 help resolve this problem, check the following factors:
- Check that the admin resources have been configured correctly. For example, use the admin 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. For more information, see Problems running JMS applications with security enabled.
Problems running JMS applications with security enabled
When you try to run a JMS application with security enabled, we can encounter authentication problems indicated by one or more of the following error messages: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. To resolve this problem, check the security configuration:
- 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 connection factory with a container-managed authentication alias, and verify the associated user ID and password are valid.
MQJMS2013 invalid security authentication supplied for MQQueueManager:If we are 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 an invalid security authentication error. To resolve this problem, check the security configuration. When you configure the WebSphere MQ JMS provider to use bindings transport mode, you set the property Transport type to BINDINGS on the WebSphere MQ queue connection factory. At this time, you also choose one of the following options:
- Use security credentials. To do this, verify the user specified is the currently logged-on user for the WAS process.
- Do not use security credentials. On the WebSphere MQ connection factory, ensure that the Component-managed Authentication Alias and the Container-managed Authentication Alias properties are not set.
See about messaging security, see Secure messaging.
Application server does not start when the zh_TW.EUC locale is set on Solaris
On Solaris, if we set the locale to zh_TW.EUC and we are using WebSphere MQ as a JMS provider, the appservers might not start up.
To resolve this problem, set the LANG and LC_ALL variables to zh_TW.
Server memory consumption and java.lang.OutOfMemoryError exception when processing JMS messages
When you use the default messaging provider, JMS messages are processed by a messaging engine within the appserver process. This approach consumes memory from the appserver's JVM heap. If there is significant concurrent processing of large messages, and the amount of memory available to the JVM heap is not enough to handle this event, then a java.lang.OutOfMemoryError exception is thrown and the application server terminates. To resolve this problem, estimate the potential number of concurrent processors or consumers of messages and the message sizes, then set the size of the appserver's JVM heap to handle the effect. For example:
- When you deploy a message-driven bean that processes messages concurrently, estimate the potential consumption of the application server's memory by concurrent endpoints. Note that 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.
- Start the WAS admin console.
- Navigate to Servers > Server Types > WebSphere application servers > server_name > Java and Process Management > Process Definition > Java Virtual Machine, then configure the amount of memory available to the appserver's JVM heap by setting the Initial Heap Size and Maximum Heap Size properties.
- Navigate to Resources > JMS > JMS providers > Default messaging provider > Activation specifications > activation_specification_name , then configure the number of concurrent MDB endpoints that can process messages by setting the Maximum concurrent endpoints property of the activation spec for this message-driven bean.
TopicConnectionFactory attributes clash error when using "Basic" WebSphere MQ broker (MA0C SupportPac broker)
When you create a JMS topic subscriber that uses the WebSphere MQ messaging provider, the following error message can occur in SystemOut.log: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 clashThis problem is caused 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.
To resolve this problem, 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).
WSEC5061E: The SOAP Body is not signed exception is issued when running a secured Web services application using JMS transport and WebSphere MQ
When you run a secured Web services application that uses JMS transport under the WebSphere MQ messaging provider, the following error message can occur in the SystemOut.log file:com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5061E: The SOAP Body is not signed.; nullThis problem occurs under the following circumstances:
- A Web service application, configured with WS-Security, is running in an appserver that has WAS security enabled.
- This Web service application uses the JMS transport to send SOAP requests to a target Web service.
- The JMS resource uses a remote WebSphere MQ server to connect to a WebSphere MQ queue.
- Another identical Web service application, configured to use the same queue through the same WebSphere MQ server, is running in a different appserver that does not have WebSphere Application WAS security enabled.
The problem occurs when a request sent from the original application is processed through the same queue, but to the different appserver where security is not enabled. To resolve this problem:
- 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 admin console to change the properties of the WebSphere MQ queue connection factory.
- Rerun the application.
Message MQJMS1006: invalid value for tempQPrefix is issued when trying to use a V5.1 client with a V5 default messaging provider queue connection factory on a Version 7 appserver
When you use a WAS V5.1 application client to connect to a queue connection factory defined as a "V5 default messaging provider"" resource on a WAS V7 appserver, the following message is displayed: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:This problem occurs when the application client is using WebSphere MQ JMS client CSD 04 JAR files. WAS V7 sets the tempQprefix property to blank, and this value cannot be handled by the CSD 04 release of the setTempqPrefix method.
To resolve this problem:
- If the application client uses WebSphere embedded messaging JAR files, apply the WebSphere embedded messaging interim fixes for WAS V5.1.
- If the client uses external WebSphere MQ JMS client JAR files, apply the CSD 05 release.
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, and you send a message to a WebSphere MQ queue within a user-managed transaction, the message can arrive on the destination queue before the transaction commits. This problem occurs when the WebSphere MQ resource manager is not enlisted in the user-managed transaction.
To resolve this problem, use a container-managed transaction.
javax.jms.JMSException: MQJMS3024: unable to start MDB listener
This error can occur if we use an uninitialized client ID (that is, a client ID not associated with a durable subscription). To resolve this problem, set the client ID in one of the following three ways:
- Set the client ID as a property of the tcf, using the jmsadmin tool. For example, alter tcf(myTCF) clientid(myID).
- Set the client ID programmatically, using TopicConnection.setClientID()
- Set the client ID field administratively, using the admin console to modify the WebSphere MQ messaging provider topic connection factory settings.
SVC: jms.BrokerCommandFailedExceptfailed: 3008
This error can occur when you log in to a Windows 2000 system as an administrator.
To resolve this problem, log out and log in again as a user, rather than an administrator.
Subtopics
WebSphere MQ connection and queue connection factory creation errors
Related tasks
Troubleshooting message-driven beans
Troubleshooting performance monitoring statistics
WebSphere MQ messaging provider topic connection factory settings
Troubleshooting messaging
Troubleshooting service integration technologies
Related
Application deployment troubleshooting tips
Messaging resources for this application
Application resources for this destination