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.
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?
Oracle Tuxedo Chief Architect
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,