Support Article
Search is not working in PRPC 6.3 SP1
Summary
Search is not working in PRPC 6.3 SP1.Error Messages
2016-08-01 21:34:12,476 [for queue: 'default'] [ STANDARD] [ PegaRULES:06.03] ( internal.mgmt.RequestorPool) ERROR|HTTP|LuceneServiceWorkPackage|Pega-Search-Work-Param|pzHTTPLuceneSearchWork - Timed out borrowing service requestor from requestor pool
2016-08-01 21:34:12,476 [for queue: 'default'] [ STANDARD] [ PegaRULES:06.03] ( internal.mgmt.PREnvironment) ERROR username HTTP|LuceneServiceWorkPackage|Pega-Search-Work-Param|pzHTTPLuceneSearchWork - Problem
obtaining requestor from ServiceRequestorPool
com.pega.pegarules.pub.PRException: Timed out borrowing service requestor from requestor pool
From: (unknown)
at com.pega.pegarules.session.internal.mgmt.RequestorPool.borrowRequestor(RequestorPool.java:464)
at com.pega.pegarules.session.internal.mgmt.RequestorPoolManager.borrowRequestor(RequestorPoolManager.java:61)
at com.pega.pegarules.session.internal.PRSessionProviderImpl.borrowRequestor(PRSessionProviderImpl.java:573)
at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:883)
at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:771)
at com.pega.pegarules.integration.engine.internal.services.ServiceAPI.getServiceMethod(ServiceAPI.java:2612)
at com.pega.pegarules.integration.engine.internal.services.ServiceAPI.preLockSetup(ServiceAPI.java:965)
at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:326)
at com.pega.pegarules.integration.engine.internal.services.http.HTTPService.invoke(HTTPService.java:355)
at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:312)Steps to Reproduce
Not ApplicableRoot Cause
A defect or configuration issue in the operating environment.
The requestor pool size in the Data-Admin-ServicePackage was too small for the production environment. This needs to be tuned as the load in the application increasesResolution
Perform the following local-change:
Increasing the default value of Maximum Idle Requestors, Maximum Active Requestors, and Maximum Wait (in seconds) will resolve this issue. And, to what extent it should be increased depends on the load in production.
Sudden Increasing the Maximum Active Requestor to huge number is not a good idea as it would have an impact on JVM Memory utilization hence Rather than drastically increasing the value to 100 or higher number, better try increasing the Maximum Idle Requestors, Maximum Active Requestors, Maximum Wait (in seconds) by 10 and monitor the JVM memory footprints and re-occurrence of this behaviour.
To set an estimated value, perform following steps:
- Access the System Management Application (SMA) during peak volume window and click the estimate size button. Clicking this will add a column called Datasize in the list view with the size of memory occupied by the Requestors.
- Take an average of this.
Note: It is recommended to do these changes in a lower environment or load test environment first, then gather statistics around this and then forecast the heap memory settings.
Published September 1, 2016 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.