Support Article

Search is not working in PRPC 6.3 SP1

SA-26509

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 Applicable

Root 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 increases


Resolution



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:

  1. 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.
  2. 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 August 7, 2016 - Updated September 1, 2016

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.