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?
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.
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.
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.