WS-ReliableMessaging troubleshooting tips

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.

To enable trace for WS-ReliableMessaging, set the application server trace string as follows:
  • For either of the managed qualities of service:
    org.apache.sandesha2*=all=enabled:com.ibm.ws.websvcs.rm*=all=enabled:org.apache.axis2*=all=enabled:com.ibm.ws.sib.wsrm*=all=enabled
  • For the Unmanaged Non-Persistent quality of service:
    org.apache.sandesha2*=all=enabled:com.ibm.ws.websvcs.rm*=all=enabled:org.apache.axis2*=all=enabled
If you encounter a problem that you think might be related to WS-ReliableMessaging, you can check for error messages in the WebSphere Application Server administrative console, and in the application server SystemOut.log file. You can also enable the application server debug trace to provide a detailed exception dump.

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.

When you examine the runtime state of inbound or outbound sequences you might see more sequences than you expect, due to sequence reallocation

If a sequence is reallocated, the original and new sequences are both visible. Ignore the multiple entries.

If reliable messaging is running on a cluster, when you examine the runtime state of inbound or outbound sequences you see multiple entries for each sequence

This is because, although reliable messaging only binds to one messaging engine in a cluster, the runtime panel is calculating and displaying the sequence information once for every cluster member. Ignore the duplicate entries. Note that the slight differences in the statistics being displayed for each duplicate entry is due to the entries being created sequentially, while polling for messages continues.

You get runtime errors when you migrate persisted WS-ReliableMessaging messages from Version 6.1.0.9 or 6.1.0.11 of the Feature Pack for Web Services to a later version of the product

If you are migrating from WebSphere Application Server Version 6.1, and you are using 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.

Each message is persisted as part of a sequence that is currently being processed. To remove all persisted messages, use the administrative console to complete the following steps:
  1. Navigate to the Inbound sequence collection runtime panel for your reliable messaging application.
  2. Select all the inbound sequences, then click delete sequence and messages to delete the sequences.
  3. Navigate to the Outbound sequence collection runtime panel, then repeat the previous steps for the outbound sequences.

When an application server starts, a messaging engine used for reliable messaging is reported as unavailable

When you use reliable messaging with a managed quality of service, you might see the following exception message when your application server starts:

CWSIT0019E: No suitable messaging engine is available on bus yourBus that matched the specified connection properties
If you suspect there is an underlying problem, for example the bindings are incorrect or the server that hosts the messaging engine is not going to start, complete the following checks:
  • Check that the specified messaging engine and service integration bus exist.
  • Check the system out log to ensure that the server that hosts the messaging engine has started.

A client application is unable to invoke a reliable messaging enabled Web service

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:

A sequence is not established, and therefore WS-ReliableMessaging cannot ensure messages are transmitted

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.
There is a problem with your reliable messaging configuration. Complete the following checks:
  • Check that the policy sets are correctly applied. Specifically, check that the destination has reliable messaging correctly enabled.
  • Check the logs for server-side problems.
  • For the managed persistent quality of service, check that the associated messaging engine is available.

A sequence is established but cannot be used, and therefore WS-ReliableMessaging cannot ensure messages are transmitted

If you get an exception such as 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 reliable messaging managed store is not initialized because the policy set binding is not complete or not valid

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 must 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 by using the administrative console.

A message is not recovered after a server becomes unavailable, even with the managed persistent quality of service

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

Note: There is a performance overhead in using in-order delivery, because messages are held in a queue until they can be delivered in order. However, where the highest level of reliability is required, you should always specify in-order delivery in conjunction with the managed persistent quality of service.

When using reliable messaging with a persistent WS-I RSP profile and WS-SecureConversation, an exception message states that the security context token is not valid

When you use a persistent WS-I RSP policy set, which includes WS-SecureConversation, if the scoping security context token is expired when the server is restarted then WS-ReliableMessaging cannot resend its messages and system messages are written to the log file stating that the reliable messaging sequence was not secured using the correct security token. For example:
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.

Out-of-memory errors occur when you are using in-order delivery in a highly available environment

There is a performance overhead in using in-order delivery, because messages are held in a queue until they can be delivered in order. In some situations, messages can build up in the queue until an out-of-memory error occurs. If a client is sending messages to the server, but not receiving responses, you can configure the client to stop sending messages until the server recovers, preventing the build up of messages on the server. You can also tune your system to increase the heap size of the JVM, which can help to avoid out-of-memory errors.

However, where the highest level of reliability is required, you should always specify in-order delivery in conjunction with the managed persistent quality of service.

[Fix Pack 5 or later] The performance overhead is greatly reduced; you should not have to tune your system to reduce its effect, although you might want to tune your system for other purposes. You are unlikely to see out-of-memory errors resulting from the use of in-order delivery.




Subtopics
WS-ReliableMessaging known restrictions
Related tasks
Configuring WS-SecureConversation to work with WS-ReliableMessaging
Learning about WS-ReliableMessaging
Attaching and binding a WS-ReliableMessaging policy set to a Web service application by using the administrative console
Attaching and binding a WS-ReliableMessaging policy set to a Web service application by using the wsadmin tool
Tuning Web services reliable messaging applications
Detecting and fixing problems with WS-ReliableMessaging
Related information
WS-ReliableMessaging sequence reallocation
Reference topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 1:44:59 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-express-dist&topic=rwbs_wsrm_prob0
File name: rwbs_wsrm_prob0.html