Tips for troubleshooting your WS-ReliableMessaging configuration.
To help you identify and resolve problems with WS-ReliableMessaging,
you can use the TCP/IP monitor to view the messages that are flowing between
your client applications and reliable messaging enabled Web services. You
can also use the WebSphere Application Server trace and logging facilities
as described in
Tracing
and logging configuration
Setting up component trace (CTRACE).
org.apache.sandesha2*=all=enabled:com.ibm.ws.websvcs.rm*=all=enabled:org.apache.axis2*=all=enabled:com.ibm.ws.sib.wsrm*=all=enabled
org.apache.sandesha2*=all=enabled:com.ibm.ws.websvcs.rm*=all=enabled:org.apache.axis2*=all=enabled
A list of the main known restrictions that apply when using WS-ReliableMessaging is provided in WS-ReliableMessaging known restrictions.
WebSphere Application Server system messages are logged from a variety of sources, including application server components and applications. Messages logged by application server components and associated IBM products start with a unique message identifier that indicates the component or application that issued the message. The prefix for the WS-ReliableMessaging component is CWSKA.
The Troubleshooter reference: Messages topic contains information about all WebSphere Application Server messages, indexed by message prefix. For each message there is an explanation of the problem, and details of any action that you can take to resolve the problem.
If you are migrating from Version 6.1.0.9 or 6.1.0.11 of the Feature Pack for Web Services, and your configuration includes WS-ReliableMessaging configured for the managed persistent quality of service, you need to remove all persisted messages before you migrate.
CWSIT0019E: No suitable messaging engine is available on bus yourBus that matched the specified connection propertiesIn a network deployment environment, this can occur because the messaging engine is on an application server or cluster member that has started later than the server that hosts your reliable messaging application. In this case you need do nothing but wait; reliable messaging will keep trying to connect until the messaging engine becomes available.
If your client application is unable to invoke a reliable messaging enabled Web service, you can use the TCP-IP monitor to view the messages that are flowing between the client and the service. You should also check the following:
After a sequence has been established, WS-ReliableMessaging provides retransmission of messages to a service. However if the sequence is not established then the messages are not transmitted to the service and a message similar to the following example is displayed:
org.apache.axis2.AxisFault: The Create Sequence request has been refused by the RM Destination
The initial createSequence message has been refused. This is propagated back, and causes the client to fail. For information about CreateSequence and CreateSequenceRefused, see the WS-ReliableMessaging: supported specifications and standards.
You might also see a subsequent message to help explain why the request has been refused. For example:
Caused by: javax.xml.ws.soap.SOAPFaultException: com.ibm.ws.sib.wsrm.exceptions.WSRMRuntimeException: CWSJZ0202I: A messaging engine connection is unavailable for bus myBus.
If you get an exception like the following exception, then the sequence is established but cannot be used:
javax.xml.ws.WebServiceException: org.apache.axis2.AxisFault: The value of wsrm:Identifier is not a known Sequence identifier.
The most common reason is that you are working in a clustered environment but your server-side policy set specifies the unmanaged non-persistent quality of service.
For further checks that might help you resolve the problem, see also the troubleshooting tips A sequence is not established, and therefore WS-ReliableMessaging cannot ensure messages are transmitted and A client application is unable to invoke a reliable messaging enabled Web service.
If your policy set specifies a managed quality of service, but you have not specified a binding to a messaging engine to support that quality of service, you get the following exception message:
CWSKA0102E: The managed Web services reliable messaging storage manager could not be initialized because the policy set binding was incomplete or invalid.
Perhaps you have attached a managed policy set to your application, and used the default bindings (which do not support the managed qualities of service). You need to create a new binding for your application that specifies a service integration bus and messaging engine to support the managed qualities of service. To do this, see Attaching and binding a WS-ReliableMessaging policy set to a Web service application using the administrative console.
To remove the possibility of losing messages in this way, include in your client application a call to the waitUntilSequenceCompleted method on the sequenceManager, as described in Example: Code for waiting for a sequence to complete. This ensures that reliable messaging finishes sending its messages before the client application exits the JVM.
Clustering offers maximum protection against servers becoming unavailable. It provides highly available service endpoints, and (through the service integration bus) high availability of the reliable messaging layer.
For more information about configuring high availability for Web services and messaging engines, see Balancing workloads with clusters and Adding a messaging engine to a cluster.
When many applications use the same messaging engine, it can impact performance and in some cases lead to timeout errors. In order to make the reliable message application environment more scalable in a cluster, increase the number of messaging engines associated with the cluster.
For more information about configuring high availability for Web services and messaging engines, see Balancing workloads with clusters and Adding a messaging engine to a cluster.
When the reliable messaging layer receives a request message, it sends an acknowledgement then delivers the message to the target service. There is a marginal possibility that the server hosting the reliable messaging layer could become unavailable after the request message has been acknowledged and before it has been delivered. In this case, the message is only recovered if you are using in-order delivery as well as managed persistent quality of service. To specify in-order delivery, select the WS-ReliableMessaging policy option to "Deliver messages in the order that they were sent" as described in Configuring the WS-ReliableMessaging policy.
CWWSS7215E: Cannot get valid security context token from the cache.
To ensure that the scoping security context token does not expire before WS-ReliableMessaging can recover and resend its messages, complete the following task: Configuring WS-SecureConversation to work with WS-ReliableMessaging.
There is a limit to the number of open sequences a single client can support in a single JVM at one time. This limit depends on system resources. To avoid reaching the limit, use a single sequence within the client to maintain conversational state between the reliable messaging client and service. If you need to use multiple sequences from the same client, program your application to use the WS-ReliableMessaging SPI to actively close down sequences that have finished their lifecycle. For more information about how to do this, see Controlling WS-ReliableMessaging sequences programmatically.