loadrunner Controller test execution. Continue on Error...

[Scott Moore]

Controller test execution. Continue on Error is checked in RTS, and also handled programmatically in code to turn on and off for any steps with error handling. Every error handling section exits with a return 0, including the end of the action. login and logout are in the main action. If the vuser errors anywhere in the script, should the vuser fail and end without starting the next iteration or fail and restart the next iteration (respecting iteration pacing rules)?

 

[Mark Tomlinson]

Depends on the level/type of error being handled. My guess is your custom error handling is based on content (e.g. parsing values from received payload) whereby you want the default error handling to be disabled on the step? I'm not 100% certain that the "Continue on Error" RTS works on 100% of all "errors" from the step. The driver throws errors from multiple different levels inside the call stack. Igor Markov would know more. What virtual user type?

 

[Scott Moore]

This is the Citrix protocol I am currently dealing with. I know if the past I have been able to run this and resume to the next iteration even if I get unexpected disconnects even outside my error handling. I checked my scripts from that previous version and I am using basically the same code and lr_continue_on_error() functions in the same places. If I exit out with a return 1 then it would simply not respect pacing and kick off another iteration without waiting, right? would lr_exit() do something different?

 

[Ashwin Nair]

lr_continue_on_error() with an error continuation option (3) works if, in the event of an an error, you want the vuser to exit, wait for pacing and begin next iteration. Tried this for Citrix Vuser type.

 

[Scott Moore]

Here is some pseudo code to review: turn continue on error on (option 1) return code = citrix sync on window "blah" if return code is not OK { send message to output log end current transaction with LR_FAIL citrix logoff (normal, continue on error) citrx disconnect server return 0 } turn continue on error off (option 0) If COE is checked in RTS and the following code happens, what SHOULD the user do if it hits the return 0 above? What should happen if the failure happens after the COE is turned off but before I turn it back on for the next error handling code? If COE is checked in RTS, have I just overwitten that with the programmatic turning off of COE in that last line above? Should I remove all programmatic references and just leave COE on in the RTS?

 

[Ashwin Nair]

Edit: When the user hits return 0, the transaction will end with "fail" status and script will end. I dont think RTS settings will play any role. (Please do correct me if I'm wrong) If the error happens aftr you turned COE off and before turning back on, the script will fail and end. If the COE is checked in RTS, then any programmatic statements for COE will overwrite it. That is if COE is checked in RTS and if you give lr_continue_on_error(0) that will essentially switch off the feature of contunuing in case of an error. What I usually do is, I leave COE unchecked in RTS, and handle COE programmatically with continuation option 3 at the beginning of the script which will exit vuser and proceed to next iteration in the event of any error in the script. I generally use a semaphore at the start of the script to confirm that a logoff has been done or not in the previous iteration.

 

[Scott Moore]

When the code hits return 0, it should exit the current action which would move on to the vuser_end action which only has another return 0. If you use option 3, then what happens to all the error checking code after a failed window sync? I want to send a message that tells me wha the problem was, get a snapshot, document the line of code, the vuser, iteration #, etc. How do you get that information if option 3 is set?

 

[Scott Moore]

I removed all programmatic references or lr_continue_on_error() functions in the script but left COE on in the RTS. Still fails users and stops on Unexpected disconnects.

 

[Ashwin Nair]

If the objective is to proceed to next iteration if any error occurs, then option (3) works fine. Leave COE ino RTS unchecked and keep lr_continue_on_error(3) at the start of the script. If you're looking to o/p the debug data before proceeding with next iteration, I would set logging in RTS ito 'Always send messages' with extended logging on. That way we can see the LOC, sync fails, existing open windows. For error snapshots, we can enable the same under 'Miscellaneous' section in RTS. It should capture the error shot in most situations. And yes, the data footprint will be more if extended logging is enabled

 

[Santosh Kumar Gattu]

To keep a vuser alive after encountering the error in citrix protocol is a bit tricky. As I understood, Your login, action and logout sections all are in same action part. If vuser fails at window sync and you want to send an error message to the logs then put continue on error in windows sync functions, this allows you to execute error handling code after the failure of sync function.

 

[Scott Moore]

I don't think I have explained my issue. Let me ask it a different way. If I select the "continue on error" setting in the RTS, shouldn't the script run through the entire action file no matter how many errors it receives until it gets to a return 0? This was supposed to be basic functionality of LoadRunner since the beginning. If it doesn't continue on error, then why set it? It's not continuing on error even though it is checked. I don't want it to start another iteration when it comes across an error, I want it to continue on error, which is why I am setting the "continue on error" check box so it will continue on error. continue on error I am logging a support ticket.

 

[Scott Moore]

I logged a ticket with support. I have corrected the problem. You have to manually add the CONTINUE_ON_ERROR argument to the ctrx_window_sync function EVEN IF you have the RTS setting set. This is obviously a defect. The function reference says this argument OVERRIDES the set flag in the RTS. In this case it is the only thing that forces the code to go into my error handling section. Setting the RTS alone does not do it. I still need to find out why as this makes no sense, but perhaps I am about to change history again.