Tips for troubleshooting WebSphere Messaging

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.

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 for error messages in the SYSPRINT or SYSOUT 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

If you see a message like the following, check to see that required WebSphere MQ messages are not being suppressed by the message processing facility (MPF):

BBOO0222I WSVR0002I: Server CONTROL PROCESS xyzabc open for e-business, problems occurred during startup

Before starting a JMS server, ensure that the following WebSphere MQ messages are not being suppressed by the message processing facility:

CSQV086E CSQY022I CSQY003I CSQX022I CSQM132I CSQ9022I CSQX017I CSQ3104I CSQ3106E

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:

Failure to create a queue connection

If WebSphere Application Server fails to create a queue connection, the SYSPRINT and SYSOUT 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:

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:

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 WebSphere Application Server 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 WebSphere Application Server 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.

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.


Related tasks
Troubleshooting WebSphere Messaging



Searchable topic ID:   rmj_prob0
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rmj_prob0.html

Library | Support | Terms of Use | Feedback