In SOA Suite 12c, the model for managing and tuning thread pools has been changed significantly from 11g. In 11g, each of the service engines such as BPEL, BPMN and Mediator had their own configurations through Enterprise Manager to tune their respective thread pools. In BPEL for example, you could configure the invoke threads, engine threads, and system threads. You were not, however, able to control the number of incoming requests to exposed SOAP services for example because these were handled by standard Weblogic execute threads and not the invoke or engine threads.
In 12c, Oracle has moved away from these custom thread pools to use standard Weblogic Work Managers. This allows the thread pools to be managed and monitored in a much more consistent and standard manner. They have also added a Work Manager for incoming requests so that these can be limited and not be allowed to over load the server. Another benefit in SOA 12c is that, by default, the constraints on the Work Managers are matched to the SOADataSource automatically so that you don’t have to worry about threads running out of database connections.
As you can see below, SOA now has a large set of Work Managers and minimum thread constraints all beginning with the default_ prefix as well as several Work Managers, thread constraints, and request classes all beginning with the SOA prefix. The default configuration has each default_ Work Manager configured to use its corresponding minimum thread constraint and the SOAInternalProcessing_maxThreads constraint. The SOA_Request_WM Work Manager likewise uses the SOAIncomingRequests_maxThreads constraint for handling incoming Web Service requests.
By default the SOADataSource is set to a maximum of 50 connections. Also by default 20% of this is allocated to incoming requests, 50% to internal processing and 30% to internal buffer. As you can see below, this results in the SOAIncomingRequests_maxThreads being set to 10 threads and the SOAInternalProcessing_maxThreads set to 25 threads.
Now we will change the maximum size of the SOADataSource from 50 to 100 as shown below.
If we check the max thread constraints again, we will see if they have been increased automatically to 20 and 50 respectively.
We can also easily change the ratio of threads in the different constraints as well. If we go to EM, right click on soa-info, go to SOA Adminstration -> Common Properties and then click on the More SOA Infra Advanced Configuration Properties link:
We can then click on the SOAMaxThreadsConfig MBean
From here, we can see three configuration values where we can adjust the ratio between incoming, processing, and buffer threads. Below I have adjusted it to 40% incoming, 30% buffer and 30% processing.
Within a few seconds, we can see that our max thread constraints have already been updated based on these new ratios:
By implementing these new features, the process of tuning has become much simpler for many of our customers. In most cases, the default settings will work and, if needed, only the size of the SOADatasource or the ratio of the thread pool sizes will need to be adjusted. Only in more specific cases will more advanced tuning, such as creationg additional max thread constraints or fair share request classes, need to be performed. The first step should always be to tune using basic configurations and only move to more advanced configurations when necessary.