3 Replies Latest reply on Jan 15, 2014 11:13 PM by BrunnoAttorre

    Configuring a thread pool for multiple GWWS endpoints



      I was configuring a salt application on Tuxedo 12 and I've some doubts that I would like to understand a little better:


      1- When I configure a GW Instance in my Salt Config, if I have two inbound bindings and I set the thread pool for 20, does that mean that I will have 20 threads on the pool for both endpoints and salt would use them as requested? Or 20 for each? Is there any way to configure a thread pool for each endpoint?


      For example, a saltconfig like the one bellow, can I configure a thread pool for tux_test and another for tux_test_2 without the need for another GWWS?


      <GWInstance id="tux_test">


                      <Binding ref="tux_test:tux_test_Binding">

                          <Endpoint use="tux_test_GWWS1_HTTPPort"></Endpoint>


                      <Binding ref="tux_test2:tux_test_Binding2">

                          <Endpoint use="tux_test2_GWWS1_HTTPPort"></Endpoint>




                          <Property name="thread_pool_size" value="20"/>

                      <Property name="enableSOAPValidation" value="true"/>




      2- I would like to understand a little better the GWWS communication with my tuxedo service. When the inbound request arrives in the GW Instance, it calls the corresponding service in a synchronous call ( tpcall?), but I was wondering if there's any way to make this communication a little different (like using a tpenqueue and releasing the GWWS thread while the service is running, for asynchronous call). Is there any configuration in order to set the communication between GWWS -> Tuxedo ATMI service in a asynch way?


      Thanks in advance for the help,

      Brunno Attorre

        • 1. Re: Configuring a thread pool for multiple GWWS endpoints
          Maurice G-Oracle

          Hello Brunno,


          1- the thread pool is per-GWWS process.


          2- internally GWWS does the handling asynchronously, i.e. it does not wait for a request to complete before processing the next. The threads are only occupied when there is work to do, for example when a request is queued for a service the context will be switched until the response comes back then a thread from the pool will resume processing.


          Is there anything you observe that makes you think it is not the case


          At any rate, if you are after performance and don't mind errors not being caught earlier I suggest disabling SOAP validation which is fairly costly and usually only useful in development mode.


          Let us know if you have any further questions.


          Thank you,



          • 2. Re: Configuring a thread pool for multiple GWWS endpoints
            Todd Little-Oracle

            Hi Brunno,


            To add to Maurice's excellent description,  the thread limit doesn't limit the number of outstanding calls.  As well, it's usually recommended that you run multiple GWWS, preferably across multiple machines to ensure availability and further improve scalability.


            Related to Maurice's question, are you encountering a problem, either scalability or otherwise that suggest a needed change in the GWWS behavior?



            Todd Little

            Oracle Tuxedo Chief Architect

            • 3. Re: Configuring a thread pool for multiple GWWS endpoints

              Maurice and Todd, first of all, thanks very much for the reply!


              I was thinking the GWWS thread executing the request was put on hold until the final response to the caller was completed. This has cleared my mind, as now I understood the whole flow of the request.


              As of now, I haven`t encountered any performance problems on this, it was more a question on how the SALT -> Tuxedo communication worked and a way to better understand what are the possibilities for scalability in case of a high demand through SALT Web Service. Since GWWS handle this in the way Maurice stated, I believe the only tuning I would have to do in case of a high demand situation would be the ones you explained on your responses.


              So, once again, thanks for the explanation,


              Brunno Attorre