Question
Macquarie Bank
Macquarie Bank
AU
Macquarie Bank
Posted: Jan 23, 2023
Last activity: Feb 23, 2023
Last activity: 23 Feb 2023 0:47 EST
Closed
Idle requestor expiry time in a requestor pool
Hi All,
We have a service REST with processing mode as Stateful, with 10 active requestors in my pool. Due to some performance issue (LDAP auth taking more time), we are thinking to not to end the requestor session. so that whenever a new request comes it will re-use the same requestor from the pool by avoiding the auth check. I would like to understand below scenarios before we go with this option.
1) How long will be requestor be present in the pool in idle state.
2) How can we cache the LDAP auth credentials, so that everytime a new request comes from same consumer it can be validated from the cache rather than hitting the LDAP server.
3) Is it advisable to have a requestor session long without ending it?
Regards,
Navakanth M.
***Edited by Moderator: Pooja Gadige to add capability tag***
To see attachments, please log in.
Posted: 3 years ago
Bits In Glass
Bits In Glass
CA
@NavakanthMannem
The idle timeout of requestors in the pool can be configured in the "Requestor Management" landing page in the Pega Designer Studio. The default value is 30 minutes, which means that if a requestor remains idle (i.e., no requests are received for it) for more than 30 minutes, it will be removed from the pool.
Pega provides several options for caching authentication credentials, such as LDAP cache or credential cache. These options are available in the "Authentication Service" rule instance. By enabling caching, Pega can reduce the number of LDAP server hits for subsequent requests from the same consumer.
It is generally not advisable to keep requestor sessions long without ending them, especially in a Stateful processing mode. Keeping requestors idle for a long time can lead to issues such as memory leaks, increased response time, and potential security vulnerabilities. However, depending on the specific use case and system requirements, it may be acceptable to increase the idle timeout or use other techniques such as requestor pooling to improve performance. It is important to carefully consider the implications of such changes and thoroughly test them before deploying to production.