Posts Tagged ‘Mule’

Abstract

The application I work on packages Mule ESB 2.2.1 in a WAR and deploys it under a WebLogic 10.3 server. My team mates and I noticed that, on multiple deploy/undeploy cycles, the PermGen size dramatically decreased. The cause of this was the number of threads, which hardly decreased on undeployment phases, unlike the expected behaviour.
Indeed, Mule is seldom deployed as a WebApp. Rather, it is designed to be run as a standalone application, within a Tanuki wrapper. When the JVM is killed, all the threads are killed, too, and therefore no thread survives ; hence, the memory is freed and there is no reason to fear a thread leak.

Moreover, when the application is redeployed, new threads -with the same names as the “old” threads- are created. The risk is that, for any reason, a thread-name-based communication between threads may fail, because the communication pipe may be read by the wrong thread.

In my case: on WebLogic startup, there are 31 threads ; when the application is deployed, there are 150 ; when the application works (receives and handles messages), the number of threads climbs to 800 ; when the application is undeployed, only 12 threads are killed, the other remaining alive.

The question is: how to kill Mule-created threads, in order to avoid a Thread leak?

WebLogic Threads

I performed a thread dump at WebLogic startup. Here are WebLogic threads, created before any deployment occurs:

[java]Attach Listener
DoSManager
DynamicListenThread[Default[1]]
DynamicListenThread[Default]
ExecuteThread: ‘0’ for queue: ‘weblogic.socket.Muxer’
ExecuteThread: ‘1’ for queue: ‘weblogic.socket.Muxer’
ExecuteThread: ‘2’ for queue: ‘weblogic.socket.Muxer’
Finalizer
JMX server connection timeout 42
RMI Scheduler(0)
RMI TCP Accept-0
RMI TCP Connection(1)-127.0.0.1
RMI TCP Connection(2)-127.0.0.1
Reference Handler
Signal Dispatcher
Thread-10
Thread-11
Timer-0
Timer-1
VDE Transaction Processor Thread
[ACTIVE] ExecuteThread: ‘0’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[ACTIVE] ExecuteThread: ‘2’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘1’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘3’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘4’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘5’ for queue: ‘weblogic.kernel.Default (self-tuning)’
main
weblogic.GCMonitor
weblogic.cluster.MessageReceiver
weblogic.time.TimeEventGenerator
weblogic.timers.TimerThread
[/java]

Dispose Disposables, Stop Stoppables…

The application being deployed in a WAR, I created a servlet implementing ServletContextListener. In the method contextDestroyed(), I destroy Mule objects (Disposable, Stoppable, Model, Service, etc.) one per one.
Eg#1:

[java] final Collection<Model> allModels;
try {
allModels = MuleServer.getMuleContext().getRegistry().lookupObjects(Model.class);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Disposing models " + allModels.size());
}
for (Model model : allModels) {
model.dispose();
}
allModels.clear();
} catch (Exception e) {
LOGGER.error(e);
}[/java]

Eg#2:

[java] private void stopStoppables() {
final Collection<Stoppable> allStoppables;
try {
allStoppables = MuleServer.getMuleContext().getRegistry().lookupObjects(Stoppable.class);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Stopping stoppables " + allStoppables.size());
}
for (Stoppable stoppable : allStoppables) {
stoppable.stop();
}
allStoppables.clear();
} catch (MuleException e) {
LOGGER.error(e);
}
}[/java]

This first step is needed because default mechanism is flawed: Mule re-creates objects that were destroyed.

Kill Threads

The general idea to kill Mule threads is the following: perform a Unix-style “diff” between WebLogic native threads, and the threads still alive once all Mule objects have been stopped and disposed.

On Application Startup

