Question
Infosys
US
Last activity: 15 Sep 2017 13:53 EDT
how to identify which Load-DataPage has caused Connect-Wait to fail
In our application, we have one activity in which "Load-DataPage" is called multiple times to load multiple data page asynchronously first, followed by Connect-Wait with WaitSeconds parameter set to 11 seconds.
During execution, Connect-Wait fails sometimes.
The question is, when Connect-Wait fails, is there easy way to identify the "Load-DataPage" that fails or takes a long time, causing Connect-Wait to fail?
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Infosys
US
I am hoping there are a few engine classes for which logging level can be set to debug to reveal that information. But other solutions involving coding are acceptable too.
Infosys
US
Still waiting for answer as of today. 9/14/2017
Hope someone in Pega engineering can help.
Pegasystems Inc.
US
Hi Yaning,
Can you check in the tracer that might help you.
Regards
Mahesh
PEG
US
I don't think you will take any performance hit if you have a separate connect-wait for each data page load. You can assign a pool number to each load (the number can be whatever you want it to be), and then each connect-wait will wait on that and only that pool. You can fire all the loads first, then all the connect-waits. Whichever connect-wait fails will have a failure status, and you will immediately know which page fails by the pool number.
Since all the loads take place asynchronously, you will get through all the connect-waits in as long as it takes the longest load to complete.
Infosys
US
Hi Ron,
How are you? Thank you for answering!
I think your suggestion certainly helps, although not perfect.
My understanding is that Connect-Wait step halts until its corresponding data page is loaded.
So for example:
step 10, Connect-Wait(1000)
step 11, Connect-Wait(1100)
step 12, Connect-Wait(1200)
step 13, Connect-Wait(1300)
step 14, Connect-Wait(1400)
If both Connect-Wait(1000) and Connect-Wait(1400) are slow and exceeds the time threshold, 10 seconds for example, we would only see step 10 fails.
Step 14 does not start while step 10 executes, therefore, step14 won't show fail status unless the underlying page load takes 20 seconds.
PEG
US
Hi Yining. I thought this might be you. Great to hear from you again -- I guess your life, like mine, is Pega forever! ;)
Your example is correct, but depending upon the actual behavior, and the reason for detecting "failure", it might be good enough. It depends upon what the expected or observed behavior of the pages might be. In a simple case, you expect each page to take no more than 2 seconds. If you configure all the Connect-Waits for 2 seconds, and the actual load times are 2,2,2,2,2, then step 10 will wait 2 seconds, and steps 11-14 won't wait at all -- the loading will have been completed by the time you get to them.
If Step 13 takes 5 seconds when normal expectation is 2 seconds, then step 10-12 will succeed, and 13 will fail.
Or, if you observe that when a page fails to load, it NEVER loads, then again, having the 4 connect-waits will catch each of the failures.
For your scenario, I agree we would only see step 10 fail, unless, of course, step 14 is so slow it fails anyway. If you fall into the middle ground, where both 10 and 14 each take 10 seconds (so they each have exceeded their expected load time), what is the purpose of detecting "failure"? For, although in this case step 14 failed to load within the expected 10 seconds, it did actually load. If it did not, you would see that step 14 failed as well.
Infosys
US
Thank you very much Ron! We are on the same page.
-Yining
PEG
US
And one more thing I just found out today. If you look at the Help for the connect-wait, you will see that when you don't supply a pool-id, the connect-wait will wait for child processes, but NOT for asynchronous data page loads! Certainly something you will need to know.