RE: Unable to customize threading in synchronized mode

Hi,

So case 2 (everything is asynchronous) works best but does not return a response.  Have you tried using a response router?  I know that the config you posted below may not need/use a response router but you do mention that your live code is a little more complex.

HTH

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: Monday, December 08, 2008 1:01 PM
To: user@...
Subject: Re: [mule-user] Unable to customize threading in synchronized mode

Off course,
Maybe I was a little unclear there.
I have tried all the following:

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

And case 1, 3 and 4 gives the same result: only 4 simultaneous instances, while case 2 makes number of instances customizable through pooling/threading-profiles (scaling correctly) but doesn’t give me the response back which is crucial for my use-case.

Thanks,
Vikram

On 03/12/2008 11:42, "Antoine Borg" <antoine.borg@...> wrote:

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