opensta-devel — OpenSTA developer discussions

[OpenSTA-devel] [ opensta-Bugs-433574 ] Replay may fail during LOAD RESPONSE_INFO

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

Bugs item #433574, was opened at 2001-06-15 18:17
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=433574&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Replay
Group: Crash
Status: Open
Resolution: None
Priority: 5
Submitted By: Charlie Hewett (cjhewett)
>Assigned to: Daniel Sutcliffe (dansut)
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 13: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 11: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 13: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 18: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

[OpenSTA-devel] [ opensta-Bugs-419422 ] Errors using File Variables &amp; many VUs

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

Bugs item #419422, was opened at 2001-04-27 04:10
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=419422&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Architecture
Group: Crash
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Richard Clarke (rclarke)
>Assigned to: Daniel Sutcliffe (dansut)
Summary: Errors using File Variables & many VUs

Initial Comment:
When I ran a test with 100 virtual users and simply 
included NEXT and LOG commands to read and log the 
value of a file variable my test ran successfully 
until late in the test. At the point of failure, all 
threads reported the following errors:

W* IF-THEN Failed: '(USER_AGENT = "DEFAULT")' 
 No value available for variable: USER_AGENT,
W* ERROR: FAILED PROCESSING TOF (1): ,
W* TScript::run: ERROR: TOF execution failed,

When the test was rerun using a value list (rather 
than a file variable) the test ran successfully.

The above, strongly suggests that the script objects 
have been  corrupted - probably by something in the 
file variable code.

Charlie Hewett has reported a similar problem on the 
users list. In his case, the following message is 
reported for each VU after the 84th instance:

W*ERROR: FAILED PROCESSING TOF(4) 
CECFileVar::CECFileVar

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

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

[OpenSTA-devel] [ opensta-Bugs-405440 ] No common date/time format

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

Bugs item #405440, was opened at 2001-03-02 10:13
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=405440&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Architecture
Group: Design
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip Whettlock (pwhettlock)
>Assigned to: Daniel Sutcliffe (dansut)
Summary: No common date/time format

Initial Comment:
Dates and times occur in a number of places within 
OpenSTA, in a variety of formats. Could we have a 
standard format?
I would suggest using the extended formats of 
ISO8601:2000, these are YYYY-MM-DD (date), hh:mm:ss 
(time) and YYYY-MM-DDThh:mm:ss (date/time)

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2001-03-13 10:00

Message:
Logged In: YES 
user_id=19748

These times should also be consistent throughout the run.
ie. if a date/time is displayed it should always be this.
John Crowell reports on the users mailing list that the HTTP
data list looses the time form a date/time format at
midnight.
See:
 http://www.geocrawler.com/archives/3/6594/2001/3/0/5312969/

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

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

[OpenSTA-devel] [ opensta-Bugs-415144 ] RANDOM fails with ranges &gt; 32768

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

Bugs item #415144, was opened at 2001-04-10 09:51
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=415144&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Script Language
Group: Behavioral
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Richard Clarke (rclarke)
>Assigned to: Daniel Sutcliffe (dansut)
Summary: RANDOM fails with ranges > 32768

Initial Comment:
SCL allows a range of values to be specified in the 
Definitions section of a script for an integer 
variable. If this range is greater than 32768, no 
value beyond the 32768th will be generated. This is 
because the random number generation function that is 
used only generates a value in the range 0 to 32767.

For example, the definition:

Integer myvar (0-60000)

will never generate a random value above 32767 
when "GENERATE myvar" is used.

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

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

[OpenSTA-devel] [ opensta-Bugs-751953 ] Cookie variable size not matched to size of cookies recorded

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

Bugs item #751953, was opened at 2003-06-10 10:43
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=751953&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Inconvenience
Status: Open
Resolution: None
Priority: 3
Submitted By: James Ward (jmrward)
>Assigned to: Daniel Sutcliffe (dansut)
Summary: Cookie variable size not matched to size of cookies recorded

Initial Comment:
Cookies that end with "==" lose these characters when 
saved in a cookie variable.  An example from a replayed 
script is below:

1-1 :[525]:HTTPRESPONSE(18): Setting COOKIE_18_1 
to 'SMSESSION=ig/.....sVZgQ=='
1-1 :[529]:LOG: cookie_18_1: SMSESSION=ig/.....sVZgQ


Could possibly happen with other trailing characters in 
cookies.

workaround:  manually add +"==" after any cookie that 
is supposed to have these characters

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2003-06-25 08:35

Message:
Logged In: YES 
user_id=19748

Thanks for investigating your issue and finding the root
cause of your propblem.  In future discussing issues like
this on the OpenSTA users mailing list first is likely to
find you quicker solutions and allow accurate bug
descriptions first time:
  http://lists.sf.net/lists/listinfo/opensta-users

I'm not sure there can ever be a perfect answer to this
problem though; yes we should make sure the variables are
big enough to store the cookies recorded but whose to say
that the runtime cookies won't be bigger still.  Perhaps we
also need some sort of warning generated when filling vars
truncates the content as well.

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

Comment By: James Ward (jmrward)
Date: 2003-06-13 12:37

Message:
Logged In: YES 
user_id=798053

I figured this one out myself.  The cookies were not being 
generated incorrectly.  However, the default cookies that the 
script was declaring were not quite large enough.  I realized 
that the cookie I was having trouble with was 1026 
characters long while the automatic cookies were declared as 
1024 characters long (cutting off the last two characters, 
which in this case was "==").  So, the real issue is that 
automatic cookie generation does not dynamically size the 
cookies used, which is just inconvenient.

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

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

[OpenSTA-devel] Developer updates

[Daniel S. <da...@Op...>]

Just a quick email to annouce a few changes:

Richard Clarke truly does seem to have dropped off the face of the
earth and so I'm taking him off the project member list and will be
re/unassigning his bugs.  Richard: if you are out there lurking, you
are welcome back whenever you can find the time to get involved
again.

Thierry Boullet has proved to be a very valuable development resource
and has been made a full SF OpenSTA project member.  Welcome Thierry,
I hope this can see your involvement move to a new level :-)

