Tips for troubleshooting WebSphere Messaging

This topic provides a set of tips to help you troubleshoot problems with WebSphere Messaging.

For messaging problems specific to WAS nodes, see the information center and the Application Servers support web site; for example: Tips for troubleshooting WebSphere messaging [v5].

 

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. This is not required if security is not enabled.

  • 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, one 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, 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 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, then the JMS Bindings authentication by WebSphere MQ throws the error MQJMS2013 invalid security authentication supplied for MQQueueManager.

If you want to use WebSphere MQ as a JMS Provider, with JMS connection using Bindings transport mode, 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 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, one 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 V5 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.

We 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 administrative console panel: Servers > Application servers > servername > Java and Process Management > Process Definition > Java Virtual Machine .

One 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. For example, on the WebSphere administrative console panel: Resources > JMS Providers > Default messaging > JMS activation specification > activationspec_name.

 

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).


 

Related Tasks


Troubleshooting service integration messaging

 

See Also