In the ServletContextListener, I add a field that will be set in a method called in the constructor:
[java] private List<String> threadsAtStartup;
(…)
/**
* This method retrieves the Threads present at startup: mainly speaking, they are Threads related to WebLogic.
*/
private void retrieveThreadsOnStartup() {
final Thread[] threads;
final ThreadGroup threadGroup;
threadGroup = Thread.currentThread().getThreadGroup();
try {
threads = retrieveCurrentActiveThreads(threadGroup);
} catch (NoSuchFieldException e) {
LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
threadsAtStartup = new ArrayList<String>();
return;
} catch (IllegalAccessException e) {
LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
threadsAtStartup = new ArrayList<String>();
return;
}

threadsAtStartup = new ArrayList<String>(threads.length);
for (int i = 0; i < threads.length; i++) {
final Thread thread;
try {
thread = threads[i];
if (null != thread) {
threadsAtStartup.add(thread.getName());
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("This Thread was available at startup: " + thread.getName());
}
}
} catch (RuntimeException e) {
LOGGER.error("An error occured on initial Thread statement: ", e);
}
}
}
/**
* Hack to retrieve the field ThreadGroup.threads, which is package-protected and therefore not accessible
*
* @param threadGroup
* @return
* @throws NoSuchFieldException
* @throws IllegalAccessException
*/
private Thread[] retrieveCurrentActiveThreads(ThreadGroup threadGroup) throws NoSuchFieldException, IllegalAccessException {
final Thread[] threads;
final Field privateThreadsField;
privateThreadsField = ThreadGroup.class.getDeclaredField("threads");
privateThreadsField.setAccessible(true);

threads = (Thread[]) privateThreadsField.get(threadGroup);
return threads;
}
[/java]

On application shutdown

In the method ServletContextListener.contextDestroyed(), let’s call this method:
[java] /**
* Cleanses the Threads on shutdown: theorically, when the WebApp is undeployed, should remain only the threads
* that were present before the WAR was deployed. Unfornately, Mule leaves alive many threads on shutdown, reducing
* PermGen size and recreating new threads with the same names as the old ones, inducing a kind of instability.
*/
private void cleanseThreadsOnShutdown() {
final Thread[] threads;
final ThreadGroup threadGroup;
final String currentThreadName;

currentThreadName = Thread.currentThread().getName();

if (LOGGER.isDebugEnabled()) {
LOGGER.debug("On shutdown, currentThreadName is: " + currentThreadName);
}

threadGroup = Thread.currentThread().getThreadGroup();
try {
threads = retrieveCurrentActiveThreads(threadGroup);
} catch (NoSuchFieldException e) {
LOGGER.error("An error occured on Threads cleaning at shutdown", e);
return;
} catch (IllegalAccessException e) {
LOGGER.error("An error occured on Threads cleaning at shutdown", e);
return;
}

for (Thread thread : threads) {
final String threadName = thread.getName();
final Boolean shouldThisThreadBeKilled;

shouldThisThreadBeKilled = isThisThreadToBeKilled(currentThreadName, threadName);
if (LOGGER.isDebugEnabled()) {
LOGGER.info("should the thread named " + threadName + " be killed? " + shouldThisThreadBeKilled);
}
if (shouldThisThreadBeKilled) {
thread.interrupt();
thread = null;
}
}

}

/**
* Says whether a thread is to be killed<br/>
* Rules:
* <ul><li>a Thread must NOT be killed if:</li>
* <ol>
* <li>it was among the threads available at startup</li>
* <li>it is a Thread belonging to WebLogic (normally, WebLogic threads are among the list in the previous case</li>
* <li>it is the current Thread (simple protection against unlikely situation)</li>
* </ol>
* <li>a Thread must be killed: in all other cases</li>
* </ul>
*
* @param currentThreadName
* @param threadName
* @return
*/
private Boolean isThisThreadToBeKilled(String currentThreadName, String threadName) {
final Boolean toBeKilled;
toBeKilled = !threadsAtStartup.contains(threadName)
&amp;&amp; !StringUtils.contains(threadName, "weblogic")
&amp;&amp; !threadName.equalsIgnoreCase(currentThreadName);
return toBeKilled;
}
[/java]

EhCache

My application uses an EhCache. Its threads names usually end with “.data”. They are not killed by the previous actions. To get rid of them, the most elegant way is to add this block in the web.xml:
[xml] <listener>
<listener-class>net.sf.ehcache.constructs.web.ShutdownListener</listener-class>
</listener>
[/xml]
cf EhCache documentation

With all these operations, almost all threads are killed. But Java VisualVM still displays 34, vs. 31 at startup.

Tough Threads

A thread dump confirms that, at this point, 3 rebellious threads still refuse to be kill:
[java]MuleServer.1
SocketTimeoutMonitor-Monitor.1
SocketTimeoutMonitor-Monitor.1
[/java]
Let’s examine them:

