Mule

Hi, do you mean that the error is there in 2.0 ? What is the action you'd like taken?

I have already found out, that the memory leak in Mule 1.4.3 was caused by the class AbstractJmsTransformer because we transformed SOAP messages to Object.
When I took this class from Mule 1.4.4 Snapshot there is no memory leak any more in Mule 1.4.3. I checked this class also in Mule 2.0 RC3 and it looks also changed like in Mule 1.4.4, that's why I don't understand the memory leak in Mule 2.0 caused by my configuration.

I have tried my config with released Mule 2.0 and there is still the memory leak (I just want to metion one more time that this configuration causes memory leak also in Mule 1.4.3, but not in Mule 1.4.4 Snapshot, even not in Mule 1.5).

The action is:

1. soap message is sent on axis inbound endpoint by some client
2. transformation from soap message to jms message is done, because of ActiveMQ
3. message is sent to ActiveMQ

These actions are included in my config:

<custom-transformer name="SOAPEnvelopeToJMSMessage" class="ns.jms.transformers.SOAPEnvelopeToJMSMessage" />

<service name="P2PForwarderService">

<inbound>
<inbound-endpoint address="axis:http://163.242.48.228:8180/services" synchronous="true">
<soap:http-to-soap-request-transformer/>
<properties>
<spring:entry key="style" value="message"/>
<spring:entry key="use" value="literal"/>
</properties>
</inbound-endpoint>
</inbound>

<component class ="ns.service.umo.P2PForwarderService"/>

<outbound>
<outbound-pass-through-router>
<outbound-endpoint address="jms://queue.p2p.hlrfe1" connector-ref="activeMQConnector" synchronous="true"
transformer-refs="SOAPEnvelopeToJMSMessage">
<properties>
<spring:entry key="use" value="literal"/>
</properties>
</outbound-endpoint>
</outbound-pass-through-router>
</outbound>

</service>

This is the implementation of transformer SOAPEnvelopeToJMSMessage used in my configuration:

package ns.jms.transformers;

import javax.xml.soap.SOAPEnvelope;
import org.mule.transport.jms.transformers.ObjectToJMSMessage;
import org.mule.api.MuleMessage;
import org.mule.api.transformer.TransformerException;

public class SOAPEnvelopeToJMSMessage extends ObjectToJMSMessage
{
public SOAPEnvelopeToJMSMessage()

@Override
public Object transform (MuleMessage umoMess, String encoding) throws TransformerException
{
Object msgBeforeTransformation = null;
Object msgAfterTransformation = null;

msgBeforeTransformation = (Object) umoMess.getPayload ();

if (msgBeforeTransformation instanceof Object[] && ((Object[])msgBeforeTransformation).length > 0 && ((Object[])
msgBeforeTransformation)[0] instanceof SOAPEnvelope)
{
SOAPEnvelope envlp = (SOAPEnvelope) ((Object[])msgBeforeTransformation)[0];
if (envlp != null)
{
Object custSrc = envlp.toString();
umoMess.setPayload (custSrc);
if (custSrc != null)

}
}
if (msgAfterTransformation == null)

return msgAfterTransformation;
}
}

This is implementation of P2PForwarderService used in my configuration:

package ns.service.umo;

import javax.xml.soap.SOAPEnvelope;
import javax.xml.soap.SOAPException;
import org.mule.RequestContext;
import org.mule.api.MuleEventContext;
import org.mule.api.lifecycle.Callable;

public class P2PForwarderService implements Callable, P2PForwarderServiceInterface
{
public Object onCall(MuleEventContext context){ return context.getMessage(); }

public void forward (SOAPEnvelope request, SOAPEnvelope response) throws SOAPException { MuleEventContext ctx = RequestContext.getEventContext(); ctx.getMessage().setStringProperty("Final_endpoint","UMO2"); }
}

Any idea which changeset in the 1.4 branch (trunk) fixed this?

I have already mentioned that I have analyzed the memory leak in Mule 1.4.3 and when I took the class AbstractJmsTransformer from mule-transport-jms package of Mule 1.4.4 Snapshot and put it to mule-transport-jms package of Mule 1.4.3 - memory leak was not anymore there.

I made the prototype in Mule 2.0 where I put http inbound endpoint instead of axis:http inbound endpoint and the memory leak disappeared. It means that the memory leak rises somewhere by the transformation jms message.

Can you please provide the prototype here? This will help a lot in resolving this issue quickly.

My new config with http inbound endpoint:

<custom-transformer name="HttpToJMSMessage" class="ns.jms.transformers.HttpToJMSMessage"/>

<service name="P2PForwarderService">
<inbound>
<inbound-endpoint address="http://localhost:8180/services" synchronous="true">
</inbound-endpoint>
</inbound>

<component class="org.mule.component.simple.BridgeComponent"></component>

<outbound>
<outbound-pass-through-router>
<outbound-endpoint address="jms://queue.p2p.hlrfe1" connector-ref="activeMQConnector" synchronous="true"
transformer-refs="HttpToJMSMessage">
</outbound-endpoint>
</outbound-pass-through-router>
</outbound>

</service>

This is the implementation of transformer HttpToJMSMessage used in my configuration:

public class HttpToJMSMessage extends ObjectToJMSMessage
{
public HttpToJMSMessage()
{
super();
this.registerSourceType(Object.class);
}

public Object transform (MuleMessage umoMess, String encoding) throws TransformerException
{
Object msgBeforeTransformation = null;
Object msgAfterTransformation = null;

msgBeforeTransformation = (Object) umoMess.getPayload ();
if (msgBeforeTransformation instanceof ContentLengthInputStream)
{
ContentLengthInputStream contentLengthInputStream = (ContentLengthInputStream) msgBeforeTransformation;
String soapMessage = "";
String line;

try
{
BufferedReader reader = new BufferedReader (new InputStreamReader (contentLengthInputStream));
while ( (line = reader.readLine()) != null)

reader.close ();
}
catch (IOException e){}

umoMess.setPayload (soapMessage);
if (soapMessage.length() > 0)

}

if (msgAfterTransformation == null)
throw new TransformerException(this, new NullPointerException("Failed to trasnform the message"));
}

return msgAfterTransformation;
}
}

It sounds like we can compare the AbstractJmsTransformer in 1.4.3 with 2.0 to get more clues on this.

Henrieta,

Thanks for your help on this.
Did you run this through a profiler? Do you know what object type was leaking?

This shouldn't be an issue anymore given that we now ported all fixes over from 1.4.4-SNAPSHOT.