With the addition of a new member with write access to CVS I decided
to drop my unofficial doc on keeping the stable releases stable into
the Wiki, it can be found here:
  http://portal.opensta.org/faq.php?topic=DevelopmentStableUpdates
This is the procedure myself and Geoff have been following when
checking in changes - I welcome feedback and comments if anyone has
them.  It will make more sense when we do have an unstable release
series - hopefully it will be worth doing the branch for this soon
...

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] [ opensta-Bugs-897856 ] Recording HTTPS fails because newer IE escapes URL

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Serious
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alain Ribault (ribault)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Recording HTTPS fails because newer IE escapes URL

Initial Comment:
HTTPS recording :
With my browser (IE6, latest patches), when the opensta
receives an http page with https links, it transforms
the link like http://{ ..., which is correct by opensta
implementation. The problem is that IE escapes '{' by
'%7D' and the gateway does not understand http://%7D,
so the capture stops by 'page not found'.

Hisashi Iwashimizu wrote that it is after applying
MS04-004 
 security patch to IE6. 

I did some tests with Mozilla and it worked fine
(because no escape code). 

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

>Comment By: Daniel Sutcliffe (dansut)
Date: 2005-06-15 12:18

Message:
Logged In: YES 
user_id=19748

mvemers wrote:
> This problem seems to have re-occurred - IE is showing %7B
> in the location bar again:

