This topic provides a set of tips to help you troubleshoot problems with WebSphere Messaging.
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 WebSphere Application Server, stop then restart your host or open a new session that uses the updated system PATH.
When WebSphere Application Server is first installed, the JMS server is not configured to start automatically by default:
Check that the JMS server has started before trying to use WebSphere Messaging. For messages that indicate the JMS server has started successfully, see the following tip The JMS server tries to start, but fails.
For more information about managing JMS servers, see Administering WebSphere JMS support.
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, you should see the following messages:
MSGS0050I: Starting the Queue Manager MSGS0051I: Queue Manager open for business MSGS0052I: Starting the Broker MSGS0053I: Broker open for business
If the JMS server tries to start, but fails, you should see messages indicating that the queue manager could not start, like the following:
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, 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:
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 WebSphere Application Server fails to create a queue connection, the SystemOut.log contains error messages like the following:
J2CA0046E: Method addNewConnection caught javax.resource.spi.ResourceAdapterInternalException: createQueueConnection failed
Check 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: 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 WebSphere Application Server on a host that already has WebSphere MQ installed, you should ensure that WebSphere MQ is at a prerequisite level, as described in the Release Notes and WebSphere Application Server detailed system requirements Web page. You can also check the WebSphere MQ Support service summary Web page at http://www.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, you should see messages like the following in mq_install.log:
... date time MsiInstallProduct() returning ERROR_SUCCESS (0) date time ======================= Exiting Publish And Subscribe Install ====================== date time <<Function Successful>> return code WASM_ERROR_SUCCESS (0) date time ======================= 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:
In both cases the problem can be removed by doing one of the following:
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:
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 the WebSphere embedded JMS provider or WebSphere MQ as the JMS provider, you can encounter problems that stop application servers 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 application servers. Set the LANG and LC_ALL variables to zh_TW instead of zh_TW.EUC.