• MuleServer.1: This thread is an instance of the inner class MuleServer.ShutdownThread. Indeed, this is the first thread created by Mule, and therefore appears among the threads available at startup, before the ServletContextListener is called… I did not succeed in killing it, even why trying to kill it namely, which makes sense: killing the father thread looks like suiciding the ServletContextListener.
• SocketTimeoutMonitor-Monitor.1: This thread is created by Mule’s TcpConnector and its daughter classes: HttpConnector, SslConnector, etc. Again, I could not kill them.

Conclusion

We have seen Mule suffers of major thread leaks when deployed as a WAR. Anyway, most of these leaks may be sealed.
I assume MuleSoft was aware of this issue: in the version 3 of Mule, the deployment of webapps was refactored.

Case

You have to deliver Mule 2.2.1 as a standalone application, or, more accurately, as a simple archive ready-to-use by someone else (customer, co-team worker, etc.).

In this tutorial, we assume that:

• you have to include external jars, eg. MQ and WebLogic jars
• you have written your XML configuration file for Mule, of which all properties are externalized in an external property file. We don’t mind the actual workflow, we assume you’re skilled enough with Mule 😉

Build

Prerequisites

Prior to building standalone:

• get Mule ESB 2.2.1 standalone archive, available on MuleSoft website
• get the JARs needed by MQ
  • providerutil.jar
  • fscontext.jar
  • dhbcore.jar
  • connector.jar
  • commonservices.jar
  • com.ibm.mqjms.jar
  • com.ibm.mq.jar
• get WebLogic’s wlfullclient.jar
• install the zip and the jars on your local repository:

  mvn install:install-file -DgroupId=org.mulesource -DartifactId=mule-esb -Dversion=2.2.1 -Dpackaging=zip -Dfile=mule-standalone-2.2.1.zip
  mvn install:install-file -Dfile=wlfullclient.jar  -DgroupId=weblogic -DartifactId=wlfullclient -Dversion=10.3 -Dpackaging=jar -DgeneratePom=true
  mvn install:install-file -Dfile=fscontext.jar  -DgroupId=fscontext -DartifactId=fscontext -Dversion=1.2 -Dpackaging=jar -DgeneratePom=true
  mvn install:install-file -Dfile=providerutil.jar  -DgroupId=fscontext -DartifactId=providerutil -Dversion=1.2 -Dpackaging=jar -DgeneratePom=true
  mvn install:install-file -DgroupId=mq -DartifactId=com.ibm.mq -Dversion=6.0.2.0 -Dpackaging=jar -Dfile=com.ibm.mq.jar
  mvn install:install-file -DgroupId=mq -DartifactId=com.ibm.mqjms -Dversion=6.0.2.0 -Dpackaging=jar -Dfile=com.ibm.mqjms.jar
  mvn install:install-file -DgroupId=mq -DartifactId=dhbcore -Dversion=6.0.2.0 -Dpackaging=jar -Dfile=dhbcore.jar
  mvn install:install-file -DgroupId=mq -DartifactId=commonservices -Dversion=6.0.2.0 -Dpackaging=jar -Dfile=commonservices.jar
  mvn install:install-file -DgroupId=connector -DartifactId=connector -Dversion=1.0 -Dpackaging=jar -Dfile=connector.jar

Files to be edited