This actually doesn't mean that this bug has re-occurred,
the fix to this problem was to allow the gateway to
understand the urlencoded form of the { character as well. 
It is only a problem if you cannot record HTTPS because of
this...

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

Comment By: Mark Vevers (mvevers)
Date: 2005-06-15 11:26

Message:
Logged In: YES 
user_id=13500

This problem seems to have re-occurred - IE is showing %7B
in the location bar again:

gwhttp.dll: 1.4.3.6 
IE Version:  6.0.2900.2180.xpsp_sp2_gdr.050301-1519

Any suggestions?

Thanks


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

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-01-24 13:37

Message:
Logged In: YES 
user_id=19748

And addendum to this fix has been merged into the CVS HEAD.
The case were a Location: header was specified from the root
during a HTTPS redirect was not dealt with.  Thanks to Thierry
for spotting this.  This will be included in the OpenSTA 1.4.3
release.

gwhttp.dll: 1.4.3.5
OpenSTA: 1.4.3.18

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-20 17:29

Message:
Logged In: YES 
user_id=19748

The most recently mentioned fix has been merged into the CVS
HEAD.  It will become generally available in the OpenSTA 1.4.3
release.

gwhttp.dll: 1.4.3.4
OpenSTA: 1.4.3.13

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-20 14:33

Message:
Logged In: YES 
user_id=19748

I now have a "proper" fix for this that treats the URL encoded
version of { (which is %7b not %7d as Alain initially reported)
as equivilant to the {.

The fix had to be extended with a little fudge because it
uncovered and issue with IE and redirects.  This is best shown
by an example:  If I go to record https://osta.lan/mail/ I'll 
get http://{osta.lan/mail/ which the new "fixed" IE will rewrite
to http://%7Bosta.lan/mail/ - this will work fine, but if the
Web server then returns with a HTTP 302 and "Location:
src/login.php" then IE will get confused and try to redirect to
http://%7Bosta.lanan/mail/src/login.php - obviously the extra
2 chars and the domain name changing length confuse IE.  It
is unlikely that anyone in the "real world" will find this IE
buglet so I worked around it by having the gateway rewrite
the "Location:" header so that it is always fully specified for
SSL recordings (the recording .all gets the original value).

I was convinced this was something the gateway was doing
wrong for a long while but hours spent with a sniffer and
tests with other browsers showed that it was IE.

The fix also "enhances" the console and trace output from
the gateway.

This gateway code is ugly...

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

Comment By: John L (johnleij)
Date: 2004-09-21 13:34

Message:
Logged In: YES 
user_id=999135

Hi all,

As I wasn't able to build OpenSTA due to lack of access to 
required third party tools, I binary patched the product. I'm 
not sure whether the license gives me the rights to distribute 
the patch, but I gather that it is for everybodys' best if I at 
least inform you of what I did.

I binary patched gwhttp.dll to make it work with SSL even 
after security patch MS04-004 on Internet Explorer 6.

The idea is to replace the ordinary "http://{" sequence 
with "http://-" so that IE doesn't destroy the URL when it is 
UrlEncoded. Note that this quick and dirty fix will make 
OpenSTA stop working with sites that begin with '-' (not very 
common though).

In gwhttp.dll I patched:
- Changed "http://{" to "http://-" (address ~00029380h)
- Changed "{" to "-" (address ~00029c40h)

I could write a long disclaimer here to inform you that I can't 
guarantee that the patch works, but I think you already know 
that. The patch surely seems to work for me.


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

Comment By: jmrwnd (jmrwnd)
Date: 2004-09-21 09:23

Message:
Logged In: YES 
user_id=1125756

Has johnleij's fix been implemented anywhere, and is there 
any way to get this alternate version of the code?  I am 
unable to alter and build the source code myself and need a 
workaround for this problem ASAP.  I absolutely must test 
with IE6 or Netscape 6, but both escape the '{' character.

If all else fails, is there another similar tool that could record 
https traffic with these browsers that could run off of a 
laptop?  Any help is greatly appreciated.  Thanks.

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

Comment By: John L (johnleij)
Date: 2004-03-16 09:28

Message:
Logged In: YES 
user_id=999135

A possible quick-fix could be to change the implementation of 
OpenSTA so that instead of using "http://{" to identify SSL, 
we could use "http://-". The latter isn't common on the 
internet and is not tampered with by MSIE.

A search through the source code gave me the idea to chage 
the value of constants CYRANO_SSL_URL and 
CYRANO_SSL_STR in HttpGateway\gwhttp\context.hpp to 
reflect this.

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

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

[OpenSTA-devel] [ opensta-Bugs-897856 ] Recording HTTPS fails because newer IE escapes URL

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

Bugs item #897856, was opened at 2004-02-16 07:43
Message generated for change (Comment added) made by mvevers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=897856&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Capture
Group: Serious
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alain Ribault (ribault)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Recording HTTPS fails because newer IE escapes URL

Initial Comment:
HTTPS recording :
With my browser (IE6, latest patches), when the opensta
receives an http page with https links, it transforms
the link like http://{ ..., which is correct by opensta
implementation. The problem is that IE escapes '{' by
'%7D' and the gateway does not understand http://%7D,
so the capture stops by 'page not found'.

Hisashi Iwashimizu wrote that it is after applying
MS04-004 
 security patch to IE6. 

I did some tests with Mozilla and it worked fine
(because no escape code). 

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

Comment By: Mark Vevers (mvevers)
Date: 2005-06-15 15:26

Message:
Logged In: YES 
user_id=13500

This problem seems to have re-occurred - IE is showing %7B
in the location bar again:

gwhttp.dll: 1.4.3.6 
IE Version:  6.0.2900.2180.xpsp_sp2_gdr.050301-1519

Any suggestions?

Thanks


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

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-01-24 18:37

Message:
Logged In: YES 
user_id=19748

And addendum to this fix has been merged into the CVS HEAD.
The case were a Location: header was specified from the root
during a HTTPS redirect was not dealt with.  Thanks to Thierry
for spotting this.  This will be included in the OpenSTA 1.4.3
release.

gwhttp.dll: 1.4.3.5
OpenSTA: 1.4.3.18

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-20 22:29

Message:
Logged In: YES 
user_id=19748

The most recently mentioned fix has been merged into the CVS
HEAD.  It will become generally available in the OpenSTA 1.4.3
release.

gwhttp.dll: 1.4.3.4
OpenSTA: 1.4.3.13

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-20 19:33

Message:
Logged In: YES 
user_id=19748

I now have a "proper" fix for this that treats the URL encoded
version of { (which is %7b not %7d as Alain initially reported)
as equivilant to the {.

The fix had to be extended with a little fudge because it
uncovered and issue with IE and redirects.  This is best shown
by an example:  If I go to record https://osta.lan/mail/ I'll 
get http://{osta.lan/mail/ which the new "fixed" IE will rewrite
to http://%7Bosta.lan/mail/ - this will work fine, but if the
Web server then returns with a HTTP 302 and "Location:
src/login.php" then IE will get confused and try to redirect to
http://%7Bosta.lanan/mail/src/login.php - obviously the extra
2 chars and the domain name changing length confuse IE.  It
is unlikely that anyone in the "real world" will find this IE
buglet so I worked around it by having the gateway rewrite
the "Location:" header so that it is always fully specified for
SSL recordings (the recording .all gets the original value).

I was convinced this was something the gateway was doing
wrong for a long while but hours spent with a sniffer and
tests with other browsers showed that it was IE.

The fix also "enhances" the console and trace output from
the gateway.

This gateway code is ugly...

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

Comment By: John L (johnleij)
Date: 2004-09-21 17:34

Message:
Logged In: YES 
user_id=999135

Hi all,

As I wasn't able to build OpenSTA due to lack of access to 
required third party tools, I binary patched the product. I'm 
not sure whether the license gives me the rights to distribute 
the patch, but I gather that it is for everybodys' best if I at 
least inform you of what I did.

I binary patched gwhttp.dll to make it work with SSL even 
after security patch MS04-004 on Internet Explorer 6.

The idea is to replace the ordinary "http://{" sequence 
with "http://-" so that IE doesn't destroy the URL when it is 
UrlEncoded. Note that this quick and dirty fix will make 
OpenSTA stop working with sites that begin with '-' (not very 
common though).

In gwhttp.dll I patched:
- Changed "http://{" to "http://-" (address ~00029380h)
- Changed "{" to "-" (address ~00029c40h)

I could write a long disclaimer here to inform you that I can't 
guarantee that the patch works, but I think you already know 
that. The patch surely seems to work for me.


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

Comment By: jmrwnd (jmrwnd)
Date: 2004-09-21 13:23

Message:
Logged In: YES 
user_id=1125756

Has johnleij's fix been implemented anywhere, and is there 
any way to get this alternate version of the code?  I am 
unable to alter and build the source code myself and need a 
workaround for this problem ASAP.  I absolutely must test 
with IE6 or Netscape 6, but both escape the '{' character.

If all else fails, is there another similar tool that could record 
https traffic with these browsers that could run off of a 
laptop?  Any help is greatly appreciated.  Thanks.

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

Comment By: John L (johnleij)
Date: 2004-03-16 14:28

Message:
Logged In: YES 
user_id=999135

A possible quick-fix could be to change the implementation of 
OpenSTA so that instead of using "http://{" to identify SSL, 
we could use "http://-". The latter isn't common on the 
internet and is not tampered with by MSIE.

A search through the source code gave me the idea to chage 
the value of constants CYRANO_SSL_URL and 
CYRANO_SSL_STR in HttpGateway\gwhttp\context.hpp to 
reflect this.

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

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

[OpenSTA-devel] [ opensta-Bugs-1205532 ] Recordings of large POST bodies have missing chars in SCL

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Script Language
Group: Serious
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Thierry Boullet (tboullet)
Assigned to: Daniel Sutcliffe (dansut)
>Summary: Recordings of large POST bodies have missing chars in SCL

Initial Comment:
With OpenSTA 1.4.3, during the creation of a script,
the large SCL literal strings (as the body of a request
POST) are cut out in several blocks which are then
concatenated.

The problem is that one character is removed for each
concatenation.

With OpenSTA 1.4.2, the SCL literal string is for example :
       POST URI "http://....
       ...
       , BODY
"................................................." &
       ...
      
"..............................................................."
&
      
"....................................................uvwxyz"
&
      
"abcd........................................................"
&
       ...

With OpenSTA 1.4.3, the literal string is now :
       POST URI "http://....
       ...
       , BODY
"................................................." &
       ...
       ...
      
"..............................................................."
+ &
      
"....................................................uvwxy"
&
      
"abcd........................................................"
&
       ...
The last character ('z') of the line after the
concatenation misses.

Daniel thinks that it is the fix of the bug #637865
which introduced this.
http://sourceforge.net/tracker/index.php?func=detail&aid=637865&group_id=10857&atid=110857


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

>Comment By: Daniel Sutcliffe (dansut)
Date: 2005-06-13 17:20

Message:
Logged In: YES 
user_id=19748

A fix for this issue has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.4 release.

tof2scl.dll: 1.4.4.2
OpenSTA: 1.4.4.2

Attached to this bug report is the updated DLL built for the
1.4.3 release of OpenSTA.  Use in place of existing DLL to
get fixed behavior.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-06-12 10:47

Message:
Logged In: YES 
user_id=19748

Problem is in theTof2Scl DLL.
New behaviour where long quoted character strings are broken
down into concatenated chunks loses a character whenever the
string split is made.
The issue has been tracked down to be in the
SclWriter::ValidateString() routine - when the beginning
quote character is added to the new string at the split
point it is not counted and therefore causes too much to be
consumed of the work string and a char lost.  A fix is
imminent...

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

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

[OpenSTA-devel] [ opensta-Bugs-1205532 ] Loss of characters caused by concatenating large SCL String

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Script Language
Group: Serious
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Thierry Boullet (tboullet)
>Assigned to: Daniel Sutcliffe (dansut)
Summary: Loss of characters caused by concatenating large SCL String

Initial Comment:
With OpenSTA 1.4.3, during the creation of a script,
the large SCL literal strings (as the body of a request
POST) are cut out in several blocks which are then
concatenated.

The problem is that one character is removed for each
concatenation.

With OpenSTA 1.4.2, the SCL literal string is for example :
       POST URI "http://....
       ...
       , BODY
"................................................." &
       ...
      
"..............................................................."
&
      
"....................................................uvwxyz"
&
      
"abcd........................................................"
&
       ...

With OpenSTA 1.4.3, the literal string is now :
       POST URI "http://....
       ...
       , BODY
"................................................." &
       ...
       ...
      
"..............................................................."
+ &
      
"....................................................uvwxy"
&
      
"abcd........................................................"
&
       ...
The last character ('z') of the line after the
concatenation misses.

Daniel thinks that it is the fix of the bug #637865
which introduced this.
http://sourceforge.net/tracker/index.php?func=detail&aid=637865&group_id=10857&atid=110857


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

>Comment By: Daniel Sutcliffe (dansut)
Date: 2005-06-12 10:47

Message:
Logged In: YES 
user_id=19748

Problem is in theTof2Scl DLL.
New behaviour where long quoted character strings are broken
down into concatenated chunks loses a character whenever the
string split is made.
The issue has been tracked down to be in the
SclWriter::ValidateString() routine - when the beginning
quote character is added to the new string at the split
point it is not counted and therefore causes too much to be
consumed of the work string and a char lost.  A fix is
imminent...

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

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

RE: [OpenSTA-devel] Re: Charlie J Hewett's document on SCL

[Hewett, C. J <cha...@in...>]

~NEG_EXP_DIST is an "undocumented feature".  Here is an explanation of
what it basically does (assuming no one has changed it):

~NEG_EXP_DIST(random, mean), where "random" is a random integer between
1-2^31, and "mean" is an integer value representing the mean for the
distribution.  The return value is calculated by -[ln(random / (2^31)) *
mean * 100], where 100 is a scaling factor to retain precision.  To walk
through this, the integer random value is scaled down to a number
between 0-1, then the natural log is taken, then it is multiplied by the
mean value and the scaling factor.  Finally, the number is converted to
a positive value.  Assuming that the mean time is entered in seconds,
the result values will have 10ms precision (e.g. 500 for 5 seconds).
This function should be valuable because it is how arrival times are
often calculated.

Specifically, I needed this function to conform to the TPC-W
(www.tpc.org/tpcw/) specification for Think Time, which is the amount of
time between the Virtual Users browse to the next page.  The TPC-W spec
states that:
"Each Think Time must be taken independently from a negative exponential
distribution. Each Think Time,
T, must be computed from the following equation:
T =3D - ln(r) * ?
where:
ln =3D natural log (base e)
r =3D random number, with at least 31 bits of precision, from a uniform
distribution such that (0 < r < 1)
? =3D 7 to 8 seconds inclusive"

Basically, if you look at the distribution it creates, it is a bell
curve around 7 seconds.  So most of the wait (think) times will be
around 7 seconds plus or minus a few seconds, but there are some
outliers which are very fast or very slow (e.g. someone clicks to the
next page quickly or spends a lot of time reading a page).  This is more
realistic than just a strictly random number.

Here's what Richard Clarke sent to me in a previous e-mail:
"FYI I have incorporated these changes into the 'stable' 1.0 branch of
OpenSTA. They will appear in OpenSTA 1.0.2, which we expect to be
available next week (wc 30-Apr-01). The bitwise operators have been
documented, but not the ~NEG_EXP_DIST function. The implementation of
the latter is currently unchanged from your original code. In order to
make it more general, we may make some modifications in the future (I
will consult you before making any changes)."

If you go through the OpenSTA-devel archives to posts in 2001, there is
more discussion (especially between Richard Clarke and me) of adding
operators and functions.

Hope this helps,
-Charlie


-----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Daniel
Sutcliffe
Sent: Thursday, June 09, 2005 8:22 AM
To: ope...@li...
Subject: [OpenSTA-devel] Re: Charlie J Hewett's document on SCL

Ash Ashbhai wrote:
> > > Has anyone got a copy of the documents by Charlie mentioned in
> > > the below thread?
> > >
http://sourceforge.net/mailarchive/forum.php?thread_id=3D1094644&forum_id=
=3D
4764

This email mentions a zip file containing 3 docs - I've searched
through my archives and can only find a zip file containing 1 Word
document ... this contains instructions on adding a bitwise OR (%)
operator and the ~NEG_EXP_DIST() function ...
=20
Thierry Boullet wrote:
> > The last post of Charlie contains the instructions for adding an
integer
> > function to SCL (NEG_EXP_DIST_FUNC):
> >   http://sourceforge.net/mailarchive/message.php?msg_id=3D11783362
> >   (RE: Duration of the viewstate encoding - 2005-05-17)
>
> Thanks.  I missed that thread.

The instructions given in this email are the same as the latter half
of the document I have...  Interestingly enough ~NEG_EXP_DIST is
implemented in the current OpenSTA - but there is no mention of it
in the documentation!  Here's what the comments in the code say:
  ;  The NEG_EXP_DIST function has the following format:
  ;    ~NEG_EXP_DIST(random, mean)
  ;  where 'random' and 'mean' are integer operands. The
  ;  function returns an INTEGER value.=20
Here's the bit that does the actual work:
  //Calculation of negative exponential distribution
  // make value range from {(1/2147493647):1}
  temp =3D (double)nedrand / 2147483647.0;
      // (2^31) - 1 is the max value (range 1-2147483647)
  int reslt =3D (int)(-(log(temp) * nedmean));
      // scaling factor set to 1000 (to keep higher resolution on
result)
I'm not sure what specific use this has but maybe it is useful to
someone out there... Maybe if Charlie has the time he can fill us in.
I'll document it for the next release of the SCL Reference.

The bitwise OR operator that Charlie documented implenting looks like
it was included into the source very differently.  There are a
bitwise XOR(^) and IOR(|), and the % was given to the modulo
operator.

I'm going to drop both of these into the Wiki so we can find them
easier and add to them as we work out more about this area.  I'll
reply with a link once I've done this.

> Can you please point me in the right direction on where can I get
> more documentation on using tpg.exe?  Like how to write
> subexpressions...

ROTFL :-)

Richard Clarke was the only one of the team that really knew his way
around the legacy code that was used for the SCL parsing - and he
seems to be "missing".

What I do know is that the parsing mechanism is derived from the
OpenVMS TPARSE routines - so maybe looking for some online VMS TPARSE
documentation may help.  There will be actual TPG documentation
somewhere (from the Performance Software days) but even if I had this
documentation (which I don't) the chances are that I wouldn't legally
be able to make this available...

The other possibility is that if Malcolm Green is listening in here,
and is feeling generous :-)  He could perhaps provide us some clues
as to where to look for information and how different the PSL TPG is
from the original OpenVMS equivalent... please.

Other than that, it really is a matter of working it out for
ourselves... if we work together and document as we go then that
shouldn't be too difficult, the TPA files seem very well commented.

Ash: may I ask what you'd like to add to SCL?  And make sure that you
are willing to donate your work back to the product... ?  If you
aren't willing to give back to the community then it is difficult to
justify spending too much time helping you (or anyone) out. :-)

Hope this info helps,
Cheers
/dan
--=20
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
shotput
a projector? How fast can you ride your desk chair down the office luge
track?
If you want to score the big prize, get to know the little guy. =20
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
_______________________________________________
OpenSTA-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensta-devel

[OpenSTA-devel] [ opensta-Bugs-1216593 ] out of memory while trying to show results

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

Bugs item #1216593, was opened at 2005-06-07 14:08
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1216593&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Results Analysis
Group: Fatal Error
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: javier_dba (javier_dba)
Assigned to: Nobody/Anonymous (nobody)
Summary: out of memory while trying to show results

Initial Comment:
Out of memory error appears while trying to show 
"HTTP Responses v Elapsed time".
Test was done successfully ramping 400 vusers along 1 
hour. 
Attached a zip file containing:
- picture with the error.
- test file
- script file
- output from dir command of Repository folder
- zipped Scripts folder from Repository
- zipped ObjectCode folder from Repository
- zipped ArchMgr folder from Repository
- zipped Profiles folder from Repository

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

>Comment By: Daniel Sutcliffe (dansut)
Date: 2005-06-09 11:52

Message:
Logged In: YES 
user_id=19748

This is a duplicate report of  bug# 1013510 and thus will be
deleted.

I will download the zip file and attach it to this earlier bug.

For future reference please discuss issues on the Users
Mailing List before posting as new bugs - this helps clarify
the issue and can avoid it being created as a duplicate in
the system and wasting time.

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

Comment By: javier_dba (javier_dba)
Date: 2005-06-07 14:10

Message:
Logged In: YES 
user_id=1292886

More information:
Ten computers generating load, sharing the repository, one 
commanding the load.
Used OpenSTA 1.4.2 and 1.4.3. Both versions have the same 
behaviour "out of memory".

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

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

[OpenSTA-devel] [ opensta-Bugs-1013510 ] Blank graphs or TestPlugin errors from bad results analysis

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

Bugs item #1013510, was opened at 2004-08-21 15:44
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1013510&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Results Analysis
Group: Fatal Error
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Blank graphs or TestPlugin errors from bad results analysis

Initial Comment:
A large result set from a test may cause issues when
trying to view graphs (the results analysis phase). 
When this happens the results graphs are empty or an
"Out of memory" can be shown.  This issue seems to
occur more with the graphs that are "v Elapsed Time"
but not exclusively so.  All reports have been with
large result sets.

The issues also may not occur the first time you view
your results but once it has happened it will not go
away on its own.  Deleting the HttpStats.cache and
Combined_HTTPDataFile.dat will cause your results to be
analysed again and may help avoid the problem in your
specific instance.

This problem seems to happen more if your test did not
finish cleanly, either through another problem or
through user aborting during the run.  Monitoring
results whilst the test is running also seems to
increase the chance of this happening.

A sure sign that you have a problem is the TestPlugin
process using up large amounts of memory or CPU.  If an
"Out of memory" condition is reported it will come from
this TestPlugin process.

Please add any more useful information to this bug
report.  We are specifically interested in a simple
consistent way of reproducing this error and/or small
resultsets which are known to cause the error.

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

>Comment By: Daniel Sutcliffe (dansut)
Date: 2005-06-09 11:51

Message:
Logged In: YES 
user_id=19748

From deleted bug#1216593 by javier_dba:
Out of memory error appears while trying to show
"HTTP Responses v Elapsed time".
Test was done successfully ramping 400 vusers along 1
hour.
Attached a zip file ResultsAnalysisCrash.zip containing:
- picture with the error.
- test file
- script file
- output from dir command of Repository folder
- zipped Scripts folder from Repository
- zipped ObjectCode folder from Repository
- zipped ArchMgr folder from Repository
- zipped Profiles folder from Repository

Ten computers generating load, sharing the repository, one
commanding the load. Used OpenSTA 1.4.2 and 1.4.3. Both
versions have the same behaviour "out of memory".

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-13 07:48

Message:
Logged In: YES 
user_id=19748

The results analysis phase has multiple problems -
especially when
dealing with large result sets.  Instead of filing multiple
bug reports
please add any useful and concrete information here that may
help
us get to the bottom of this.

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

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

[OpenSTA-devel] Re: Charlie J Hewett's document on SCL

[Daniel S. <da...@Op...>]

Ash Ashbhai wrote:
> > > Has anyone got a copy of the documents by Charlie mentioned in
> > > the below thread?
> > >   http://sourceforge.net/mailarchive/forum.php?thread_id=1094644&forum_id=4764

This email mentions a zip file containing 3 docs - I've searched
through my archives and can only find a zip file containing 1 Word
document ... this contains instructions on adding a bitwise OR (%)
operator and the ~NEG_EXP_DIST() function ...
 
Thierry Boullet wrote:
> > The last post of Charlie contains the instructions for adding an integer
> > function to SCL (NEG_EXP_DIST_FUNC):
> >   http://sourceforge.net/mailarchive/message.php?msg_id=11783362
> >   (RE: Duration of the viewstate encoding - 2005-05-17)
>
> Thanks.  I missed that thread.

The instructions given in this email are the same as the latter half
of the document I have...  Interestingly enough ~NEG_EXP_DIST is
implemented in the current OpenSTA - but there is no mention of it
in the documentation!  Here's what the comments in the code say:
  ;  The NEG_EXP_DIST function has the following format:
  ;    ~NEG_EXP_DIST(random, mean)
  ;  where 'random' and 'mean' are integer operands. The
  ;  function returns an INTEGER value. 
Here's the bit that does the actual work:
  //Calculation of negative exponential distribution
  // make value range from {(1/2147493647):1}
  temp = (double)nedrand / 2147483647.0;
      // (2^31) - 1 is the max value (range 1-2147483647)
  int reslt = (int)(-(log(temp) * nedmean));
      // scaling factor set to 1000 (to keep higher resolution on result)
I'm not sure what specific use this has but maybe it is useful to
someone out there... Maybe if Charlie has the time he can fill us in.
I'll document it for the next release of the SCL Reference.

The bitwise OR operator that Charlie documented implenting looks like
it was included into the source very differently.  There are a
bitwise XOR(^) and IOR(|), and the % was given to the modulo
operator.

I'm going to drop both of these into the Wiki so we can find them
easier and add to them as we work out more about this area.  I'll
reply with a link once I've done this.

> Can you please point me in the right direction on where can I get
> more documentation on using tpg.exe?  Like how to write
> subexpressions...

ROTFL :-)

Richard Clarke was the only one of the team that really knew his way
around the legacy code that was used for the SCL parsing - and he
seems to be "missing".

What I do know is that the parsing mechanism is derived from the
OpenVMS TPARSE routines - so maybe looking for some online VMS TPARSE
documentation may help.  There will be actual TPG documentation
somewhere (from the Performance Software days) but even if I had this
documentation (which I don't) the chances are that I wouldn't legally
be able to make this available...

The other possibility is that if Malcolm Green is listening in here,
and is feeling generous :-)  He could perhaps provide us some clues
as to where to look for information and how different the PSL TPG is
from the original OpenVMS equivalent... please.

Other than that, it really is a matter of working it out for
ourselves... if we work together and document as we go then that
shouldn't be too difficult, the TPA files seem very well commented.

Ash: may I ask what you'd like to add to SCL?  And make sure that you
are willing to donate your work back to the product... ?  If you
aren't willing to give back to the community then it is difficult to
justify spending too much time helping you (or anyone) out. :-)

