« Return to Thread: Unable to customize threading in synchronized mode

RE: Unable to customize threading in synchronized mode

by antoine.borg :: Rate this Message:

Reply to Author | View in Thread

Unable to customize threading in synchronized mode

Hi,

Have you tried using the remoteSync attribute on the endpoint?

http://ricston.com/blog/?p=115

Antoine Borg, Senior Consultant | Tel: +32 28 504 696
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM

email: antoine.borgantoine.borg@... | blog: blog.ricston.com | web: ricston.com

From: Vikramjeet Singh Jassal [mailto:vikramsj@...]
Sent: Thursday, November 20, 2008 1:48 PM
To: user@...
Subject: [mule-user] Unable to customize threading in synchronized mode

Hi,

I have implemented a simple http proxy which does some custom modifications to the querystring before submitting it to a backend. My problem is that I am not able to make mule execute more than 4 instances of this model simultaneously. It’s crucial to get the response back so I have configured the http inbound endpoint to be synchronized.After trying out both 1.4.1 and 1.4.4 releases without luck, I have implemented a really simple mule-model to debug this scenario. Here is my configuration:

<mule-configuration id="testApp" version="1.0">

    <mule-environment-properties
       serverUrl="">
       <threading-profile id="default" maxThreadsActive="100"
           maxThreadsIdle="100" threadTTL="60000" poolExhaustedAction="RUN"
           threadWaitTimeout="60000" maxBufferSize="0" doThreading="true" />
   </mule-environment-properties>

     <connector name="HttpConnector" className="org.mule.providers.http.HttpConnector" >
   <properties>
       <map name="serviceOverrides">
           <property name="inbound.transformer"
               value="no.fast.pf.pluto.transformers.EmptyTransformer" />
       </map>
   </properties>
   </connector>

    <model name="PlutoServer">
        <mule-descriptor name="QRServer" implementation="org.mule.components.simple.EchoComponent">
           <inbound-router>
               <endpoint address="${server.qrserver}" connector="HttpConnector"
                               remoteSync="false" synchronous="true">
               </endpoint>
           </inbound-router>
        </mule-descriptor>
    </model>

</mule-configuration>

As you can see the only custom code is the no.fast.pf.pluto.transformers.EmptyTransformer. Here is the code:
public class EmptyTransformer extends AbstractTransformer{     @Override    protected Object doTransform(Object arg0, String arg1) throws TransformerException {        System.err.println("WAITING START");        try {            Thread.sleep(10000);        } catch (InterruptedException e) {            e.printStackTrace();        }        System.err.println("WAITING DONE");        return arg0;    } }

I have tried to find out where the limitation to 4 instances is actually done, so I configured this transformer to debug this as early as possible in the pipe. The transformer simply writes out a message and sleeps for 10 seconds. This makes it possible to monitor how many instances that prints out “WAITING START” before “WAITING DONE” starts popping up. No matter how i configure the thread-model and other pools, I am not able to have more than 4 “WAITING START” in a row. I have tried several parameters on the http connector as it seems the limitation to 4 instances is done already on the inbound side before reaching the component. These are the switches I have tried out on the connector with no luck:
<!--         <property name="keepSendSocketOpen" value="true"/>        <property name="numberOfConcurrentTransactedReceivers" value="40"/>        <property name="numberOfConcurrentTransactedDispatchers" value="40"/>        <property name="maxDispatchersActive" value="40"/>        <property name="maxReceiversActive" value="40"/>
->

I have also configured pooling-profile and threading-profile (with id=component | receiver | dispatcher | default) directly inside the mule-descriptor without luck.
HOWEVER, most important observation is that only way I can make the model follow the configurations I make in the threading-profile is to change from synchronous=true to synchronous=false. Then I get as many “WAITING START” in a row as I have configured in the threading-profile or as many as http-requests I issue. This I have succesfully scaled up to 40 and 50 in a row without any problem. BUT it’s crucial for me to get the response back to the client calling the model, so I have to set synchronous to true. I hope someone who have tried out similar stuff could guide me in the right direction here for scaling the model above 4 simultaneous instances.

Thanks in advance,
Vikram

« Return to Thread: Unable to customize threading in synchronized mode