• Create a mule-jonathan.xml file in src/main/resources/ folder.
• Externalize all properties in mule-jonathan.properties file in src/main/resources/ folder. As you may anticipate it, you will have add this property file in Mule classpath
• To perform that:
  • Copy the wrapper.conf of Mule standalone archive as src/main/resources/wrapper.conf
  • After the line:[java]wrapper.java.classpath.3=%MULE_HOME%/lib/boot/*.jar[/java]

    , add the line:

    [java]wrapper.java.classpath.4=%MULE_HOME%/etc[/java]

• in src/main/resources/, create a file start-mule-jonathan.bat, with the content:[java]
  set MULE_HOME=%CD%
  cd %MULE_HOME%\bin
  mule.bat -config mule-jonathan.xml
  [/java]

Maven

Here is the pom.xml of our project:

[xml]
<?xml version="1.0"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<groupId>lalou-jonathan</groupId>
<artifactId>jonathan-parent</artifactId>
<version>1.0</version></parent>
<modelVersion>4.0.0</modelVersion>
<groupId>lalou.jonathan</groupId>
<artifactId>jonathan-lalou-standalone-esb</artifactId>
<packaging>jar</packaging>
<version>${jonathan.version}</version>
<name>jonathan-lalou-standalone-esb</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>org.mulesource</groupId>
<artifactId>mule-esb</artifactId>
<version>2.2.1</version>
<type>zip</type></dependency>
<dependency>
<groupId>weblogic</groupId>
<artifactId>wlfullclient</artifactId>
<version>10.3</version></dependency>
<dependency>
<groupId>fscontext</groupId>
<artifactId>fscontext</artifactId>
<version>1.2</version></dependency>
<dependency>
<groupId>fscontext</groupId>
<artifactId>providerutil</artifactId>
<version>1.2</version></dependency>
<dependency>
<groupId>mq</groupId>
<artifactId>com.ibm.mq</artifactId>
<version>6.0.2.0</version></dependency>
<dependency>
<groupId>mq</groupId>
<artifactId>com.ibm.mqjms</artifactId>
<version>6.0.2.0</version></dependency>
<dependency>
<groupId>mq</groupId>
<artifactId>commonservices</artifactId>
<version>6.0.2.0</version></dependency>
<dependency>
<groupId>mq</groupId>
<artifactId>dhbcore</artifactId>
<version>6.0.2.0</version></dependency>
<dependency>
<groupId>connector</groupId>
<artifactId>connector</artifactId>
<version>1.0</version></dependency></dependencies>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>**/*</exclude></excludes></resource></resources>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-2</version>
<configuration>
<descriptors>
<descriptor>src/main/assembly/assembly.xml</descriptor></descriptors></configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

[/xml]

Maven Assembly

We will use Maven Assembly: this plugin allows unpack archives, copy files, insert files, delete folders, etc.

Here is the assembly.xml file that should be located in src/main/assembly/ folder of your project. The code is commented so that you understand what we do.

