[OpenSTA-devel] [ opensta-Bugs-645735 ] LOAD RESPONSE_INFO BODY with a var conid can cause issues

[SourceForge.net <no...@so...>]

Bugs item #645735, was opened at 2002-11-29 10:11
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=645735&group_id=10857

Category: Script Language
Group: Inconvenience
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Ralph Hendriks (ralluph)
>Assigned to: Daniel Sutcliffe (dansut)
>Summary: LOAD RESPONSE_INFO BODY with a var conid can cause issues

Initial Comment:
The script compiler allows the connection ID parameter 
in a LOAD RESPONSE_INFO command to be an 
integer variable, value or expression, as documented in 
the SCL Reference Guide.

It appears that the HTTP Task Group Executer code 
only allows an integer value. This makes it 
uncomfortable to parametrize conid's.

see also:
http://sourceforge.net/mailarchive/forum.php?
thread_id=1355570&forum_id=4763

used version: OpenSTA 1.4.1 on Windows 2000 SP 3

----------------------------------------------------------------------

>Comment By: Daniel Sutcliffe (dansut)
Date: 2005-04-25 18:08

Message:
Logged In: YES 
user_id=19748

There is something much more subtle going on here.  My
earlier provided fix does not work all the time and Antony's
IF fix makes little sense if this is really a SCL syntax
problem.

I have also found that adding a LOAD REPONSE_INFO HEADER on
the same conid and request causes the LOAD RESPONSE_INFO
BODY to work fine.  My suspicions are now that this has
something to do with event sequencing and using a variable
for the connection id somehow doesn't cause the LOAD command
to wait until it is sensible to perform - the evidence that
this is not the case is that a SYNCHRONIZE before the LOAD
does not help...  I give in.

Workaround:  Do a LOAD RESPONSE_INFO HEADER on the same
connection id variable and request.

----------------------------------------------------------------------

Comment By: Antony Marcano (antonym)
Date: 2003-11-18 01:47

Message:
Logged In: YES 
user_id=403001

Another observation:
When the "LOAD RESPONSE_INFO BODY ON iVar" is wrapped 
in an "if then" statement the integer variable does not require 
the integer expression work-around. i.e. The integer variable 
can be used as you would expect.

----------------------------------------------------------------------

Comment By: Daniel Sutcliffe (dansut)
Date: 2003-09-15 13:55

Message:
Logged In: YES 
user_id=19748

Problem reported again by Antony Marcano of etest associates
- details below come from his bug report (804342) which is
merged with this report and removed:

Playback error (in Modeller and Commander):
---------------------------------------------
TModeller_Web.exe|1632|1-1|FE_HOME|64|E*HTTPRESPONSE: No
data available for connection id(1)
TModeller_Web.exe|1632|1-1|FE_HOME|64|E*TScript::run: ERROR
in TOF execution; resuming at ON ERROR handler. 1-1
:[286]:LABEL: ERR_LABEL
---------------------------------------------

Above error occurs when using INTEGER variable or array as
the connection ID:

LOAD RESPONSE_INFO BODY ON conID

(Where conID is an Integer variable; eg. conID=1)

Or:
LOAD RESPONSE_INFO BODY ON conID[1]

(Where conID[] is an array of INTEGERS; e.g.
conID[1]=1)

This does not affect RESPONSE_INFO HEADER.  It is possible
to use an integer variable.

----
Dan - Some extra info:
Providing an Integer expression works fine, so a sneaky
workaround for this is to do something like:

LOAD RESPONSE_INFO BODY ON (0+conID) INTO ...

Alll other HTTP commands which use conid's appear to work fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=645735&group_id=10857