Hope this info helps,
Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] [ opensta-Bugs-1216593 ] out of memory while trying to show results

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

Bugs item #1216593, was opened at 2005-06-07 18:08
Message generated for change (Comment added) made by javier_dba
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1216593&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Results Analysis
Group: Fatal Error
Status: Open
Resolution: None
Priority: 5
Submitted By: javier_dba (javier_dba)
Assigned to: Nobody/Anonymous (nobody)
Summary: out of memory while trying to show results

Initial Comment:
Out of memory error appears while trying to show 
"HTTP Responses v Elapsed time".
Test was done successfully ramping 400 vusers along 1 
hour. 
Attached a zip file containing:
- picture with the error.
- test file
- script file
- output from dir command of Repository folder
- zipped Scripts folder from Repository
- zipped ObjectCode folder from Repository
- zipped ArchMgr folder from Repository
- zipped Profiles folder from Repository

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

>Comment By: javier_dba (javier_dba)
Date: 2005-06-07 18:10

Message:
Logged In: YES 
user_id=1292886

More information:
Ten computers generating load, sharing the repository, one 
commanding the load.
Used OpenSTA 1.4.2 and 1.4.3. Both versions have the same 
behaviour "out of memory".

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

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

[OpenSTA-devel] [ opensta-Bugs-1216593 ] out of memory while trying to show results

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