[xml]
<assembly xmlns="http://maven.apache.org/xsd/1.1.0/assembly" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/xsd/assembly-1.1.2.xsd http://maven.apache.org/xsd/1.1.2/assembly">
<id/>
<baseDirectory>jonathan-lalou-standalone-esb-${version}</baseDirectory>
<formats>
<format>zip</format></formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<outputDirectory>/</outputDirectory>
<includes>
<include>org.mulesource:mule-esb</include></includes>
<unpack>true</unpack>
<unpackOptions>
<excludes>
<!– excluse original wrapper.conf, to include our tuned wrapper.conf–>
<exclude>**/conf/wrapper.conf</exclude>
<!–remove the these folders, useless in a standalone client–>
<exclude>**/examples/**</exclude>
<exclude>**/docs/**</exclude>
<exclude>**/src/**</exclude></excludes></unpackOptions></dependencySet>
<dependencySet>
<outputDirectory>mule-standalone-2.2.1/lib/user</outputDirectory>
<excludes>
<exclude>org.mulesource:mule-esb</exclude></excludes></dependencySet></dependencySets>
<fileSets>
<fileSet>
<directory>${basedir}/src/main/resources</directory>
<outputDirectory>/mule-standalone-2.2.1/etc</outputDirectory>
<includes>
<!–include the property file –>
<include>**/*jonathan*.properties</include></includes></fileSet>
<fileSet>
<directory>${basedir}/src/main/resources</directory>
<outputDirectory>/mule-standalone-2.2.1/bin</outputDirectory>
<includes>
<!– include Mule XML config file–>
<include>**/*jonathan*.xml</include></includes></fileSet>
<fileSet>
<directory>${basedir}/src/main/resources</directory>
<outputDirectory>/mule-standalone-2.2.1/conf</outputDirectory>
<includes>
<!– modified wrapper.conf to stake in account the etc/ folder, containing the property file–>
<include>**/wrapper.conf</include></includes></fileSet>
<fileSet>
<directory>${basedir}/src/main/resources</directory>
<outputDirectory>/mule-standalone-2.2.1/</outputDirectory>
<includes>
<include>**/*-mule-jonathan.bat</include>
</includes>
</fileSet>
</fileSets>
</assembly>

[/xml]

Build process

To build go to the folder yourproject/jonathan, then launch a mvn clean install. A complete installation package is output on target folder: jonathan-lalou-standalone-esb-1.0.zip.

The archive is built thanks to Maven Assembly plugin.

Install

Install

Copy or move the archive jonathan-lalou-standalone-esb-1.0.zip to any folder of your choice. Then unzip it.

(optionnal) Checks

Tree

Here is a tree of the installation, with some important file that must appear:

+---start-mule-jonathan.bat
+---bin
¦   +---mule-jonathan.xml
+---conf
¦   +---wrapper.conf
+---etc
¦   +---mule-jonathan.properties
+---lib
¦   +---boot
¦   ¦   +---exec
¦   +---endorsed
¦   +---mule
¦   +---opt
¦   +---user
¦       +------com.ibm.mq-6.0.2.0.jar
¦       +------com.ibm.mqjms-6.0.2.0.jar
¦       +------commonservices-6.0.2.0.jar
¦       +------connector-1.0.jar
¦       +------dhbcore-6.0.2.0.jar
¦       +------fscontext-1.2.jar
¦       +------providerutil-1.2.jar
¦       +------wlfullclient-10.3.jar
¦       +------connector-1.0.jar
+---licenses
+---logs

Files

Check the files listed above in the tree appear. Besides, check the conf/wrapper.conf file contains the line wrapper.java.classpath.4=%MULE_HOME%/etc

Config

Edit etc/mule-jonathan.properties file and set the right properties.

Use

Execute start-mule-jonathan.bat to launch Mule on Windows. On first attempt, Mule will display the user licence and ask you your confirmation you accept the terms of the agreement.

Case

In a Mule ESB workflow, the endpoint is a <jms:outbound-endpoint>, pointing to a JMS queue hosted on MQ Series and accessed through WebLogic 10.3.3.

I get the following stracktrace

[java]Exception stack is:
1. MQJE001: Completion Code 2, Reason 2027 (com.ibm.mq.MQException)
com.ibm.mq.MQQueue:1624 (null)
2. MQJMS2007: failed to send message to MQ queue(JMS Code: MQJMS2007) (javax.jms.JMSException)
com.ibm.mq.jms.services.ConfigEnvironment:622 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/JMSException.html)
3. Failed to create and dispatch response event over Jms destination "queue://MQSERVER/AMQ.4C8A5E112285475605?persistence=1". Failed to route event via endpoint: null. Message payload is of type: JMSObjectMessage (org.mule.api.transport.DispatchException)
org.mule.transport.jms.JmsReplyToHandler:154 (http://www.mulesource.org/docs/site/current2/apidocs/org/mule/api/transport/DispatchException.html)[/java]

Fix

On Mule config file, explicitly set the attribute disableTemporaryReplyToDestinations at true in the JMS outbound tag:

[xml]<jms:outbound-endpoint
queue="jonathan.lalou.jms.queue"
connector-ref="jmsConnector"
transformer-refs="foo" disableTemporaryReplyToDestinations="true"/>[/xml]

This short tutorial is aimed at showing the main steps allowing to deploy a WebService, using CXF framework, under a Mule ESB instance.

Java code

Declare an interface:

[java]@WebService
public interface BasicExampleServices {
@WebResult(name = "myReturnedInteger")
Integer getInteger(@WebParam(name="myInteger") Integer myInteger);
}[/java]

Implement this interface:

[java]@WebService(endpointInterface = "com.lalou.jonathan.services.BasicExampleServices", serviceName = "basicExampleServices")
public class WSBasicExampleServices implements BasicExampleServices {

public Integer getInteger(Integer param) {
return 12345;
}
}[/java]

XML files

Create a Spring config file ws-basicExample.xml:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

<bean id="basicExampleService" scope="singleton"/>
</beans>[/xml]

Create a Mule configuration file ws-basicExample-config.xml:

[xml]<?xml version="1.0" encoding="UTF-8" ?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:management="http://www.mulesource.org/schema/mule/management/2.2"
xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
xmlns:cxf="http://www.mulesource.org/schema/mule/cxf/2.2"
xmlns:jetty="http://www.mulesource.org/schema/mule/jetty/2.2"
xsi:schemaLocation="http://www.mulesource.org/schema/mule/management/2.2
http://www.mulesource.org/schema/mule/management/2.2/mule-management.xsd
http://www.mulesource.org/schema/mule/core/2.2
http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.mulesource.org/schema/mule/vm/2.2
http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
http://www.mulesource.org/schema/mule/cxf/2.2
http://www.mulesource.org/schema/mule/cxf/2.2/mule-cxf.xsd
http://www.mulesource.org/schema/mule/stdio/2.2
http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd">

<spring:beans>
<spring:import resource="ws-basicExample.xml"/>
</spring:beans>

<model name="wsBasicExampleModel">
<service name="wsBasicExampleService">
<inbound>
<cxf:inbound-endpoint address="http://localhost:8282/services/basicExampleServices"/>
</inbound>
<component>
<spring-object bean="basicExampleService"/>
</component>
</service>
</model>
</mule>

[/xml]

Checks

• Run the Mule, pointing your config file.
• In your favorite webbrowser, open the URL:
  [xml]http://localhost:8282/services/basicExampleServices?wsdl[/xml]

The webservice contract is expected to be displayed.

• You can also execute a runtime test:

  [java]public class WSBasicExampleServicesRuntimeTest {

  private BasicExampleServices basicExampleServices;

  @Before
  public void setup() {
  JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
  factory.getInInterceptors().add(new LoggingInInterceptor());
  factory.getOutInterceptors().add(new LoggingOutInterceptor());
  factory.setServiceClass(BasicExampleServices.class);
  factory.setAddress("http://localhost:8282/services/basicExampleServices");
  basicExampleServices = (BasicExampleServices) factory.create();
  }

  @Test
  public void testGetInteger() {
  final Integer expectedAnswer = 12345;
  final Integer actualAnswer;
  final Integer param = 912354;

  actualAnswer = basicExampleServices.getInteger(param);

  assertNotNull(actualAnswer);
  assertEquals(expectedAnswer, actualAnswer);
  }

  }[/java]

Context

An object is marshallized and sent on TibcoRV 8.1. An instance of Mule ESB 2.2.1 listens to TibcoRV, reads the message, unmarshalls the object and builds an SQL insert query.

The query is very simple:

[sql]insert into myTable(dateColumn, stringColumn) values(…)[/sql]

It is executed in a Jdbc connector declared on Mule configuration file:

[xml] <jdbc:connector name="jdbcConnector" dataSource-ref="mySybaseDB" pollingFrequency="1000">
<jdbc:query key="writeTest"
value="INSERT INTO myTable(dateColumn, stringColumn)
VALUES(#[map-payload:myJavaDate],#[map-payload:myJavaString])"/>
</jdbc:connector>[/xml]

The DB is Sybase. The first column is of type datetime, the second one is varchar. The values are retrieved from a java.util.Date and a java.lang.String.

Case

When the query is run, I get the error:

[java]java.sql.SQLException: Cannot run this command because Java services are not enabled. A user with System Administrator (SA) role must reconfigure the system to enable Java.[/java]

(you may get a com.sybase.jdbc2.jdbc.SybSQLException instead of java.sql.SQLException)

Explanation – Fix

The error is related only to Sybase, and not to TibcoRV and Mule: by default, Sybase cannot manage Java Dates (java.util.Date). You have to start explicitly the Java services. To perform that:

• login with an username owing the rights “sa_role“
• run the SQL query: [sql]sp_configure ‘enable java’, 1[/sql]
• the restart the Sybase server

Now it should work. A similar error may occur with JBoss.

Case

You have to run a standalone Mule 2.2.1 in debug mode. Since Mule is launched in standalone, you have to debug a remote application.

Fix

Nice case

• Edit the %MULE_HOME%/conf/wrapper.conf
• Uncomment the line:

  wrapper.java.additional.<n>=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005

• Don’t forget to set the parameter <n>

Boring case

In my case (Windows XP SP2, Java 1.5), the Mule refused to start and freezed:

------------------------------------------------------------------------
The JVM is being launched with a debugger enabled and could possibly be
suspended.  To avoid unwanted shutdowns, timeouts will be disabled,
removing the ability to detect and restart frozen JVMs.
------------------------------------------------------------------------
Launching a JVM...
Listening for transport dt_socket at address: 5005
------------------------------------------------------------------------
Startup: Timed out waiting for a signal from the JVM.
The JVM was launched with debug options so this may be because the JVM
is currently suspended by a debugger.  Any future timeouts during this
JVM invocation will be silently ignored.
------------------------------------------------------------------------

The fix this:

• Download the jar spring-agent here.
• Move it into %MULE_HOME%/lib/user/
• Edit the %MULE_HOME%/conf/wrapper.conf
• add the following block:

wrapper.java.additional.3=-javaagent:%MULE_HOME%\lib\user\spring-agent-2.5.3.jar
wrapper.java.additional.4=-Xdebug
wrapper.java.additional.5=-Xnoagent
wrapper.java.additional.6=-Djava.compiler=NONE
wrapper.java.additional.7=-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005

• (by the way, even though properties #3 and #5 are inconsistent, don’t mind)
• launch the Mule
• In your IDE (Eclipse, NetBeans, IntelliJ IDEA), run debug on localhost:5005

Context

Mule 2.2.1 ESB config file with a TibcoRV connector, under Windows XP SP2 and Java 5.
The error happened in this context, yet I assume it would occur in any occurence related to XSD / XML schemas.

Error

org.springframework.beans.factory.xml.XmlBeanDefinitionReader: Ignored XML validation warning
org.xml.sax.SAXParseException: SchemaLocation: schemaLocation value = 'http://www.mulesource.org/schema/mule/management/2.2                http://www.mulesource.org/schema/mule/management/2.2/mule-management.xsd                http://www.mulesource.org/schema/mule/core/2.2                http://www.mulesource.org/schema/mule/core/2.2/mule.xsd                http://www.springframework.org/schema/beans                http://www.springframework.org/schema/beans/spring-beans-2.5.xsd                http://www.mulesource.org/schema/mule/core/2.2/mule.xsd                http://www.mulesource.org/schema/mule/vm/2.2                http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
http://www.mulesource.org/schema/mule/tibcorv/2.2                http://www.mulesource.org/schema/mule/tibcorv/2.2/mule-tibcorv.xsd' must have even number of URI's.

Headers of XML config file:

[xml]<mule xmlns=&amp;quot;http://www.mulesource.org/schema/mule/core/2.2&amp;quot;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:management="http://www.mulesource.org/schema/mule/management/2.2"
xmlns:tibcorv="http://www.mulesource.org/schema/mule/tibcorv/2.2
xsi:schemaLocation="http://www.mulesource.org/schema/mule/management/2.2
http://www.mulesource.org/schema/mule/management/2.2/mule-management.xsd
http://www.mulesource.org/schema/mule/core/2.2
http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
http://www.mulesource.org/schema/mule/vm/2.2
http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
http://www.mulesource.org/schema/mule/tibcorv/2.2
http://www.mulesource.org/schema/mule/tibcorv/2.2/mule-tibcorv.xsd">[/xml]

Explanation – Fix

Each time, the attribute xsi:schemaLocation must have an even number of lines: a “public” XSD address and a “non-public” one. For non English-fluent speakers, I remind that a number is even if, and only if, it is a multiple of 2 ; otherwise it is odd.

In our case, one line is redundant. To fix this issue, you have to remove the redundant line, and ensure each line belongs to a consistent pair of lines: for instance:

http://www.mulesource.org/schema/mule/tibcorv/2.2
and
http://www.mulesource.org/schema/mule/tibcorv/2.2/mule-tibcorv.xsd

Stacktrace

TibrvException[error=901,message=Library not found: tibrvjsd]

and below:

java.lang.UnsatisfiedLinkError: no tibrvjsd in java.library.path

The error appears also with tibrv instead of tibrvjsd.

Context

Mule ESB 2.2.1 using TibcoRV 8.1.2, under Windows XP, with Java 1.5

Explanation – Fix

• Explanation:
  • the Mule tries to load a DLL, here tibrvjsd.dll. Its path should be available in the property java.library.path.
  • Unlike what may be found on the net, the right DLL cannot be found under
    %TIBRV_HOME%/lib, where only jars are available, not DLLs.

• Backup the file %MULE_HOME%/conf/wrapper.conf
• Edit it
• After the lines

[java]# Java Native Library Path (location of .DLL or .so files)
wrapper.java.library.path.1=%LD_LIBRARY_PATH%
wrapper.java.library.path.2=%MULE_HOME%/lib/boot[/java]

add the line:

[java]wrapper.java.library.path.3=%TIBRV_HOME%/bin[/java]

Installation

Prerequisites

Priori to following the current tutorial, you must have installed

• a Java JDK/JRE 1.5+, with a parameter JAVA_HOME already set
• a TibcoRV 8.1, with a parameter TIBRV_HOME already set. You can consult a short tutorial here to perform this.

Main

• Get Zip version of “Mule ESB Full Distribution”, version 2.2.1, on this page.
• Unzip the content in a folder, eg: C:\exe\mule-standalone-2.2.1
• Add a environment variable MULE_HOME and update your path, eg:

  set MULE_HOME=C:\win32app\mule-standalone-2.2.1
  set PATH=%PATH%;%MULE_HOME%\bin

• To check the Mule is well installed, you can launch the “Hello World” application:

  %MULE_HOME%\examples\hello\hello.bat

Specific for TibcoRV

• Get mule-transport-tibcorv-2.2.1.jar, available at this link.
• Copy it into %MULE_HOME%/lib/mule
• Get the jar %TIBRV_HOME%\lib\tibrv.jar
• Copy and rename it into %MULE_HOME%/lib/opt/tibrvj-8.1.2.jar
• Tip: to know the exact version of the Jar you have just copied, you can open it, explore and decompile the class com.tibco.tobrv.tibrvj_id. The exact version must appear.
• Copy %MULE_HOME%/conf/wrapper.conf as %MULE_HOME%/conf/wrapper.conf.old
• Edit %MULE_HOME%/conf/wrapper.conf:
  • replace

    wrapper.java.library.path.1=%LD_LIBRARY_PATH%
    wrapper.java.library.path.2=%MULE_HOME%/lib/boot

    with:

    wrapper.java.library.path.1=%LD_LIBRARY_PATH%
    wrapper.java.library.path.2=%MULE_HOME%/lib/boot
    wrapper.java.library.path.3=%TIBRV_HOME%/bin

Here is for the very configuration.

“Hello world” for “TibcoRV via Mule”

Configuration file for Mule/TibcoRV “Hello World”

Code below is commented. Save it into a file named mule-config.xml.

Run TibcoRV

Launch the daemon

Launch the daemon on localhost on port 7580:

%TIBRV_HOME\bin\rvd -http 7580

Launch a listener

Possibly, you can run a listener in a separate frame, in order to double check whether messages are sent and received in the right way, independantly of what happens on Mule side.
Listen to all messages with subject mySubject on localhost:7580

%TIBRV_HOME\bin\tibrvlisten.exe" -network localhost mySubject

Launch the Mule

• Now run the ESB:

  %MULE_HOME%\bin\mule.bat -config path\to\file\mule-config.xml

• Send a message:

  %TIBRV_HOME\bin\tibrvsend.exe -network 127.0.0.1  mySubject HelloWorld

• Expected outputs:
  • On sending frame:

    Publishing: subject=mySubject "HelloWorld"

  • On listening frame:

    tibrvlisten: Listening to subject mySubject
    2010-01-21 17:51:43 (2010-01-21 16:51:43.109000000Z): subject=mySubject, message={DATA="HelloWorld"}

  • On Mule ESB frame:

    INFO  2010-01-21 17:53:02,860 [Bus] org.mule.transport.tibrv.TibrvMessageReceiver: message received
    on: *
    INFO  2010-01-21 17:53:02,860 [fromTibco.4] org.mule.transport.tibrv.TibrvMessageAdapter: The newThreadCopy method in AbstractMessageAdapter is being used directly. This code may be susceptible to 'scribbling' issues with messages. Please consider implementing the ThreadSafeAccess interface in the message adapter.
    INFO  2010-01-21 17:53:02,860 [fromTibco.4] org.mule.component.simple.LogComponent:
    ********************************************************************************
    * Message received in service: fromTibco. Content is: '{                       *
    * DATA="HelloWorldOfTheWorld" }'                                               *
    ********************************************************************************
    INFO  2010-01-21 17:53:02,860 [connector.stdio.0.dispatcher.3] org.mule.transport.stdio.StdioMessageDispatcher: Connected: endpoint.outbound.stdio://OUT
    {DATA=HelloWorldOfTheWorld, __send__subject__=mySubject}