Pop Up Warning (Message from webpage) stating: "Failed to get the section stream."
We are on the Pega 6.3 Platform and have had an uptick in users set to a specific area reporting "slowness" at times accompanied by the attached error(s). We have been unable to recreate this ourselves but several users have received this and has stated it hinders there ability to process.
I have tried researching this error multiple ways (the Failed to get the section stream error seems to be the most common) but with no luck. We are unsure if the 2 are related as well or if they are 2 separate things which just happened to occur at the same time as the pop up warning issue.
It seems odd that we have 3 Lines of Business, however 1 LOB only seems to be experiencing this at this time.
Any help, feedback, or being pointed in the right direction would be greatly appreciated.
Unable to synchronize requestor within 120 seconds, enclosed is the explanation;
PRPC is configured to allow a requestor to run a single interaction at a time (we do not support concurrent interactions within the same requestor - with the exception of the creation of background/child threads - which must be explicitly initialized using the "Run in parallel" configuration for Connect-XXX rules, or by using java steps to create a BatchRequestorTask.
In most cases, 120 seconds is a sufficient wait period, and end users typically will not want to wait longer than this.
If a single operation exceeds this default 120 seconds, it is usually a strong candidate for remediation (eg a query that takes a long time or returns too many rows of data to be usable).
In this scenario this could be due to the followings;
- Long running thread taking longer time to get the response back from Server to client
- Query execution taking longer time or network latency
- Multiple clicks which might be spawning multiple threads trying to access the same resource and ending up with thread dumps
Request you to provide enclosed details for further analysis;
PegaRULES log file, Alert log, fiddler/network trace captured while the issue reproduces and the thread dump.
I would suggest you to create a SR when you have all the above files to analyze.