Bugs item #1216593, was opened at 2005-06-07 18:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1216593&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Results Analysis
Group: Fatal Error
Status: Open
Resolution: None
Priority: 5
Submitted By: javier_dba (javier_dba)
Assigned to: Nobody/Anonymous (nobody)
Summary: out of memory while trying to show results

Initial Comment:
Out of memory error appears while trying to show 
"HTTP Responses v Elapsed time".
Test was done successfully ramping 400 vusers along 1 
hour. 
Attached a zip file containing:
- picture with the error.
- test file
- script file
- output from dir command of Repository folder
- zipped Scripts folder from Repository
- zipped ObjectCode folder from Repository
- zipped ArchMgr folder from Repository
- zipped Profiles folder from Repository

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

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

Re: [OpenSTA-devel] Charlie J Hewett's document on SCL

[Ash A. <as...@gm...>]

Thanks. I missed that thread.
Can you please point me in the right direction on where can I get more
documentation on using tpg.exe? Like how to write subexpressions...
Ashok

On 6/7/05, Thierry Boullet <thi...@ke...> wrote:
> Ash Ashbhai wrote:
>=20
> >Hi list,
> >Has anyone got a copy of the documents by Charlie mentioned in the below=
 thread?
> >http://sourceforge.net/mailarchive/forum.php?thread_id=3D1094644&forum_i=
d=3D4764
> >If so please send them to me.
> >Thanks.
> >Ashok Srivastava
> >
> >
> Hi,
>=20
> The last post of Charlie contains the instructions for adding an integer
> function to SCL (NEG_EXP_DIST_FUNC) :
> http://sourceforge.net/mailarchive/message.php?msg_id=3D11783362 (RE:
> Duration of the viewstate encoding - 2005-05-17)
>=20
> Thierry
>=20
> Thierry Boullet
> www.kereval.com
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you sho=
tput
> a projector? How fast can you ride your desk chair down the office luge t=
rack?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> _______________________________________________
> OpenSTA-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensta-devel
>

