Question
Mphasis
US
Last activity: 16 Oct 2015 20:13 EDT
Requestor Count is huge in Requestor Management of SMA
Hi,
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.
Thanks.
Accepted Solution
Mphasis
US
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.
Mphasis
US
Hi Vipin,
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.
Pegasystems Inc.
US
Is it possible that you have done something to make the requestor no longer stateless?
This can cause requestors to be 'sticky' because they cannot be returned to the pool.
What is the package used for and what is the typical lifecycle?
Mphasis
US
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.
Pegasystems Inc.
US
That was what I meant - I think.
Is SystemPulse healthy and running?
Maybe we should take this up in an SR at this point.
Pegasystems Inc.
US
Sure if you go to SMA to the Agents link under Agent Management - you should see something like this for the Pulse
|
Pega-RULES |
1 |
SystemPulse |
Legacy |
Every 60 s |
9/29/15 3:47:09 PM EDT |
9/29/15 3:47:09 PM EDT |
9/29/15 3:48:09 PM EDT |
If there is not a happy green check box, then we need to start that guy up.
Accepted Solution
Mphasis
US
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.
Infosys
US
if processing mode is configured as stateless in service package and End requestor when done check box is unchecked in service rule, when will requestor created for service processing get deleted?
or it will never end unless forcefully terminated
Mphasis
US
Hi Mandar,
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.
Infosys
US
If there is no incoming request, after how much time requester will end? where we can configure this time?
If service is receiving requests continuously, is it advisable to use option End requester when done?