These tips are to help you troubleshoot your WebSphere® messaging
configuration.
New feature: This topic
references one or more of the application server log files. Beginning
in WebSphere Application Server Version 8.0 you can configure the
server to use the High Performance Extensible Logging (HPEL) log and
trace infrastructure instead of using
SystemOut.log ,
SystemErr.log,
trace.log,
and
activity.log files or native z/OS logging
facilities. If you are using HPEL, you can access all of your log
and trace information using the LogViewer command-line tool from your
server profile bin directory. See the information about using HPEL
to troubleshoot applications for more information on using HPEL.
newfeat
To help you identify and resolve problems
with messaging, you can use the WebSphere Application
Server trace and logging facilities as described in Tracing and logging configuration.
To help you identify and resolve problems with messaging,
you can use the WebSphere Application Server trace and
logging facilities as described in Setting up component trace (CTRACE).
If you are having problems deploying or running applications that
use the WebSphere Application Server messaging
capabilities, see the following topics:
If you see WebSphere MQ error messages or reason codes
in WebSphere Application Server messages and
logs, refer to the WebSphere MQ Messages document.
Check to see if the problem has been identified and documented,
by using the links in Diagnosing
and fixing problems: Resources for learning.
Here is a set of tips to help you troubleshoot commonly-experienced
problems. If you do not see a problem that resembles yours, or if
the information provided does not solve your problem,
contact IBM® support for
further assistance.
WebSphere MQ resource adapter
configuration is not automatically updated and requires manual maintenance
Normally
the WebSphere MQ resource adapter is automatically
updated when you apply a WebSphere Application Server fix pack. However,
if you have manually updated the WebSphere MQ
resource adapter on some nodes in your environment, applying a fix
pack does not automatically update the resource adapter that is used
by servers on those nodes.
To resolve this issue, see Maintaining the WebSphere MQ resource adapter.
java.lang.ClassNotFoundException
exceptions occur when you install a fix pack
If, when installing
a fix pack you see the following message, follow the instructions
in
Maintaining the WebSphere MQ resource adapter to try and resolve the
problem:
J2CA0043E: An exception occurred while trying to instantiate a ResourceAdapter
JavaBean instance for the installed ResourceAdapter defined by key #removed#
Messages from WebSphere MQ
for z/OS are not being consumed by JMS applications
that are deployed into WebSphere Application Server
and that use connection factories or activation specifications
For
more information about how to configure the
Provider version property,
see any of the following topics:
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 Java Message
Service (JMS) activation specifications.
- One or more enterprise beans connected through JMS connection
factories and JMS destinations.
To help resolve this problem, use the following administrative
console panels to inspect the configuration of your applications and
JMS resources:
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 Java Message Service (JMS) server
queue names list. This problem can occur if a WebSphere Application
Server queue destination is created without adding the queue name
to the internal JMS server queue names list.
To resolve this
problem:
- Start the WebSphere Application Server administrative
console.
- Navigate to
- Add the queue name to the list.
- Save the changes and restart the server.
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 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.If security is enabled, check that the user ID used
to start the MDB listener is appropriately authorized. 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, you 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,
you must configure the JMS connection factory with a container-managed
authentication alias, and ensure that the associated user ID and password
are valid. Alternatively, when running in bindings transport
mode you can exploit the connector thread identity support.
MQJMS2013 invalid security authentication supplied for MQQueueManager:
If
you are using WebSphere MQ as a JMS provider, with JMS
connection and using bindings transport mode, and the user specified
is not the current logged-on user for the WebSphere Application
Server 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, ensure that the user specified
is the currently logged-on user for the WebSphere Application
Server 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.
For more information about messaging
security, see Securing messaging.
Application server does
not start when the zh_TW.EUC locale is set on Solaris
On
Solaris, if you set the locale to zh_TW.EUC and you are using WebSphere MQ as a JMS provider, your application
servers 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 application server process. This approach consumes
memory from the application server 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 application server 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 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 JVM heap and can add more, especially
if a two-phase transaction is in place.
- Start the WebSphere Application Server administrative
console.
- Navigate to , then configure
the amount of memory available to the application server JVM heap
by setting the Initial Heap Size and Maximum
Heap Size properties.
- Navigate to , then configure the number of concurrent MDB endpoints
that can process messages by setting the Maximum concurrent
endpoints property of the activation specification for
this message-driven bean.
TopicConnectionFactory attributes clash
error when you use "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 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 caused by the configuration of
the JMS topic connection factory that is 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 that uses
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.; null
This problem occurs under the following circumstances:
- A web service application, configured with Web Services Security,
is running in an application server that has WebSphere Application
Server 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 application server that does not have WebSphere Application
Server security enabled.
The problem occurs when a request sent from the original
application is processed through the same queue, but to the different
application server 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 WebSphere Application
Server administrative console to change the properties of the WebSphere MQ queue connection factory,
as described in Configuring a queue connection factory for the WebSphere MQ messaging provider.
- Rerun the application.
Message MQJMS1006: invalid value for
tempQPrefix is issued when trying to use a Version 5.1 client
with a V5 default messaging provider queue connection factory on an
application server on a later version of the product
When
you use a WebSphere Application Server Version 5.1
application client to connect to a queue connection factory defined
as a
"V5 default messaging provider"" resource on an application
server on a later version of the product, 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.
The later version of the product 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 WebSphere Application Server
Version 5.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 you use an uninitialized client ID (that is, a client ID that is
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, by using the jmsadmin
tool. For example, alter tcf(myTCF) clientid(myID).
- Set the client ID programmatically, by using TopicConnection.setClientID()
- Set the client ID field administratively, by using the administrative
console to modify the WebSphere MQ messaging provider topic connection factory settings.
For the WebSphere MQ
messaging provider, channel framework messages appear during server
startup
The
following message might be displayed several times in the control
region adjunct process during server startup, even though the connection
succeeds on subsequent retries. This message is issued because of
the asynchronous way in which the z/OS TCP
proxy channel starts and does not indicate that any error has occurred.
Trace: 2009/06/17 08:24:41.434 01 t=9C6B58 c=UNK key=P8 (00000011)
Description: Log Java Message
Message: CHFW0030E: Error starting chain _InboundTCPProxyBridgeService because
of exception com.ibm.wsspi.channel.framework.exception.RetryableChannelException:
An exception was thrown when attempting to start the TCPProxyChannel
com.ibm.ws.channel.framework.imp l.ChannelFrameworkImpl
These messages might be accompanied by First Failure Data
Capture (FFDC) output similar to the following example:
Exception = com.ibm.wsspi.channel.framework.exception.RetryableChannelException
Source = com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.startChainInternal
probeid = 2577
Stack Dump = com.ibm.wsspi.channel.framework.exception.RetryableChannelException:
An exception was thrown when attempting to start the TCPProxyChannel
at com.ibm.ws.tcpchannelproxy.jfap.impl.TCPProxyInboundChannel.
start(TCPProxyInboundChannel.java:153)
at com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.
startChannelInChain(ChannelFrameworkImpl.java:1410)
at com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.
startChainInternal(ChannelFrameworkImpl.java:2863)
at com.ibm.ws.channel.framework.impl.WSChannelFrameworkImpl.
startChainInternal(WSChannelFrameworkImpl.java:960)
at com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.
startChainInternal(ChannelFrameworkImpl.java:2794)
at com.ibm.ws.channel.framework.impl.ChannelFrameworkImpl.
startChain(ChannelFrameworkImpl.java:2779)
at com.ibm.ws.runtime.component.ChannelFrameworkServiceImpl.
startChain(ChannelFrameworkServiceImpl.java:666)
at com.ibm.ws.sib.jfapchannel.framework.impl.ChannelFrameworkReference$TCPProxy
BridgeServiceInboundChainStartupRunnable.run(ChannelFrameworkReference.java:1641)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
Caused by: com.ibm.ws.tcpchannelproxy.jfap.NotYetInitializedException:
Server is not yet initialized
at com.ibm.ws.tcpchannelproxy.jfap.TCPProxyBridgeServicesImpl.
startListening(TCPProxyBridgeServicesImpl.java:558)
at com.ibm.ws.tcpchannelproxy.jfap.impl.TCPProxyInboundChannel.
start(TCPProxyInboundChannel.java:131)
... 8 more
Eventually the following message should
be displayed indicating that the z/OS TCP
proxy channel has started up correctly:
Trace: 2009/06/17 08:24:51.449 01 t=9C6B58 c=UNK key=P8 (13007002)
ThreadId: 00000003
FunctionName: com.ibm.ws.channel.framework.impl.WSChannelFrameworkImpl
SourceId: com.ibm.ws.channel.framework.impl.WSChannelFrameworkImpl
Category: AUDIT
ExtendedMessage: BBOO0222I: CHFW0019I: The Transport Channel Service has started
chain _InboundTCPProxyBridgeService.