Re: [OpenSTA-devel] Charlie J Hewett's document on SCL

[Thierry B. <thi...@ke...>]

Ash Ashbhai wrote:

>Hi list,
>Has anyone got a copy of the documents by Charlie mentioned in the below thread?
>http://sourceforge.net/mailarchive/forum.php?thread_id=1094644&forum_id=4764
>If so please send them to me.
>Thanks.
>Ashok Srivastava
>  
>
Hi,

The last post of Charlie contains the instructions for adding an integer 
function to SCL (NEG_EXP_DIST_FUNC) :
http://sourceforge.net/mailarchive/message.php?msg_id=11783362 (RE: 
Duration of the viewstate encoding - 2005-05-17)

Thierry

Thierry Boullet
www.kereval.com

[OpenSTA-devel] Charlie J Hewett's document on SCL

[Ash A. <as...@gm...>]

Hi list,
Has anyone got a copy of the documents by Charlie mentioned in the below th=
read?
http://sourceforge.net/mailarchive/forum.php?thread_id=3D1094644&forum_id=
=3D4764
If so please send them to me.
Thanks.
Ashok Srivastava

[OpenSTA-devel] [ opensta-Bugs-1083975 ] Concatenating large SCL strings can cause compiler to crash

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

Bugs item #1083975, was opened at 2004-12-12 20:44
Message generated for change (Comment added) made by tboullet
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1083975&group_id=10857

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Script Language
Group: Crash
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Concatenating large SCL strings can cause compiler to crash

