Re: Unable to customize threading in synchronized mode

1. remoteSync="false" synchronous="true"
2. remoteSync="false" synchronous="false"
3. remoteSync="true" synchronous="false"
4. remoteSync="true" synchronous="true"
   

I don't mean to be annoying but in the config you pasted below, remoteSync is set to false .. have you tried setting it to true?

A

Antoine Borg, Senior Consultant | Tel: +32 28 504 696
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: antoine.borg@ricston.com <antoine.borg@...> | blog: blog.ricston.com <http://blog.ricston.com/> | web: ricston.com <http://www.ricston.com/>  

---

From: Vikramjeet Singh Jassal [vikramsj@...]
Sent: Wednesday, November 26, 2008 12:40 PM
To: user@...
Subject: Re: [mule-user] Unable to customize threading in synchronized mode

Hi again,

Yes I have tried the remoteSync attribute too. It gives identical behaviour as the synchronized attribute. I get the responses back, but no more than 4 simultaneous instances.

Any other suggestions?

Thanks,
Vikram


On 25/11/2008 09:19, "Antoine Borg" <antoine.borg@...> wrote:

Hi,

Have you tried using the remoteSync attribute  on the endpoint?

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

 
A

Antoine Borg, Senior Consultant | Tel: +32 28 504 696  
ricston  Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email:  antoine.borg@ricston.com <antoine.borg@...>  | blog:  blog.ricston.com <http://blog.ricston.com/>  | web: ricston.com <http://www.ricston.com/>   


 

---

From: Vikramjeet Singh Jassal  [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