Requestor Pooling for Services
In this blog article, we will see how to reserve a set of requestors for Pega services.
This tutorial was implemented using Pega personal edition 8.5, but the core concepts remain the same in higher versions as well
Let’s start with requestors. You can visit another blog article on requestor types.
Requestors can refer to people or object who requests service from Pega.
a. It can be users who requests processing from a browser – browser requestor type
b. It can be agents/bots which do the background processing – batch requestor type
c. It can be external applications that request resources from Pega services – App requestor type
The runtime context for these requestors is managed by application based access group that provides access to the application.
In this blog article, we will only talk about the third requestor type mentioned above. External applications that request resources from Pega services – App requestor type.
We know that all the Pega services (Service-REST, Service SOAP, Service File) are packaged under service package data instance.
Again, you can visit my other blog article on service package instances.
One of the main jobs of the service package is to manage the Requestor pooling.
I have already explained some basics about requestor pooling, but I feel it is good to dedicate a separate post to it!
I will start with a story!
Imagine ABC is a new taxi startup. They started with one car and slowly as days go by, they started getting lot of taxi service requests. They have a challenge with managing many cars on their own. They bought 10 cars, a parking lot that can accommodate those 10 cars, technicians who can service and maintain those cars.
With their own cars they can service maximum 10 taxi request at the same time. As a growing company, they felt restricted in able to process only 10 taxi service requests at a certain time. The company decided to get 10 more drivers who own the car to process the taxi service requests. Company is not responsible for service and maintenance of those cars, except for the 10 cars they own.
Here they can have maximum idle cars waiting = 10
Maximum active cars that can process the request = 20
Now let’s talk in Pega terms.
Say there is a Pega application that processes the claims request from different applications. REST service is dedicated to processing the requests.
We know that we need APP requestor(s) to process the service requests.
So when an external application sends an external, we need to establish the requestor (create a requestor) and then execute the service rule under the requestor context to process the service request. Here creating a new requestor will be like performing an additional transaction together witha claim request processing transaction!!
Pega comes up with an idea to reuse the requestors.
Reusing requestors means Pega doesn’t delete the requestors and keeps it in an idle state in a pool.
Make an important note that idle requestors eat up system resources and should be managed accordingly!
Say, you can specify the maximum no of Idle requestors = 10
Now your Pega application can also get huge number of service requests (which may be higher than your idle requestor count), in that case we may need to create new requestors and may delete it after the processing.
Say, you can specify the maximum no of active requestors = 20
Hope you can relate the requestor pooling with taxi request story above. If not, sorry for the wrong analogy 😉
Before looking into the requestor pool configuration, let’s check it from admin studio.
Switch to admin studio -> Resources -> Requestor pools
Important note: By default, you will not have the requestor pooling access in admin studio unless you have the two roles – PegaRULES:SysOpsObserver and PegaRULES:SysOpsAdministrator in your access group.
We can see there are two requestor pools for the two service packages.
Out of the box AsynDeclarativePool and a Test service package I created before.
In AsyncDeclarativePool there are 6 Idle requestors and for Test service package there is one Active Requestor.
Switch to Requestors and filter on APP requestor type.
You see there are totally 7 requestors ( 6 Idle and 1 active) and one using a Java thread.
The test service package holds the service-file rule and that is why it is always active. The file listener uses the Java thread and keep on polling with an active requestor context.
The configuration in my test service package is as below –
In the pooling tab, you see three main configurations
Maximum idle requestors – This is the maximum requestors that can be idle for this service package. For new requests, the idle requestors can be reused.
Once the processing completes, the active requestor can return to the idle requestor pool until the maximum idle requestor count is reached.
The field also supports -1 which allows unlimited idle requestors count.
Keep in mind that having unlimited configuration may end up eating system resources and hence use it only when necessary.
Maximum active requestors – This is the maximum requestor count that can process the service request.
If you specify count as 10, then only 10 service requests can be processed by 10 requestors at the same time. If 11th request comes, in then it needs to wait before any active requestor completes it job.
The field also supports -1 which allows unlimited active requestors count.
Maximum wait (in seconds) – You can specify the maximum wait seconds for the service request to wait for an available active requestor. If no active available is available at the specified time then the service may end up in timeout error.
Let’s test and learn these entire configurations practically.
What are the pre-requisites to test requestor pooling?
1. Create a new service package
2. Create a simple service activity – TestRequestorPooling.
Use a simple log-message method to log the requestor ID from pxRequestor.pxClientConnection property.
3. Create a simple service REST rule
I configured the service method to be GET and used the service activity to log the requestor ID.
Pre-requisistes are ready now.
Let’s start with testing different scenarios.
Scenario 1 – Check if Idle requestor is getting reused
Step 1: check the requestor pooling from admin studio.
Currently no requestor pool is created for the new service package – myknowpega
Step 2: Now hit the service URL from postman- http://localhost:8001/prweb/api/myknowpega/V1/pooling
Verify you get 200 response. It took just 23 ms.
Step 3: Now Refresh the requestor pooling.
You see the a new requestor created and it finished processing and then returned back to Idle state.
Step 4: you can see the new APP requestor ID in admin studio and the same in the logs AM69I7A3LDP1AYDWMKG3DKTWV27195TK8A
You can find the pegarules log file under such path in your machine
C:PRPCPersonalEditiontomcatworkCatalinalocalhostprweb
Step 5: Now Just keep on sending requests continuously from Postman
You will see still the single requestor is re-used for all incoming requests.
We understood that within 20ms the requestor for Idle goes to Active state, process the request and then returns back to Idle state to process the subsequent requests.
If you can able to send more requests within 20ms, ideally then a new requestors may be created to process.
Scenario 2 – New requestors are created for long running service within the maximum active requestor limit
Let’s make it a long running service process.
Step 1: Add a wait method in the service request activity for 30 seconds.
Now the service processing should take 30s+20ms.
Step 2: Now continuously send 3 requests from postman within seconds.
You will see three active requestors – 1 reused from the Idle pool and 2 others are created newly.
You will see separate requestor ID s in logs as well as in the admin studio.
After 30 seconds, the requestors should return back to Idle pool.
Scenario 3 – Service will end up in error if service request count exceeds the active requestor count.
Step 1: Use the same wait method in service activity.
Step 2: Update the requestor pooling tab as below.
Step 2: Send 6 requests continuously from postman. First 5 records should process correctly within 30 seconds, but 6th record should end up in error within Maximum wait (inseconds) configuration – 10 seconds.
For the 6the request we received 500 error on 10045ms.
In the admin studio, you can see 5 requestors were used and in Idle state.
Scenario 4 – maximum no of active requestors is greater than max no of Idle requestors
In scenario 3, we saw with too many incoming requests that exceeded maximum active requestor count the response was 500 internal server error.
To solve this we need to have increased active requestor count.
Step 1: In the requestor pool tab, increase the maximum no of active requestor to 6 and save the instance.
Step 2: Now send 6 requests continuously from postman.
Step 3: Check in the admin studio – you see 6 active requestor count.
Refresh after 30 seconds. You will see one of the requestors is deleted because maximum idle requestor count can only be 5.
You can try it for other scenarios as well like setting -1 for maximum count.
Let’s talk about some best practices in setting up the requestor pooling.
What are the best practices for requestor pooling?
a. Always configure the maximum idle requestors to be less than or equal to maximum active requestors. Because some idle requestors may remain unused if it is configured higher than active requestors and may end up eating resources.
b. Always be careful in configuring the maximum idle requestors. In some applications, you may have lot of service package instances and so may end up with a lot of idle requestors. Requestor pooling also determines what and how many services can be packaged under a single service package instance.
c. When you get a lot of incoming requests within a short interval of time, it is safer to increase the maximum active requestors. When you rarely get incoming requests to the service, then you can decrease the idle requestors to free up requestor allocation.
d. When service processing takes too much time, then the wait interval in seconds should be higher so that we may not end in 500 error if no active requestor is available for fa ew seconds.
e. Periodically tune your requestor pool configuration. You can use the view details option to check a few metrics before determining if we need to tune the configuration.
You can follow the link for more details on tuning the requestor pool.
Important note: For stateful service requests, idle requestor count is not applicable. You will not find the configuration when you choose stateful option, this is because requestor need to be maintained for stateful requests.
How to delete the requestor pool?
There may be some situations, where you need to clear the requestor pool.
For example – when the active requestor fails to return tothe Idle state for a very long time, then you may need to clear up the requestor pool.
In the admin studio, with the right privilege, you can clear the requestor pool.
As a summary,
– Requestor pooling can be configured in the service package instance and can be applicable for all services that is packaged under service package instance.
– You can configure maximum idle requestors and maximum active requestors.
– Follow the best practices to tune the requestor pool configurations.
– Fromthe admin studio, you can clear the requestor pool.
We are at the end of this blog article.