Initial Comment:
Concatenating VERY large SCL strings can cause the compiler
to crash and leave invalid (incomplete) compiled TOF
files in
place.  This is usually done to work around the SCL
limits on
max variable size - specifically when dealing with
multipart/form-data file uploads.  In fact, recent changes
mean the SCL generated by a recording may show this
problem.

An example of the problem code is
...
    ,BODY "A very very long sequence of chars" &
...
             "probably more than 50K worth" + &
          "Another huge string of similar size to" &
...
             "cause the issue"

There does seem to be a workaround.  Place your BODY
contents in character variables and then concatenate thus:
...
    SET BODYCONT1="A very very long sequence of chars" &
...
             "probably more than 50K worth"
    SET BODYCONT2="Another huge string of similar size
to" &
...
             "cause the issue"
...
    ,BODY BODYCONT1 + BODYCONT2

More investigation required to find actual boundaries and
cause of this problem.

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

>Comment By: Thierry Boullet (tboullet)
Date: 2005-06-06 19:13

Message:
Logged In: YES 
user_id=949869

I reproduced this bug during the use of OpenSTA 1.4.2 with
large viewstate.
I made additional tests, here the description and the results:

OS : Windows XP Pro SP2 with last updates

SCRIPT_65850_142 : script captured with 1.4.2 containing a
literal string with 65850 chars (body of a POST request, 1
block)

SCRIPT_65850_143 : script captured with 1.4.3 containing a
literal string with 65850 chars (3 blocks with 2 concatenations)

SCRIPT_96970_142 : script captured with 1.4.2 containing a
literal string with 96970 chars (body of a POST request, 1
block)

SCRIPT_96970_143 : script captured with 1.4.3 containing a
literal string with 96970 chars (3 blocks with 2 concatenations)

SCRIPT_65850_142 and SCRIPT_96970_142 compiled in Script
Modeler 1.4.2 or 1.4.3 => error maxstrlen (that's normal)
SCRIPT_65850_143 compiled in Script Modeler 1.4.2 or 1.4.3
=> success (that's "normal" and has been the previous
workaround for the large BODY problems of the past)
SCRIPT_96970_143 compiled in Script Modeler 1.4.2 or 1.4.3
=> crash of scl.exe (see attached file)

I built another version of OpenSTA which is based on the
1.4.3 with the following modifications:
   - file \src\Architecture\Scl\scl_limits.h:
       #define MAX_VARIABLE_SIZE   262143 (Maximum size of a
variable or record)
       #define MAX_LITERAL_SIZE    262143 (Maximum size of a
character literal or constant)
   - file \src\Architecture\Scl\scl_tpacom.h :
       #define MAX_CONSTANT_SIZE 262143 (Max size of
constants area)
       #define CHRBUFSIZ 262144 (Character string storage)

The new limits of 256K that I used are arbitrary.

Role of MAX_VARIABLE_SIZE :
for example : CHARACTER*70000    STR_TMP
                     => error (modoutrange), Character
Modifier Out of Range. Valid Range 1 to 65535

Role of MAX_LITERAL_SIZE :
for example : "A very very long sequence of chars more than 64K"
                     => error (maxstrlen), Maximum String
Length Limit Exceeded

Role of MAX_CONSTANT_SIZE :
It's the limit of space available for all the constant
values defined in the script and in the included files.
for example : definition of many large constants (> 64K)
                     => error (consoverflow), Constants Data
Area Overflow

Role of CHRBUFSIZ  :
for example : if a string is > CHRBUFSIZ, crash of scl.exe

