Replay may fail during LOAD RESPONSE_INFO

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")

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.

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,

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.

Logged In: YES
user_id=19748

Merging the relevant info from this bug in with 645735 and
closing as this area seems to be a can of worms and want it
all addressed at one time until it is clear there are in
fact multiple distinct problems.