The war file is installed but fails to start and continually stalls at the following line in the logs.
(rnal.access.CacheContainerImpl) INFO - Using the Dynamic Cache Probation Policy - cache after 2 accesses AND with a blob increment of 102400.
it appears to kill tomcat processes as the tomcat shutdown is unable to find the listener at port 8005 once this happens.
@BruceT30 Did you check the Platform Support Guide to make sure it is a supported stack?
Upgrade to 8.5.3 - Restart app server always stuck on loading cache
Performance lags in system startup and other contexts after updating to Pega Platform 8.x.x [SDR-61]
Please log a support issue via the MSP and provide the INC id here if you need further help.
@BruceT30 I can see that you logged a support ticket on the 9th February. Please include this information in these PSC posts.
You only recently provided the context.xml file to the support team and they are now investigating.
They will review logging in light of context.xml, compare to standard startup and see where time is spent or if errors are occurring.
→ Please continue to liaise directly with GCS and please add a new reply here once the issue is resolved.
@BruceT30 the support ticket was resolved with the below analysis:
Explanation description:
Some of the parameters that are applicable for jdbc connection pool (like MaxActive etc.) are not applicable for dbcp connection pooling due to which Tomcat will use the default values instead. This is causing the defacult connection to be set to 8 which is insufficient for Pega engine startup.
Explanation type:
Client resolved the issue by setting theNodeType definition.
We strongly recommend implementing the suggestion (Change maxActive and maxWait (not used in DBCP) → to maxTotal and maxWaitMillis).
This recommendation stems from the error stack we observed in the logs. While separating the node type may aid in starting up the nodes initially, the application will eventually require additional database connections.
@MarijeSchillern I just reproduced the same exact issue when I changed -DnodeType from universal to -DNodeType=webuser,batch-processing,stream - startup hung in the exact same place. I also observed from DB itself that all database connections were idle. What was the change to nodeType that resolved the issue?
@WERDA I added all the details I was able to find from the closed support ticket : INC-B5670
Information in closure notes:
“I_t was caused by the NodeType definition in the setenv. We set it to WebApp and Stream and it started_.”
I’ll let the post author @BruceT30 comment further, alternatively log a support issue.
I had a bad nodeType arg. Fixed it by changing to -DNodeType=WebUser,BackgroundProcessing,Stream,Search,BIX
@MarijeSchillern Thanks! just saw your reply.