The constant MAX_STRING_LEN in the file
\src\Architecture\Scl\scl_comdef.h is not used.

With this version, results are :

SCRIPT_65850_142 and SCRIPT_96970_142 compiled in Script
Modeler => success
SCRIPT_65850_143 compiled in Script Modeler => success
SCRIPT_96970_143 compiled in Script Modeler => success

The use of variables > 64k functions correctly (DOM
Addressing, encoding, use in the body of a POST).
I think that it is a track to exceed the limit of the 64K
when that is really necessary.


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

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-05-10 21:46

Message:
Logged In: YES 
user_id=19748

Quite a few fixes in this area and I now can't reproduce -
leaving the bug open though just to let people know it is
possible.  If you see this issue on an OpenSTA installation
newer than 1.4.2 then please comment on this bug report.

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

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

[OpenSTA-devel] Re: Duration of the viewstate encoding

[Daniel S. <da...@Op...>]

Daniel Sutcliffe wrote:
> > Once I get my build going I'll be sure to post some similar test
> > results...  Could you provide the viewstate strings for others
> > to download?

Thierry Boullet wrote:
> I can provide the scripts and the HTML pages with the different 
> viewstate which I used for the measurements.
> That the interested people contact me (I will not be able to answer
> you during the next week).
> Could the OpenSTA portal provide a space for this kind of data to
> test OpenSTA?

Make them available to me and I'll find a home for this sort of file
somewhere on opensta.org

> > If you read my other posting though I'd rather not add a new
> > command to SCL though - I think that FORMAT can be extended to
> > provide this (and other) functionality in a flexible and clean way.
> >
> > Your thoughts.  I'd really like to see this done for the next
> > release as I believe it can provide very useful fuctionality and
> > increased speed...
> 
> I agree to extend the function FORMAT.
> I will study the information provided by Charlie to see how to add
> the encoding in the command FORMAT.

I don't think you'll need Charlie's info for this - although I'm sure
it'll prove useful in time ...

> Any suggestions for syntax to use?

Well, FORMAT currently has %U, %L, and %D - I see this simply a
matter of assigning more letters to be the extra translations we want
to provide.  The first one is obviously to "url encode", following
from this I think that a "url decode" should be available.  Then
there are things like "base64" and the ability to do better date/time
formatting as been asked for...

I'm not sure if we can use upper and lower case % letters - or how
feasible it would be to use a more complex syntax (like sprintf).
The only real restriction we have is to make sure that existing
scripts will produce the same results... if you want to do this then
let us know what you think the possibilities are and how far you'd
like to take it.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] Re: Can anybody help me to build OpenSTA project?

[Daniel S. <da...@Op...>]

Ury wrote:
> I'm download OSTA 1.4.3 source code and unable to compile it.  Can
> you help me?
> 
> Problems:
> 1. I'm download and install omniORB_304.tar.tar, but the VC can't
>    find header files corbaidl_defs.hh

This is an OmniORB build issue - it does work you just need to follow
their instructions carefully.  If you continue to have problems then
you are best asking for help of the OmniORB developers.  All I can
say is that following the instructions (ours and theirs) allows it to
build without a problem.

> 2. I'm unable to download Bison/Flex.
>    Path ftp://sunsite.dk/projects/crystal/support/msvc/bison_flex/
>    requires authentication.

Works for me just now...

> 3. Lot of errors on compilling like that:
>    Generating stubs from .\XMLRelayTestRun.idl
>    The system cannot find the path specified.
>    Error executing c:\windows\system32\cmd.exe.

If you haven't got OmniORB working/built then of course you will have
issues compiling the IDLs ...

> At all: It is possible to find OpenSTA source package whith all
> prerequired and 3hd party sources together?

It would be impossible to do this and comply with the various
packages licenses - which is why we don't do it.  Also it would be
huge ...

It's not easy to put together the correct build environment for
OpenSTA, but hopefully it'll be getting easier soon.  Until than all
you can really do is to make sure you follow the instructions in the
Wiki to the letter:
  http://portal.opensta.org/faq.php?topic=BuildingPrerequisites

Check this mailing lists messages and archives for information on how
you can deviate slightly from the instructions.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] Re: [ opensta-Bugs-1083975 ] Concatenating large SCL strings can cause compiler to crash

[Daniel S. <da...@Op...>]

> > Can you attach the script that reproduces the crash to the problem
> > report?  I'm not sure if you can as a normal user... if you can't,
> > then I think it's about time we got you added as a member of the
> > OpenSTA SF project... if you want?

Thierry Boullet wrote:
> Yes, I can attach the scripts to the report but as a normal user I 
> cannot do it.

You should be able to do it now.  I'll post more on this issue once 
I've had chance to give it a good look at.

> Thank you for your proposal to add me as a member to the OpenSTA SF
> project.  I am interested to become member as a developer and a
> tester.  My SF login is tboullet.

Let me officially welcome you as the first new OpenSTA project member
in a long time :-)  OpenSTA trully is entering a new era.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] Re: New content lost bug

[Daniel S. <da...@Op...>]

Thierry Boullet wrote:
> Ok, I created this bug with a link back to the old one.

Thanks Thierry,

I'll be working on this bug (#1205532):
  http://sourceforge.net/tracker/index.php?func=detail&aid=1205532&group_id=10857&atid=110857
as a matter of some urgency this week.

Hopefully we'll have a fixed version by the end of the week that
also uses an updated build environment.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] Can anybody help me to build OpenSTA project?

[Ury <ur...@bs...>]

Hi

I'm download OSTA 1.4.3 source code and unable to compile it. Can you
help me?

Problems:
1. I'm download and install omniORB_304.tar.tar, but the VC cant find
header files corbaidl_defs.hh
2. I'm unable to download Bison/Flex.
Path ftp://sunsite.dk/projects/crystal/support/msvc/bison_flex/
requires authentication.
3. Lot of errors on compilling like that:
Generating stubs from .\XMLRelayTestRun.idl
The system cannot find the path specified.
Error executing c:\windows\system32\cmd.exe.

At all: It is possible to find OpenSTA source package whith all
prerequired and 3hd party sources together?


Regards