This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Abstract

This troubleshooting guide helps you resolve common problems encountered in JMS integration scenarios with WSO2 ESB.

Contents
Handling ClassNotFoundExceptions and NoClassDefFoundExceptions

Check if you have deployed all the required client libraries. The missing class should be available in one of the jar files deployed in <ESB HOME>/repository/components/lib directory.  

WSO2 ESB comes with geronimo-jms library, which contains the javax.jms packages. Therefore, you do not have to deploy them again.  

Back to Top ^


HTTP Header Conversion

When forwarding HTTP traffic to a JMS queue using WSO2 ESB, you might get an error similar to the one given below.  

ERROR JMSSender Error creating a JMS message from the axis message context
javax.jms.MessageFormatException: MQJMS1058: Invalid message property name: Content-Type
  

This exception is specific to the JMS broker used, and is thrown by the JMS client libraries used to connect with the JMS broker.
 
The incoming HTTP message contains a bunch of HTTP headers that have the ‘-‘ character. Some noticeable examples are Content-length and Transfer-encoding headers. When WSO2 ESB forwards a message over JMS, it sets the headers of the incoming message to the outgoing JMS message as JMS properties. But, according to the JMS specification, the ‘-‘ character is prohibited in JMS property names. Some JMS brokers like ActiveMQ do not check this specifically, in which case there will not be any issues. But some brokers do and they throw exceptions. 

The solution is to simply remove the problematic HTTP headers from the message before delivering it over JMS. You can use the property mediator as follows to achieve this:  

<property action="remove" name="Content-Length" scope="transport">
<property action="remove" name="Accept-Encoding" scope="transport">
<property action="remove" name="User-Agent" scope="transport">
<property action="remove" name="Content-Type" scope="transport"> 

Back to Top ^


JMS Property Data Type Mismatch

 When the ESB attempts to forward a message over JMS, there are instances that the client libraries throw an exception saying the data type of a particular message property is invalid.
 
This problem occurs when the developer uses the property mediator to manipulate property values set on the message. Certain implementations of JMS have data type restrictions on properties. But the property mediator always sets property values as strings.

The solution is to revise the mediation sequences and avoid manipulating property values containing non-string values. If you want to set a non-string property value, write a simple custom mediator. Instructions are given in section Creating Custom Mediators.  For an example, to set a property named foo with integer value 12345, use the property mediator as follows and set the type attribute to INTEGER. If the type attribute of the property is not specifically set, it will be assigned to String by default.  

<property name="foo" value="12345" type="INTEGER" scope="transport/"> 

Back to Top ^


Too-Many-Threads and Out-of-Memory Issues

 With some JMS brokers, WSO2 ESB tends to spawn new worker threads indefinitely until it runs out of memory and crashes. This problem is caused by a bug in the underlying Axis2 engine. A simple workaround to this problem is to engage the property mediator of the mediation sequence as follows:  

<property action="remove" name="transportNonBlocking" scope="axis2"> 

This prevents the ESB from creating new worker threads indefinitely. You can use a jconsole like JMX client to monitor the active threads and memory consumption of the ESB.

Back to Top ^

  • No labels