[OpenSTA-devel] [ opensta-Bugs-433574 ] Replay may fail during LOAD RESPONSE_INFO
Brought to you by:
dansut
Menu
▾
▴
[OpenSTA-devel] [ opensta-Bugs-433574 ] Replay may fail during LOAD RESPONSE_INFO
|
From: SourceForge.net <no...@so...> - 2004-03-02 18:59:05
|
Bugs item #433574, was opened at 2001-06-15 15:17 Message generated for change (Comment added) made by vectorgirl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=433574&group_id=10857 Category: HTTP Replay Group: Crash Status: Open Resolution: None Priority: 5 Submitted By: Charlie Hewett (cjhewett) Assigned to: Richard Clarke (rclarke) Summary: Replay may fail during LOAD RESPONSE_INFO Initial Comment: The following error occurs on the LOAD RESPONSE_INFO (HEADER or BODY) command during replay: !HTTPRESPONSE: No data available for connection id(1) !TScript::run: ERROR: TOF execution failed !Script Execution Failed. From the test commander, it shows up as a W* ERROR script execution error with the same message. This error has a very high occurrence (50+%) under specific conditions: 1) When the time between web interactions is greater than 40 seconds (i.e. WAIT 40000 [ms]). 2) When the LOAD RESPONSE_INFO statement is in a subroutine separate from the PRIMARY GET. The interesting thing is that when I put the LOAD RESPONSE_INFO statement back into the same subroutine as the PRIMARY GET, the error pretty much disappears, even with large wait times between web interactions. Similarly, when the time between web interactions is lessened, the errors are less frequent, even when the LOAD_RESPONSE_INFO statement is in a subroutine separate from the PRIMARY GET. The error also seems to occur sometimes on the very first web interaction (the LOAD RESPONSE_INFO command after the first PRIMARY GET). ---------------------------------------------------------------------- Comment By: vectorGirl (vectorgirl) Date: 2004-03-02 10:53 Message: Logged In: YES user_id=988955 I was experiencing similar problems with a set of scripts. Each script replayed fine from modeller or by itself in a test, but when I combined the scripts in the test, or added multiple users, I would start to get errors on LOAD RESPONSE_INFO commands. I tried some of the work arounds listed here, but I still had errors. The different scripts all use a common set of subroutines, via an include, one for each app function with a PRIMARY POST and related LOADS and GETS. I found that the problems would begin with certain subroutines which had multiple LOAD RESPONSE_INFO statements. I rewrote the subroutines to do a single monolithic LOAD RESPONSE_INFO into a string variable long enough to cover the data I needed, then replaced the other LOAD statements with code to extract the data I needed from the dump string. It's not very pretty, though for some of the data it's actually simpler and it seems to have cleared up the problem in my tests. There's a chance these tests will lead into a bigger project for the same client. If so, perhaps then I can invest some time looking at the code behind it. Until then, hope this helps. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-10 08:58 Message: Logged In: NO Can someone explain the LOAD RESPONSE_INFO and SYNCHRONIZE REQUEST commands? If I put synch request before a load response should that force the script to wait until it receives the response from the primary get/post before trying to load the response? So I imagine that if I'm getting "HTTPRESPONSE: No data available for connection id(1) !TScript::run: ERROR: TOF execution failed !Script Execution Failed. " Errors it's because the page did not return properly? Thanks, ---------------------------------------------------------------------- Comment By: Marius Strumyla (i5mast) Date: 2001-11-08 10:40 Message: Logged In: YES user_id=76189 i've had this problem, too. here's what i did to fix it. the pattern of a script that would _occasionally_ fail looked like this. PRIMARY GET ... ON 1 GET <image> ON 2 DISCONNECT FROM 1 SYCHRONIZE REQUESTS PIMARY GET ... ON 2 LOAD RESPONSE_INFO BODY ON 2 ! here i would get a failure INTO ... this script would run fine from Script Modeler, but would fail with 2 virtual users (however, not always). so, i inserted DISCOENNCT FROM 2 line before SYNCHRONIZE REQUESTS. that reduced the frequency of this failure, but still didn't remove it completely. the next thing i did was added a line DISCONNECT ALL at the end of a script. PRIMARY GET ... ON 1 GET <image> ON 2 DISCONNECT FROM 1 SYCHRONIZE REQUESTS PIMARY GET ... ON 2 LOAD RESPONSE_INFO BODY ON 2 ! here i would get a failure INTO ... DISCONNECT ALL some interesting notes... when you record a script and press [] button to finish the script recording, Script Modeler doesn't close opened http connections. closing browser, however, finishes script recording in the right way. all opened connections are closed. i'm saying this, because when i recorded my scripts i would finish them in both ways. therefore, i think, some of my scripts had these failures while the others didn't. ---------------------------------------------------------------------- Comment By: David K Gleeson (nzrower) Date: 2001-06-18 15:46 Message: Logged In: YES user_id=248364 -- This describes exactly the problem that I am having as well. I make several long web requests, > 1500 ms, however this is not related. I took the WAIT statements out when I learned that the LOAD RESPONSE_INFO HEADER / BODY command waits until the request is complete. I am using POST requests. the follow scenario also avoided this issue (placing the code from the function call inline, and also calling the function straight after): PRIMARY POST URI "http://myURL/url" ON 33 & HEADER DEFAULT_HEADERS & ,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms" & "-powerpoint, application/vnd.ms-excel, application/msword, */*", & "Accept-Language: en-us", & "Content-Type: application/x-www-form-urlencoded", & "Content-Length: 411", & "Pragma: no-cache", & "Cookie: "+S_cookie_5_0+"; "+S_cookie_5_1+"; "+cookie_5_0} & ,BODY "<!-- request body goes here -->" !! this is the function call DUMP_RESPONSE contents inserted inline load response_info header on 33 into VAR_TMP set buf = "x_33_h.txt" open buf as ofile for output write VAR_TMP to ofile close ofile !! call DUMP_RESPONSE, inserted from an included file !! someplace DUMP_RESPONSE(33, "x_33_h2.txt") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=433574&group_id=10857 |