Troubleshoot WebSphere Messaging
Contents
- JMS server not started by default
- JMS server tries to start, but fails
- MDB listener fails to start
- Failure to create a queue connection
- Problems running JMS applications with security enabled
- Queue manager fails to stop on Redhat Linux
- Application server fails to start in zh_TW.EUC locale on Solaris
- WAS Embedded Messaging fails to install on top of WebSphere MQ
The JMS server does not start when starting the WebSphere administrative server
During installation, the system PATH setting is updated to include the WebSphere Messaging directories. If you try to start the WebSphere administrative server from a session that does not use the updated system PATH, the JMS Server fails to start properly. To resolve this after installing WAS stop then restart your host or open a new session that uses the updated system PATH.
Also, when installing WAS, the JMS server is not configured to start automatically by default, except on Windows if the messaging samples are installed. So, generally, if you want to use JMS resources on that host, use the administrative console to configure the JMS server to start automatically.
Finally, check that the JMS server has started before trying to use WebSphere Messaging. For SystemOut.log messages that indicate the JMS server has started successfully, see the following tip The JMS server tries to start, but fails.
The JMS server tries to start, but fails
To see if the JMS Server has started, check the was_home\logs\server\SystemOut log. If the JMS server started successfully, see the following lines
JMSProvider A MSGS0050I: Starting the Queue Manager
JMSProvider A MSGS0051I: Queue Manager open for business
JMSProvider A MSGS0052I: Starting the Broker
JMSProvider A MSGS0053I: Broker open for businessIf the JMS server tries to start, but fails, see messages indicating that the queue manager could not start, like the following
QueueManagerM E MSGS0153E: The Queue Manager process could not be started - error: com.ibm.ws.process.exception.InvalidExecutableException: The system cannot find the file specified. 002: No such file or directory
An MDB listener fails to start
If an MDB listener fails to start, 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 authetication alias has been specified on the queue connection factory or topic connection factory used by the message-driven bean. This is not required if security is not enabled.
- Check that the user ID used to start the MDB listener has 12 characters or less.
For example, the default Windows NT user ID, administrator, is not valid for use with WebSphere embedded messaging, because it contains 13 characters.
(UNIX platforms only) Check that this user ID is a member of the mqm and mqbrkrs groups.
Failure to create a queue connection
If WAS fails to create a queue connection, the SystemOut.log contains messages like the following
[date time] 577cb554 PoolManager E J2CA0046E: Method addNewConnection caught javax.resource.spi.ResourceAdapterInternalException: createQueueConnection failedCheck that the JMS server is running (including that the Internal WebSphere Messaging or WebSphere MQ JMS provider was installed correctly) as described in preceding tips.
Note that In a Network Deployment or Enterprise multi-node cell, the JMS server used by a messaging application can be on a different node to the application. Either check that all JMS servers in the cell have started, or use the Administrative console to determine which JMS server the application is trying to connect to (look at the Node property of the appropriate connection factory), then check that the JMS server has started.
Embedded WebSphere Messaging failed to install on top of an existing WebSphere MQ product
When preparing to install WAS on a host that already has WebSphere MQ installed, ensure that WebSphere MQ is at a prerequisite level, as described in the Release Notes and Supported hardware, software, and APIs page of the WebSphere Application Server library web site. You can also check the WebSphere MQ Support service summary Web page at http://www-3.ibm.com/software/ts/mqseries/support/summary/.
If you have a problem installing the embedded WebSphere Messaging function, first check the mq_install.log. Failures during the WebSphere Messaging prereq stage usually indicate a shortage of space. Failures after this stage are usually due to a conflict between messaging components already installed on the machine and the levels required to support the J2EE 1.3 specification.
If the embedded WebSphere Messaging function installed successfully, see messages like the following in mq_install.log
MsiInstallProduct() returning ERROR_SUCCESS (0)
======================= Exiting Publish And Subscribe Install ======================
<<Function Successful>> return code WASM_ERROR_SUCCESS (0)
======================= End of WebSphere Messaging Install Log ======================You can also check the createMQ.log for any messages that indicate a configuration problem with the installation of WebSphere Messaging.
Problems running JMS applications with security enabled
When trying to run a JMS application with security enabled, you can encounter problems indicated by one of the error messages...
MSGS0508E: The JMS Server security service was unable to authenticate userid... This indicates that the JMS connection has not provided the WebSphere JMS server with any security credentials.
WMSG0019E: Unable to start MDB Listener PSSampleMDB, JMSDestination Sample/JMS/listen : javax.jms.JMSSecurityException... This indicates that the security credentials supplied are not valid. In both cases the problem can be removed by doing one of the following...
- If the authentication mechanism is set to Application, then the application needs to supply valid credentials.
- If the authentication mechanism is set to Container, then you need to configure the JMS ConnectionFactory with a container-managed Authentication Alias and ensure that the associated username and password are valid.
MQJMS2013 invalid security authentication supplied for MQQueueManager If using a WebSphere MQ JMS Provider JMS connection when using Bindings transport mode, and the user specified is not the current logged on user for the WAS process, then the WebSphere MQ JMS Bindings authentication throws the error MQJMS2013 invalid security authentication supplied for MQQueueManager. If you want to use a WebSphere MQ JMS Provider JMS connection when using Bindings transport mode, you set the property Transport type=BINDINGS on the WebSphere MQ Queue Connection Factory. You must also choose one of the following options:
- To use security credentials, ensure that the user specified is the currently logged on user for the WAS process.
- Do not specify security credentials. On the WebSphere MQ Connection Factory, ensure that both the Component-managed Authentication Alias and the Container-managed Authentication Alias properties are not set.
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 (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 the WebSphere embedded JMS provider or WebSphere MQ as the JMS provider, you can encounter problems that stop appservers starting up.
If you intend using the WebSphere embedded JMS provider or WebSphere MQ as the 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.
See Also
Troubleshooting WebSphere Messaging