Requestor Count is huge in Requestor Management of SMA
For a particular service package in our application, below are settings of the requestor pooling tab (This is stateless):
Max active requestors: 100
Max Idle requestors: 50
Idle Timeout: 10 seconds
I checked Requestor pooling under SMA and there most idle and most active both has value of 30, so it never really exceeded the limit as it seems.
Now, when I check Requestor Management under SMA, there are at any given point of time, we have more than 400 requestors present for this particular service related activity (We have only one service under this service package). I am not understanding how there can be 400 requestors for this service if the total max active has been limited to 100 already.
Is this going to impact overall performance or cause any memory issue? Is there any explanation behind such huge requestor count in requestor management? I have included screenshots of requestor management of SMA and requestor pooling tab of the service package. We are using PRPC 7.1.8 by the way.
In System Management 7.1.8, there is no column named 'Last Activity" for each requester. We have a column titled "Last Input" though and that has the service activity name as its value. The "User Name" column has "none" value for these entries though.
The service package is stateless. However, the check-box for the service titled "End Requester when done" is unchecked. But, I believe that should not matter anyway because that's only applicable for statefull service packages.
The package is used for calling OOTB CTI login, logoff and updatecalldata activities. I am not sure if I understood what you meant by typical life-cycle.
It seems that the service package was configured as statefull and in the service rule, end requester when done checkbox was unchecked. Changed the service package to stateless, it started to work. A bad miss, but identified on time. Thanks to everyone for their inputs.
The requester will not end as after completion of the current task, it will return to the pool and wait for new incoming processing requests. If there is no incoming request, the requester will end in that case though.