opensta-devel — OpenSTA developer discussions

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

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

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?
>  
>
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?

>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.
Any suggestions for syntax to use?

Thierry


Thierry Boullet
www.kereval.com

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

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

Hewett, Charlie J wrote:

>Hello,
>
>I haven't done much work with OpenSTA lately, but at some point, I did
>create a new function in OpenSTA.  Some things may have changed since
>3-4 years ago, but I saved a description of the steps I took to add a
>new function to SCL.  It's quite a few steps, but most of them are
>simple.  The hardest part was trying to figure out files in which I
>needed to make changes--hopefully this helps with that...  Please see
>below.
>
>The following are instructions for adding an integer function to SCL.
>The example here is specifically the steps to create an integer function
>NEG_EXP_DIST.
>
>1)  Modify the parse source file.
>
>File:		..\scl\scl_sub_tbl.tpa
>What to do:	Add the following code to function INTEGER_FUNC to add
>support for another function:
>	PSL$TRAN	!NEG_EXP_DIST_FUNC,	PSLTPA_EXIT
>
>Create the function subexpression (e.g. NEG_EXP_DIST_FUNC).  Look at the
>LOCATE_FUNC for example.  Remember that the number of parameters may be
>different, as well as the parameter data type.
>
>2)  Define the new functions used in NEG_EXP_DIST_FUNC.
>
>File:		..\scl\scl_sub_tbl_rtndef.h
>What to do:	Specify the two new functions.
>unsigned long INI_NEG_EXP_DIST (struct tpaarg *);
>unsigned long SAVE_FNC_NEG_EXP_DIST (struct tpaarg *);
>
>File:		..\scl\scl_sav_routines.c
>What to do:	Create SAVE_FNC_NEG_EXP_DIST based on SAVE_FNC_LOCATE.
>
>File:		..\scl\scl_ini_routines.c
>What to do:	Create INI_NEG_EXP_DIST based on (exactly copy of)
>INI_LOCATE.
>
>3)  Define TOF_FNCID_NEG_EXP_DIST variable used in SAVE_FNC_NEG_EXP_DIST
>function in scl_sav_routines.c.
>
>File:		..\include\tofprmdef.h
>What to do:	Add/change the following definitions:
>#define TOF_FNCID_NEG_EXP_DIST	3  // 2+1 to account for the new
>function
>static char *TOF_FNCNAM[] = {
>"Illegal function",
>"~LOCATE",
>"~EXTRACT",
>"~NEG_EXP_DIST"};
>
>4)  Define the runtime functions.
>
>File:		..\TestProcess\Common\Base\CECTofTxt.h
>What to do:	Add the following definitions of the functions:
>bool _evaluateFncNegExpDist(TContext& ctxt,
>list<CECOperand>::const_iterator* itP,
>string* resstrP) const;
>
>bool _psFncNegExpDist (const string& inStr, int* pos, const bool updpos
>= true);
>
>File:		..\TestProcess\Common\Base\CECTofTxt.cpp
>What to do:	Add the following code to the switch statement in
>function _evaluateOpd:
>case fnc_negexpdist:	    // ~NEG_EXP_DIST function
>{
>_evaluateFncNegExpDist(ctxt, itP, &fncVal);
>break;
>}
>
>Create _evaluateFncNegExpDist based on CECTofTxt::_evaluateFncLocate.
>
>		Add the following statement to CECTofTxt::_psIntFnc:
>	if (_psFncNegExpDist(inStr, pos, updpos)) return true;
>
>		Create _psFncNegExpDist based on
>CECTofTxt::_psFncLocate.
>
>Define the ps_fnc_negexpdist variable used in the _psFncNegExpDist
>function:
>const string ps_fnc_ negexpdist	= "~NEG_EXP_DIST";  // Function
>~NEG_EXP_DIST
>
>5)  Modify code to create a null operand object.
>
>File:		..\TestProcess\Common\Base\CECOperand.h
>What to do:	Add the following code to the switch statement in the
>CECOperand constructor:
>case fnc_negexpdist:
>_dTyp = dtyp_integer;
>break;
>
>6)  For diagnostic purposes, modify two files. 
>
>File:		..\TestProcess\Common\Base\CECOperand.h
>What to do:	Modify the following code to include the new function:
>enum FncCode {fnc_none, fnc_negexpdist, fnc_locate, fnc_extract};
>
>File:		CECOperand.cpp
>What to do:	Add the following code to the switch statement:
>case fnc_negexpdist:
>val_fnc = "~NegExpDist";
>break;
>
>7)  Rebuild the Architecture and HTTP directories and create a new .msi
>installer file.
>
>Thanks,
>-Charlie
>  
>
Thank you very much Charlie for this procedure.
That's with this kind of information that we can better know the 
mechanisms of development of OpenSTA and thus to make it evolve.

Thierry


Thierry Boullet
www.kereval.com

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

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

Daniel Sutcliffe wrote:

>>Role of MAX_CONSTANT_SIZE :
>>for example : definition of many large constants (> 64K)
>>=> error (consoverflow), Constants Data Area Overflow    
>>
>This is an odd one.  So the MAX_CONSTANT_SIZE is the limit of space
>available for all the constants together?  I don't remember that
>being how it is documented.
>  
>
Yes, MAX_CONSTANT_SIZE (Max size of constants area) is the limit of 
space available for all the constant values defined in the script and in 
the included files. 

>>Role of CHRBUFSIZ  :
>>for example : if a string is > CHRBUFSIZ, crash of scl.exe
>>    
>>
>This tells me that what we should have is something like:
>  #define MAX_VARIABLE_SIZE X
>  #define MAX_LITERAL_SIZE X
>  #define CHRBUFSIZ X*N
>Where N give us the room to play around.
>  
>
It is also my opinion.

>And obviously we need some sensible behavior when CHRBUFSIZ is
>overflowed.
>
>I also want to know where bug#1083968 comes into play - my thought
>is that not all content is equal and further encoding will increase
>the actual size of a string... ?
>
>What I don't understand is why I couldn't reproduce this problem if
>it was simply a matter of overflowing CHRBUFSIZ!  I was able to
>record and compile some HUGE file uploads during my testing - it was
>slow but it worked.
>  
>
I think that the cause of the crash of scl.exe is not as simple as a 
size of string which exceeds CHRBUFSIZ.
scl.exe must be studied more in detail in particular how CHRBUFSIZ is used.

>Maybe in the case of providing POST bodies - but this makes for
>really ugly scripts.  It would be nicer to be able to take the 
>POST body from a file or something.
>
>My one worry about increasing the maximum size of a variable is just
>really moving the goal posts - plus if people have these large
>variables they are likely to use them without thought and then
>complain about runtime memory usage without a thought to it being
>there own fault.  I can see large variables being of real use in
>functional testing but in the performance testing that is supposed to
>be the focus of OpenSTA they really ought to be avoided and
>discoraged.
>
>IMHO the real solution to interrogating returned HTTP data larger
>than 64K is a more flexible identifier addressing mechanism.  This
>could provide a full solution whilst still being performance oriented
>...
>  
>
These are interesting suggestions.

>>The new limits of 256K that I used are arbitrary.  These limits
>>should be configurable.
>>    
>>
>Do you mean easily configurable at the compilation level - or
>something that can be changed from the user level?
>  
>
The limit of 64K can be preserved by default, but the user should be 
able to change this limit (reduction or increase) while being sensitized 
with the consequences.

>>For example to detect size too large of POST request body, which can be the cause of bad performances.
>>    
>>
>One thing I'd like to see is runtime warnings generated everytime
>content that is too big is assigned to a character variable and
>needs to be truncated.  I think this would be really useful, although
>I'm not sure if it is what you meant with this last sentence.
>  
>
This is the kind of solution which can be used to detect too big data 
during the test.

>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?
>  
>
Yes, I can attach the scripts to the report but as a normal user I 
cannot do it.
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.

Thierry


Thierry Boullet
www.kereval.com

Re: [OpenSTA-devel] New content lost bug - Was: [ opensta-Bugs-1083975 ] Concatenating large SCL strings can cause compiler to crash

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

Daniel Sutcliffe wrote:

>Thierry Boullet wrote:
>  
>
>>During this test, I noted a new issue : one character is removed for 
>>each concatenation.
>>With OpenSTA 1.4.2, the SCL literal string is for example :
>>       ...
>>       "..............................................................." &
>>       "....................................................uvwxyz" &
>>       "abcd........................................................" &
>>       ...
>>
>>With OpenSTA 1.4.3, the literal string is now :
>>       ...
>>"..............................................................." + &
>>   "....................................................uvwxy" &
>>       "abcd........................................................" &
>>       ...
>>The last character ('z') of the line after the concatenation misses.
>>I hope that this example will make it possible to detect the cause of 
>>the problem.
>>    
>>
>Rats! :-(
>I thought I'd been very careful about testing this - obviously not
>careful enough.  Can this be reproduced by simply uploading a text
>file over 64K in length?
>  
>
As you probably understood it, the literal string is the body of a POST 
(form with large viewstate).
I created HTML pages containing a form with several sizes of viewstate.
That's with these pages that I made scripts which contain this problem.
I can directly send you these HTML pages to help you to reproduce this 
error.

>It's either a matter of making a new issue or I'll re-open bug#637865
>which is the fix where I inevitably introduced this...
>  http://sourceforge.net/tracker/index.php?func=detail&aid=637865&group_id=10857&atid=110857
>I think a new bug but with a link back to the old one is the way to
>go.
>  
>
Ok, I created this bug with a link back to the old one.

Thierry


Thierry Boullet
www.kereval.com

[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 11:44
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=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: None
Priority: 5
Submitted By: Thierry Boullet (tboullet)
Assigned to: Nobody/Anonymous (nobody)
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


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

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

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

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

Thierry Boullet wrote:
> I made some measurements of the duration of the viewstate encoding 
> because I noted that it is not negligible and that it can disturb
> the tests.

Yet again Thierry - fantastic work, it's much appreciated.
Just a few comments.

> I used 3 versions of OpenSTA :
>   OSTA142 : Release 1.4.2
>   OSTA143 : Release 1.4.3
>   MYOSTA  : based on release 1.4.3 and built with VC++ 6 SP6,
>             Platform SDK February 2003, CodeMax 2.1.0.22,
>             OmniORB 3.0.4, SizeCBar 2.44, STLPort 4.6 and
>             ucd-snmp 4.2.6.

It was always my intention that the very first thing we do after
getting 1.4.3 out was to get a build done with an updated build
setup.  To this end I've just done putting this environment together:
  VC++ 6sp6
  Latest Platform SDK - Windows Server 2003sp1
  CodeMax 2.1.0.24 - difficult to get very few changes from 2.1.0.22
  OmniOrb 3.0.5 - not sure if worth the update - want to look at 4.0
  SizeCBar 2.44
  STLPort 4.6.2
  net-snmp 4.2.6 - want to look at 5.x

Your environment looks like it's +ve proof that we can make this work
and the results ...

[snip results]

> The version MYOSTA is almost twice faster than Releases 1.4.2/1.4.3.

As if having a build environment that was easy to get hold of wasn't
enough of a reason to update... real speed improvements are awesome!

> The differences seem to be the PSDK and STLport.

That would be my thought too... I suspected we'd get some
improvements but your results are a real pleasent surprise.

> It would be interesting to confirm these results in order to use
> the versions of the products which improve the speed of OpenSTA.

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?

> In any event I think that it is necessary to add an SCL command
> which encode a string to the format "x-www-form-urlencoded".

I posted about just this thing to the Users list the other day:
  http://sourceforge.net/mailarchive/message.php?msg_id=11768133

> This coding is typical to provide variables to a POST request
> (viewstate or others).
> I think that a native command would be much faster than a SCL
> subroutine.

And is very commonly required...

> I can develop this functionality.  I would wish to know if somebody
> knows the method to add a new SCL command or if other possibilities
> can be considered.

When I first saw this post I immediately thought ofthe write up by
Charlie...  and then he posted it.   Good to see that you're still
around Charlie and thanks for posting your write up.

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...

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

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

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

Hello,

I haven't done much work with OpenSTA lately, but at some point, I did
create a new function in OpenSTA.  Some things may have changed since
3-4 years ago, but I saved a description of the steps I took to add a
new function to SCL.  It's quite a few steps, but most of them are
simple.  The hardest part was trying to figure out files in which I
needed to make changes--hopefully this helps with that...  Please see
below.

The following are instructions for adding an integer function to SCL.
The example here is specifically the steps to create an integer function
NEG_EXP_DIST.

1)  Modify the parse source file.

File:		..\scl\scl_sub_tbl.tpa
What to do:	Add the following code to function INTEGER_FUNC to add
support for another function:
	PSL$TRAN	!NEG_EXP_DIST_FUNC,	PSLTPA_EXIT

Create the function subexpression (e.g. NEG_EXP_DIST_FUNC).  Look at the
LOCATE_FUNC for example.  Remember that the number of parameters may be
different, as well as the parameter data type.

2)  Define the new functions used in NEG_EXP_DIST_FUNC.

File:		..\scl\scl_sub_tbl_rtndef.h
What to do:	Specify the two new functions.
unsigned long INI_NEG_EXP_DIST (struct tpaarg *);
unsigned long SAVE_FNC_NEG_EXP_DIST (struct tpaarg *);

File:		..\scl\scl_sav_routines.c
What to do:	Create SAVE_FNC_NEG_EXP_DIST based on SAVE_FNC_LOCATE.

File:		..\scl\scl_ini_routines.c
What to do:	Create INI_NEG_EXP_DIST based on (exactly copy of)
INI_LOCATE.

3)  Define TOF_FNCID_NEG_EXP_DIST variable used in SAVE_FNC_NEG_EXP_DIST
function in scl_sav_routines.c.

File:		..\include\tofprmdef.h
What to do:	Add/change the following definitions:
#define TOF_FNCID_NEG_EXP_DIST	3  // 2+1 to account for the new
function
static char *TOF_FNCNAM[] =3D {
"Illegal function",
"~LOCATE",
"~EXTRACT",
"~NEG_EXP_DIST"};

4)  Define the runtime functions.

File:		..\TestProcess\Common\Base\CECTofTxt.h
What to do:	Add the following definitions of the functions:
bool _evaluateFncNegExpDist(TContext& ctxt,
list<CECOperand>::const_iterator* itP,
string* resstrP) const;

bool _psFncNegExpDist (const string& inStr, int* pos, const bool updpos
=3D true);

File:		..\TestProcess\Common\Base\CECTofTxt.cpp
What to do:	Add the following code to the switch statement in
function _evaluateOpd:
case fnc_negexpdist:	    // ~NEG_EXP_DIST function
{
_evaluateFncNegExpDist(ctxt, itP, &fncVal);
break;
}

Create _evaluateFncNegExpDist based on CECTofTxt::_evaluateFncLocate.

		Add the following statement to CECTofTxt::_psIntFnc:
	if (_psFncNegExpDist(inStr, pos, updpos)) return true;

		Create _psFncNegExpDist based on
CECTofTxt::_psFncLocate.

Define the ps_fnc_negexpdist variable used in the _psFncNegExpDist
function:
const string ps_fnc_ negexpdist	=3D "~NEG_EXP_DIST";  // Function
~NEG_EXP_DIST

5)  Modify code to create a null operand object.

File:		..\TestProcess\Common\Base\CECOperand.h
What to do:	Add the following code to the switch statement in the
CECOperand constructor:
case fnc_negexpdist:
_dTyp =3D dtyp_integer;
break;

6)  For diagnostic purposes, modify two files.=20

File:		..\TestProcess\Common\Base\CECOperand.h
What to do:	Modify the following code to include the new function:
enum FncCode {fnc_none, fnc_negexpdist, fnc_locate, fnc_extract};

File:		CECOperand.cpp
What to do:	Add the following code to the switch statement:
case fnc_negexpdist:
val_fnc =3D "~NegExpDist";
break;

7)  Rebuild the Architecture and HTTP directories and create a new .msi
installer file.

Thanks,
-Charlie

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Thierry
Boullet
Sent: Tuesday, May 17, 2005 6:09 AM
To: ope...@li...
Subject: [OpenSTA-devel] Duration of the viewstate encoding

Hi,

I made some measurements of the duration of the viewstate encoding=20
because I noted that it is not negligible and that it can disturb the
tests.

I used 3 versions of OpenSTA :
    OSTA142 : Release 1.4.2
    OSTA143 : Release 1.4.3
    MYOSTA : based on release 1.4.3 and built with VC++ 6 SP6, Platform=20
SDK February 2003, CodeMax 2.1.0.22,
                        OmniORB 3.0.4, SizeCBar 2.44, STLPort 4.6 and=20
ucd-snmp 4.2.6.

I used 2 methods of encoding and 2 types of viewstate (resulting from an

application which I tested) to make measurements:

METHOD1 : This is the method described in the FAQ of OpenSTA
************************************************************************
**
SUBROUTINE URLENCODE [ SB_URL ]

    CONTINUE1:
    Set SB_INDEX =3D ~LOCATE("+",SB_URL)
    IF (SB_INDEX<>-1) THEN
        Set SB_INDEX2 =3D SB_INDEX + 1
        Set SB_URL =3D ~EXTRACT(0,SB_INDEX,SB_URL) + "%2B" &
            + ~EXTRACT(SB_INDEX2,65500,SB_URL)
        goto CONTINUE1
    ENDIF

    CONTINUE2:
    Set SB_INDEX =3D ~LOCATE("/",SB_URL)
    IF (SB_INDEX<>-1) THEN
        Set SB_INDEX2 =3D SB_INDEX + 1
        Set SB_URL =3D ~EXTRACT(0,SB_INDEX,SB_URL) + "%2F" &
            + ~EXTRACT(SB_INDEX2,65500,SB_URL)
        goto CONTINUE2
    ENDIF

    CONTINUE3:
    Set SB_INDEX =3D ~LOCATE("=3D",SB_URL)
    IF (SB_INDEX<>-1) THEN
        Set SB_INDEX2 =3D SB_INDEX + 1
        Set SB_URL =3D ~EXTRACT(0,SB_INDEX,SB_URL) + "%3D" &
            + ~EXTRACT(SB_INDEX2,65500,SB_URL)
        goto CONTINUE3
    ENDIF

END SUBROUTINE
************************************************************************
**


METHOD2 : This is the method which I use.
************************************************************************
**
SUBROUTINE FORM_URL_ENCODE [ STR_TO_ENC ]

    SET STR_LENGTH =3D ~LENGTH(STR_TO_ENC)
    SET STR_TMP =3D ""
      =20
    LOOP_PLUS:
    SET STR_OFFSET =3D ~LOCATE("+",STR_TO_ENC)
    IF (STR_OFFSET <> -1) THEN
        SET STR_TMP =3D STR_TMP + ~LEFTSTR(STR_OFFSET, STR_TO_ENC) + =
"%2B"
        SET STR_LENGTH =3D STR_LENGTH - STR_OFFSET -1
        SET STR_TO_ENC =3D ~RIGHTSTR (STR_LENGTH, STR_TO_ENC)
        GOTO LOOP_PLUS
    ENDIF
    IF (STR_TMP <> "") THEN
        SET STR_TO_ENC =3D STR_TMP + STR_TO_ENC
    ENDIF
      =20
    SET STR_LENGTH =3D ~LENGTH(STR_TO_ENC)
    SET STR_TMP =3D ""
  =20
    LOOP_SLASH:
    SET STR_OFFSET =3D ~LOCATE("/",STR_TO_ENC)
    IF (STR_OFFSET <> -1) THEN
        SET STR_TMP =3D STR_TMP + ~LEFTSTR(STR_OFFSET, STR_TO_ENC) + =
"%2F"
        SET STR_LENGTH =3D STR_LENGTH - STR_OFFSET -1
        SET STR_TO_ENC =3D ~RIGHTSTR (STR_LENGTH, STR_TO_ENC)
        GOTO LOOP_SLASH
    ENDIF
    IF (STR_TMP <> "") THEN
        SET STR_TO_ENC =3D STR_TMP + STR_TO_ENC
    ENDIF  =20

    SET STR_LENGTH =3D ~LENGTH(STR_TO_ENC)
    SET STR_TMP =3D ""
  =20
    LOOP_EQUAL:
    SET STR_OFFSET =3D ~LOCATE("=3D",STR_TO_ENC)
    IF (STR_OFFSET <> -1) THEN
        SET STR_TMP =3D STR_TMP + ~LEFTSTR(STR_OFFSET, STR_TO_ENC) + =
"%3D"
        SET STR_LENGTH =3D STR_LENGTH - STR_OFFSET -1
        SET STR_TO_ENC =3D ~RIGHTSTR (STR_LENGTH, STR_TO_ENC)
        GOTO LOOP_EQUAL
    ENDIF
    IF (STR_TMP <> "") THEN
        SET STR_TO_ENC =3D STR_TMP + STR_TO_ENC
    ENDIF  =20
  =20
END SUBROUTINE
************************************************************************
**

VIEWSTATE1 :
Size before encoding : 62936
1203 '+', 2 '/', 2 '=3D'
Size after encoding : 65350

VIEWSTATE2 :
Size before encoding : 64928
233 '+', 1 '/', 0 '=3D'
Size after encoding : 65396

My configuration :
Pentium 4, 2,66 GHz
RAM 512 Mo
OS : Windows XP Pro SP2

Results (duration of encoding for 1 VU) :

VIEWSTATE1 with METHOD1 :
    - OSTA142 and OSTA143 : 6,5 s
    - MYOSTA : 3,3 s

VIEWSTATE1 with METHOD2 :
    - OSTA142 and OSTA143 : 5,3 s
    - MYOSTA : 2,7 s

VIEWSTATE2 with METHOD1 :
    - OSTA142 and OSTA143 : 1,3 s
    - MYOSTA : 0,5 s

VIEWSTATE2 with METHOD2 :
    - OSTA142 and OSTA143 : 1,15 s
    - MYOSTA : 0,6 s

I took voluntarily large viewstate for measurements. (Like Antony=20
Marcano said within his article, applications with viewstate too large=20
should be interpreted as an early warning of some potentially serious=20
performance issues.) Even with smaller viewstate I noted than the total=20
duration of the coding of several viewstate in a script is not=20
negligible and appreciably increases the execution time of a script.

METHOD2 is a little faster than METHOD1.

The version MYOSTA is almost twice faster than Releases 1.4.2/1.4.3. The

differences seem to be the PSDK and STLport.
During the tests, I used for each measurement the same repository, the=20
same scripts and the same configuration of OpenSTA.
It would be interesting to confirm these results in order to use the=20
versions of the products which improve the speed of OpenSTA.

In any event I think that it is necessary to add an SCL command which=20
encode a string to the format "x-www-form-urlencoded".
This coding is typical to provide variables to a POST request (viewstate

or others).
I think that a native command would be much faster than a SCL
subroutine.

I can develop this functionality. I would wish to know if somebody knows

the method to add a new SCL command or if other possibilities can be=20
considered.

Any suggestions?

Thierry


Thierry Boullet
www.kereval.com



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick
_______________________________________________
OpenSTA-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensta-devel

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

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

Thierry Boullet wrote:
> Thanks Dan for this new release.  This is great news.

Well it was, in no small part, made possible by work put in by you,
so I return the Thanks to you and agree that is great news.  It will
be made greater if I can maintain the momentum and get another
release (1.4.4) out in the next month or so...

> I reproduced this bug during the use of OpenSTA 1.4.2 with large
> viewstate.

As I hinted in the bug report - I suspected this bug was not dead,
I'm glad that you have confirmed this and hopefully we can reproduce
and fix it properly.

It is probably worth looking into bug#1083968:
  http://sourceforge.net/tracker/index.php?func=detail&aid=1083968&group_id=10857&atid=110857
while we are investigating this area.  This problem is where the
compiler gives the MAXSTRLEN error even though the string is less
than 64K in length...  this problem was the reason I just didn't
split the strings into 64K chunks for my fix for bug#637865 - and
probably why I ended up not fixing that properly...

> 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 (Is this normal since total size of the string > 65535?)

That is "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

This is definitely bug#1083975 I experienced and logged and then
couldn't reproduce.

> 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)
> 
> 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 :
> for example : definition of many large constants (> 64K)
> => error (consoverflow), Constants Data Area Overflow

This is an odd one.  So the MAX_CONSTANT_SIZE is the limit of space
available for all the constants together?  I don't remember that
being how it is documented.

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

This tells me that what we should have is something like:
  #define MAX_VARIABLE_SIZE X
  #define MAX_LITERAL_SIZE X
  #define CHRBUFSIZ X*N
Where N give us the room to play around.
And obviously we need some sensible behavior when CHRBUFSIZ is
overflowed.

I also want to know where bug#1083968 comes into play - my thought
is that not all content is equal and further encoding will increase
the actual size of a string... ?

What I don't understand is why I couldn't reproduce this problem if
it was simply a matter of overflowing CHRBUFSIZ!  I was able to
record and compile some HUGE file uploads during my testing - it was
slow but it worked.
 
> The constant MAX_STRING_LEN in the file 
> \src\Architecture\Scl\scl_comdef.h is not used.

Nice - I guess we just need to get rid of this then.

> 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 know of a few people who'd really like to get their hands on your
new build... ;-)

> I think that it is a track to exceed the limit of the 64K when that
> is really necessary.

Maybe in the case of providing POST bodies - but this makes for
really ugly scripts.  It would be nicer to be able to take the 
POST body from a file or something.

My one worry about increasing the maximum size of a variable is just
really moving the goal posts - plus if people have these large
variables they are likely to use them without thought and then
complain about runtime memory usage without a thought to it being
there own fault.  I can see large variables being of real use in
functional testing but in the performance testing that is supposed to
be the focus of OpenSTA they really ought to be avoided and
discoraged.

IMHO the real solution to interrogating returned HTTP data larger
than 64K is a more flexible identifier addressing mechanism.  This
could provide a full solution whilst still being performance oriented
...

> The new limits of 256K that I used are arbitrary.  These limits
> should be configurable.

Do you mean easily configurable at the compilation level - or
something that can be changed from the user level?

> For example to detect size too large of POST request body, which
> can be the cause of bad performances.

One thing I'd like to see is runtime warnings generated everytime
content that is too big is assigned to a character variable and
needs to be truncated.  I think this would be really useful, although
I'm not sure if it is what you meant with this last sentence.

> I will add a comment for the bug 1083975.

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?

It would be great to get this and the other new issue fixed quickly
and then we can make a new release with the updated build
environment and these fixes out and heavily beta'd so 1.4.4 can
happen in the next couple of months.

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

[OpenSTA-devel] New content lost bug - Was: [ opensta-Bugs-1083975 ] Concatenating large SCL strings can cause compiler to crash

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

Thierry Boullet wrote:
> During this test, I noted a new issue : one character is removed for 
> each concatenation.
> With OpenSTA 1.4.2, the SCL literal string is for example :
>        ...
>        "..............................................................." &
>        "....................................................uvwxyz" &
>        "abcd........................................................" &
>        ...
> 
> With OpenSTA 1.4.3, the literal string is now :
>        ...
> "..............................................................." + &
>    "....................................................uvwxy" &
>        "abcd........................................................" &
>        ...
> The last character ('z') of the line after the concatenation misses.
> I hope that this example will make it possible to detect the cause of 
> the problem.

Rats! :-(
I thought I'd been very careful about testing this - obviously not
careful enough.  Can this be reproduced by simply uploading a text
file over 64K in length?

I guess I need to get my test cases out.o
This is upsetting because it makes my fix a bit of a no-fix if it
loses a byte every 64K :-(

> Is it necessary to create another bug for this new problem?

It's either a matter of making a new issue or I'll re-open bug#637865
which is the fix where I inevitably introduced this...
  http://sourceforge.net/tracker/index.php?func=detail&aid=637865&group_id=10857&atid=110857
I think a new bug but with a link back to the old one is the way to
go.

Thanks Thierry; as usual, you are a star!
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] Duration of the viewstate encoding

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

Hi,

I made some measurements of the duration of the viewstate encoding 
because I noted that it is not negligible and that it can disturb the tests.

I used 3 versions of OpenSTA :
    OSTA142 : Release 1.4.2
    OSTA143 : Release 1.4.3
    MYOSTA : based on release 1.4.3 and built with VC++ 6 SP6, Platform 
SDK February 2003, CodeMax 2.1.0.22,
                        OmniORB 3.0.4, SizeCBar 2.44, STLPort 4.6 and 
ucd-snmp 4.2.6.

I used 2 methods of encoding and 2 types of viewstate (resulting from an 
application which I tested) to make measurements:

METHOD1 : This is the method described in the FAQ of OpenSTA
**************************************************************************
SUBROUTINE URLENCODE [ SB_URL ]

    CONTINUE1:
    Set SB_INDEX = ~LOCATE("+",SB_URL)
    IF (SB_INDEX<>-1) THEN
        Set SB_INDEX2 = SB_INDEX + 1
        Set SB_URL = ~EXTRACT(0,SB_INDEX,SB_URL) + "%2B" &
            + ~EXTRACT(SB_INDEX2,65500,SB_URL)
        goto CONTINUE1
    ENDIF

    CONTINUE2:
    Set SB_INDEX = ~LOCATE("/",SB_URL)
    IF (SB_INDEX<>-1) THEN
        Set SB_INDEX2 = SB_INDEX + 1
        Set SB_URL = ~EXTRACT(0,SB_INDEX,SB_URL) + "%2F" &
            + ~EXTRACT(SB_INDEX2,65500,SB_URL)
        goto CONTINUE2
    ENDIF

    CONTINUE3:
    Set SB_INDEX = ~LOCATE("=",SB_URL)
    IF (SB_INDEX<>-1) THEN
        Set SB_INDEX2 = SB_INDEX + 1
        Set SB_URL = ~EXTRACT(0,SB_INDEX,SB_URL) + "%3D" &
            + ~EXTRACT(SB_INDEX2,65500,SB_URL)
        goto CONTINUE3
    ENDIF

END SUBROUTINE
**************************************************************************


METHOD2 : This is the method which I use.
**************************************************************************
SUBROUTINE FORM_URL_ENCODE [ STR_TO_ENC ]

    SET STR_LENGTH = ~LENGTH(STR_TO_ENC)
    SET STR_TMP = ""
       
    LOOP_PLUS:
    SET STR_OFFSET = ~LOCATE("+",STR_TO_ENC)
    IF (STR_OFFSET <> -1) THEN
        SET STR_TMP = STR_TMP + ~LEFTSTR(STR_OFFSET, STR_TO_ENC) + "%2B"
        SET STR_LENGTH = STR_LENGTH - STR_OFFSET -1
        SET STR_TO_ENC = ~RIGHTSTR (STR_LENGTH, STR_TO_ENC)
        GOTO LOOP_PLUS
    ENDIF
    IF (STR_TMP <> "") THEN
        SET STR_TO_ENC = STR_TMP + STR_TO_ENC
    ENDIF
       
    SET STR_LENGTH = ~LENGTH(STR_TO_ENC)
    SET STR_TMP = ""
   
    LOOP_SLASH:
    SET STR_OFFSET = ~LOCATE("/",STR_TO_ENC)
    IF (STR_OFFSET <> -1) THEN
        SET STR_TMP = STR_TMP + ~LEFTSTR(STR_OFFSET, STR_TO_ENC) + "%2F"
        SET STR_LENGTH = STR_LENGTH - STR_OFFSET -1
        SET STR_TO_ENC = ~RIGHTSTR (STR_LENGTH, STR_TO_ENC)
        GOTO LOOP_SLASH
    ENDIF
    IF (STR_TMP <> "") THEN
        SET STR_TO_ENC = STR_TMP + STR_TO_ENC
    ENDIF   

    SET STR_LENGTH = ~LENGTH(STR_TO_ENC)
    SET STR_TMP = ""
   
    LOOP_EQUAL:
    SET STR_OFFSET = ~LOCATE("=",STR_TO_ENC)
    IF (STR_OFFSET <> -1) THEN
        SET STR_TMP = STR_TMP + ~LEFTSTR(STR_OFFSET, STR_TO_ENC) + "%3D"
        SET STR_LENGTH = STR_LENGTH - STR_OFFSET -1
        SET STR_TO_ENC = ~RIGHTSTR (STR_LENGTH, STR_TO_ENC)
        GOTO LOOP_EQUAL
    ENDIF
    IF (STR_TMP <> "") THEN
        SET STR_TO_ENC = STR_TMP + STR_TO_ENC
    ENDIF   
   
END SUBROUTINE
**************************************************************************

VIEWSTATE1 :
Size before encoding : 62936
1203 '+', 2 '/', 2 '='
Size after encoding : 65350

VIEWSTATE2 :
Size before encoding : 64928
233 '+', 1 '/', 0 '='
Size after encoding : 65396

My configuration :
Pentium 4, 2,66 GHz
RAM 512 Mo
OS : Windows XP Pro SP2

Results (duration of encoding for 1 VU) :

VIEWSTATE1 with METHOD1 :
    - OSTA142 and OSTA143 : 6,5 s
    - MYOSTA : 3,3 s

VIEWSTATE1 with METHOD2 :
    - OSTA142 and OSTA143 : 5,3 s
    - MYOSTA : 2,7 s

VIEWSTATE2 with METHOD1 :
    - OSTA142 and OSTA143 : 1,3 s
    - MYOSTA : 0,5 s

VIEWSTATE2 with METHOD2 :
    - OSTA142 and OSTA143 : 1,15 s
    - MYOSTA : 0,6 s

I took voluntarily large viewstate for measurements. (Like Antony 
Marcano said within his article, applications with viewstate too large 
should be interpreted as an early warning of some potentially serious 
performance issues.) Even with smaller viewstate I noted than the total 
duration of the coding of several viewstate in a script is not 
negligible and appreciably increases the execution time of a script.

METHOD2 is a little faster than METHOD1.

The version MYOSTA is almost twice faster than Releases 1.4.2/1.4.3. The 
differences seem to be the PSDK and STLport.
During the tests, I used for each measurement the same repository, the 
same scripts and the same configuration of OpenSTA.
It would be interesting to confirm these results in order to use the 
versions of the products which improve the speed of OpenSTA.

In any event I think that it is necessary to add an SCL command which 
encode a string to the format "x-www-form-urlencoded".
This coding is typical to provide variables to a POST request (viewstate 
or others).
I think that a native command would be much faster than a SCL subroutine.

I can develop this functionality. I would wish to know if somebody knows 
the method to add a new SCL command or if other possibilities can be 
considered.

Any suggestions?

Thierry


Thierry Boullet
www.kereval.com

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

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

>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: Daniel Sutcliffe (dansut)    
>>
>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.
>  
>
Thanks Dan for this new release. This is great news.

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 
(Is this normal since total size of the string > 65535?)
SCRIPT_96970_143 compiled in Script Modeler 1.4.2 or 1.4.3 => crash of 
scl.exe

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)

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 :
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.

The new limits of 256K that I used are arbitrary. These limits should be 
configurable.
For example to detect size too large of POST request body, which can be 
the cause of bad performances.


During this test, I noted a new issue : one character is removed for 
each concatenation.
With OpenSTA 1.4.2, the SCL literal string is for example :
        ...
        "..............................................................." &
        "....................................................uvwxyz" &
        "abcd........................................................" &
        ...

With OpenSTA 1.4.3, the literal string is now :
        ...
        
"..............................................................." + &
    "....................................................uvwxy" &
        "abcd........................................................" &
        ...
The last character ('z') of the line after the concatenation misses.
I hope that this example will make it possible to detect the cause of 
the problem.

I will add a comment for the bug 1083975. Is it necessary to create 
another bug for this new problem?

Thierry



Thierry Boullet
www.kereval.com

[OpenSTA-devel] [ opensta-Bugs-1199408 ] Some SNMP queries always return wrong static answer

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

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

Category: SNMP Monitor
Group: Behavioral
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Some SNMP queries always return wrong static answer

Initial Comment:
This bug report is replacing 2 other existing issues
768782 and 693443.  It seems that certain SNMP queries
willseem to be working - ie they return a value,
however that value will be wrong and always the same. 
This may in fact be the query failing.  The old reports
we have are this:
- all queries of WebLogic 7 SNMP properties return 1
- queries of Solaris 8 CPU return 12
Using snmpget or other similar tools worked correctly
from the same machine in both cases.

SF user nkame came up with this clue after
investigating with a packet sniffer:
"It seems that OpenSTA does't send pure OID as is, and
does some magic. In my case I tried to get
1.3.6.1.4.1.2725.1.3.2, but OpenSTA was requesting
sysUpTime.6.1.4.1.2725.1.3.2, that is it assumed my OID
was relative to the MIB-2 root (1.3.6.1.2.1).  Changing
my requested OID to a "MIB-able" name
(enterprises.2725.1.3.2) solved the problem.  I still
have from time to time a 12 appearing, perhaps due to a
time-out or another non-handled error"

Please add other reports of static and wrong values
returned by SNMP to this bug report rather than opening
any new report.  The more information we have the
sooner we can get to the bottom of this and fix it. 

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

Comment By: Vahan Harput (vharput)
Date: 2005-05-16 16:58

Message:
Logged In: YES 
user_id=27908

Additional info:

The workaround of nkame does not seem work for me. Even
after eplacing the OID with 25.3.3.1.2.2 or host.3.3.1.2.2
in OpenSTA Commander, I still get 12 as a result.


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

Comment By: Vahan Harput (vharput)
Date: 2005-05-16 15:35

Message:
Logged In: YES 
user_id=27908

I can reproduce this bug while trying to retrieve the CPU
load (hrProcessorLoad) from a Win2000 server with the OID:

1.3.6.1.2.1.25.3.3.1.2.2

I always get the result 12.



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

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

[OpenSTA-devel] [ opensta-Bugs-1199408 ] Some SNMP queries always return wrong static answer

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

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

Category: SNMP Monitor
Group: Behavioral
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Some SNMP queries always return wrong static answer

Initial Comment:
This bug report is replacing 2 other existing issues
768782 and 693443.  It seems that certain SNMP queries
willseem to be working - ie they return a value,
however that value will be wrong and always the same. 
This may in fact be the query failing.  The old reports
we have are this:
- all queries of WebLogic 7 SNMP properties return 1
- queries of Solaris 8 CPU return 12
Using snmpget or other similar tools worked correctly
from the same machine in both cases.

SF user nkame came up with this clue after
investigating with a packet sniffer:
"It seems that OpenSTA does't send pure OID as is, and
does some magic. In my case I tried to get
1.3.6.1.4.1.2725.1.3.2, but OpenSTA was requesting
sysUpTime.6.1.4.1.2725.1.3.2, that is it assumed my OID
was relative to the MIB-2 root (1.3.6.1.2.1).  Changing
my requested OID to a "MIB-able" name
(enterprises.2725.1.3.2) solved the problem.  I still
have from time to time a 12 appearing, perhaps due to a
time-out or another non-handled error"

Please add other reports of static and wrong values
returned by SNMP to this bug report rather than opening
any new report.  The more information we have the
sooner we can get to the bottom of this and fix it. 

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

Comment By: Vahan Harput (vharput)
Date: 2005-05-16 15:35

Message:
Logged In: YES 
user_id=27908

I can reproduce this bug while trying to retrieve the CPU
load (hrProcessorLoad) from a Win2000 server with the OID:

1.3.6.1.2.1.25.3.3.1.2.2

I always get the result 12.



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

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

[OpenSTA-devel] OpenSTA 1.4.3 Release

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

Most of you will have seen that I've released 1.4.3 - both from the
announcements and the flurry of bug modifications...

I know I said there would be another beta before this happened...
what can I say, I got fed up of the never ending sequence of delays
and just wanted to move on ;-)

Once I've got BView updated then my next intended step is to make
another MSI with an updated build environment - SDK, STLport, etc.

Thoughts, ideas, comments all welcome,
Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

[OpenSTA-devel] [ opensta-Bugs-1084184 ] % Performance Collector queries are always clipped at 100%

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

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

Category: Performance Monitor
Group: Behavioral
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Shahar Kedar (shahar_kedar)
Assigned to: Daniel Sutcliffe (dansut)
Summary: % Performance Collector queries are always clipped at 100%

Initial Comment:
I'm using an NT Performance collector to collect the CPU 
usage of a certain process.
The problem is that the machine on which the process 
ran, is using a hyper threding CPU. This means that I 
get 100% for that process, although in reality it takes 
only 80% or less. My guess is that OpenSTA collected 
the information from only 1 "virtual processor".

I checked the behavior of the Windows Performace tool, 
and it gives a more reliable number (between the range 
of 0% and 160%).

Can anyone provide me with a workaround? Can this 
behavior be fixed?

Thanks,
Shahar.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2005-01-03 16:43

Message:
Logged In: YES 
user_id=19748

The mentioned fix of removing the cap on % values has been
merged into the CVS HEAD.  This fix will become generally 
available in the OpenSTA 1.4.3 release.

Thanks to Joe Robertson for tracking down this issue and
providing the source code fixes.

TExecuter_ntp.exe 1.4.3.2
OpenSTA 1.4.3.17

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

Comment By: Shahar Kedar (shahar_kedar)
Date: 2004-12-21 01:32

Message:
Logged In: YES 
user_id=1177035

The workaround you suggested is not good enough becasue 
there are some processes that take more than 100%, 
meanning - I have only one instance that taked more than 
100% CPU.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-20 15:41

Message:
Logged In: YES 
user_id=19748

After some investigation this is a known (but up to now
unlogged) bug in that all % Performance Queries are clipped
to %100.

This seems not to be a problem on XP as grouped (_Total)
values of percentage queries seem to be averages rather
than a true total as they were on older Windows versions.

The workaround is to log the seperate instances seperately
and then do the math yourself.

The fix is to OR in PDH_FMT_NOCAP100 with the dwFormat in
the call to PdhGetFormattedCounterValue() in NTPerf/ntp.cpp
in the OpenSTA source.  The concern with this fix is that it
will spoil consistancy and comparability of results between
OpenSTA versions - but as there is no consistancy between
versions of Windows this is probably not a problem.

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

Comment By: Shahar Kedar (shahar_kedar)
Date: 2004-12-20 01:30

Message:
Logged In: YES 
user_id=1177035

This is an entirely different and non-related bug. The bug I'm 
speaking of is that the NT Performance collector doesn't 
know how to collect correct CPU information from Hyper 
Threded CPUs. 

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-13 08:23

Message:
Logged In: YES 
user_id=19748

Is this not the same as (or related to) bug# 746154 ?
Ie. The OpenSTA dialog does not allow you to select a sensible
query because of problems with the dialog used.
Can you get the correct information by "stealing" the correct
query address from the Windows Performance Tool.  I think that
you are using a different(correct) query address when you use
the Windows Performance Tool.

Please add information to bug# 746154 if this proves to be the
case and this bug report will be deleted.  Add more information
here if you think this bug is a seperate issue and deserves a
completely seperate report and fix.

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

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

[OpenSTA-devel] [ opensta-Bugs-1084107 ] Monitoring interval setting not used for Total Active Users

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

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

Category: GUI Issue
Group: Behavioral
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Monitoring interval setting not used for Total Active Users

Initial Comment:
When using the Monitoring tab in the Commander there is a
"Task Monitor Interval" button which allows the
configuration
of "Interval Settings" - the Total Active Users graph
appears
to ignore this and uses fixed values of 5 seconds for
sample
and 2 seconds for refresh. 

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-12 21:02

Message:
Logged In: YES 
user_id=19748

A fix for this issue has been merged into the CVS HEAD. 
This fix
will become generally availlable in the OpenSTA 1.4.3 release.
Thanks to Thierry @ Kereval for providing this fix.

TestManager.exe: 1.4.3.2
MonitoringTabDLL.dll: 1.4.3.3
OpenSTA: 1.4.3.12

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

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

[OpenSTA-devel] [ opensta-Bugs-1049672 ] txt multipart form upload recording creates invalid scripts

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

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

Category: HTTP Capture
Group: Behavioral
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: txt multipart form upload recording creates invalid scripts

Initial Comment:
Trying to record a multipart form uploads of ASCII text
files produces invalid scripts.  The body of the
uploaded file can be invalid for a few reasons, amongst
then being the <CR><LF> pairs are replaced by ^J, <LF>
cause actual line breaks, and other invalid SCL
characters are not escaped properly.

A workaround for some of these issues and details on
other related problems can be found here in the FAQ:
http://portal.opensta.org/faq.php?topic=BugsMultipartForm

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-12 15:56

Message:
Logged In: YES 
user_id=19748

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

Tof2Scl.dll: 1.4.3.2
OpenSTA: 1.4.3.7

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

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

Message:
Logged In: YES 
user_id=19748

Some of the above issue is fixed as part of the fix for
B#637865.

Because of the above change, the data the recording gateway
places in its output TOF file aggravates the possibility
that SCL
could be generated that was invalid - character strings that are
longer than the max variable size and lines over the max length.
So the fix here is for the Tof2Scl conversion so that valid
SCL is
produced.

There are some caveats though:
 - the conversion can now take a long time for scripts with big
   strings in them.
 - The SCL compiler obviously has strange ideas about counting
   and it's idea of 65535 characters seems to vary dependent
   on content.  Because of this a max generated string length of
   32K was chosen.  This bug filed as B#1083968	
 - Valid scripts may not succesfully compile :-(  There seems to
   be a problem whereby concatenating large strings together
   for the BODY will cause the compiler, scl.exe, to crash. This
   fix generates SCL just like that.  See B#1083975 for a better
   explanation and workaround.

Apart from the above serious sounding caveats this fix should
reduce the chance of invalid SCL being created by a recording.
It is a fairly large change though so only time will tell.

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

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

[OpenSTA-devel] [ opensta-Bugs-956260 ] When HTML parser fails Modeler HTML tree displays nothing

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

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

Category: GUI Issue
Group: Inconvenience
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: When HTML parser fails Modeler HTML tree displays nothing

Initial Comment:
When the HTML parser fails (for whatever reason) then
the HTML tree tab displays absolutely nothing, and the
structure tab folders have no content.  This is
unfortunate because the parsing up to the point of
failure may have been successful and the specifying
DOM identifiers (prior to the parser failure) in the LOAD
RESPONSE_INFO do work if their format can be worked
out without the aid of the GUI.

Causing the HTML parser to fail is usually down to bad
HTML so a workaround is to fix the HTML you are 
parsing but sometimes this is not possible.  The HTML
parser can be made to fail by something as simple as
missing the closing greater than off the close HTML tag
but this problem report is not about HTML parser
stability.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-10-18 13:05

Message:
Logged In: YES 
user_id=19748

The fix has been merged into the CVS head.  It will become
generally available in release 1.4.3.  The fix includes an
error dialog which announces the line number the HTML
parsing failed on followed by display of the HTML elements
that the DOM parser can cope with.

Modeler: 1.4.3.3
OpenSTA: 1.4.3.4

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-05-18 17:48

Message:
Logged In: YES 
user_id=19748

Proposed fix is to display the HTML parsing as far as
it was successful.  This would allow the possible DOM
identifiers to at least be accessed and used.

An error message would also be useful to warn that
HTML parsing has failed.

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

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

[OpenSTA-devel] [ opensta-Bugs-897876 ] Crash in TestPlugin when menu item "&Test" is changed

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

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

Category: Build Mechanism
Group: Crash
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Thierry Boullet (tboullet)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Crash in TestPlugin when menu item "&Test" is changed

Initial Comment:
When you modify menu IDR_TESTPLTYPE_SRVR_IP's menu item
"&Test" into anything else,
you must also make changes in file
"src\BaseUI\TestPluginTabs\ConfigurationTabDll\ConfigurationTabDll.cpp"
to take into account the new label (line 295) otherwise
there is a memory error at line 308 (pTestMenu = NULL).

In this file, a new item ("&Delete Selection") is added
to the Test menu, so you must indicate what is the label of
the Test menu.

I think the memory error is surely a bug because the
command "InsertMenu" at line 305 inserts a new item
without a submenu, so the command "GetSubMenu" at line
308 returns NULL.
Code will have to be probably (I tested that) :

    CMenu *pTestMenu = pMenu->GetSubMenu(uiTestPos);
    if (pTestMenu)
    {
       
pTestMenu->AppendMenu(MF_STRING,ID_DELETESELECTION,"&Delete
Selection\tDel");
        pTestMenu->Detach();
    }

or

    if(uiTestPos == -1)
    {
        CMenu subMenu;
        subMenu.CreateMenu();
        uiTestPos = uiCount-2;
       
pMenu->InsertMenu(uiTestPos,MF_BYPOSITION|MF_POPUP,(UINT)subMenu.Detach(),"&Test");
    }
   
    CMenu *pTestMenu = pMenu->GetSubMenu(uiTestPos);
    if (pTestMenu)
    {
       
pTestMenu->AppendMenu(MF_STRING,ID_DELETESELECTION,"&Delete
Selection\tDel");
        pTestMenu->Detach();
    }

    pMenu->Detach();


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

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

Message:
Logged In: YES 
user_id=19748

A fix for this problem has been merged into the CVS HEAD.  This
fix will become generally available in the OpenSTA 1.4.3
release.
Thanks to Thierry @ Kereval for providing this fix.

ConfigurationTabDLL.dll: 1.4.3.4
OpenSTA: 1.4.3.11

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=897876&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 02:43
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=897856&group_id=10857

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-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-809482 ] Modeler can only record once on WinXP

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

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

Category: HTTP Capture
Group: Behavioral
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Modeler can only record once on WinXP

Initial Comment:
Under Windows XP Professional the Modeler can only
perform a single Recording until it is restarted.

The first recording will work OK, subsequent attempts
to record do not open the browser or give an error,
they simply return as if the recording had completed
but with a very minimalist script.

This problem has been reproduced on OpenSTA 1.4.2 using
Windows XP Professional and IE6 as the recorded
browser.  This problem behaviour is not exhibited on
W2K and NT4.  It is unknown if other version
combinations of WinXP, IE and OpenSTA also exhibit the
problem.

The workaround is simply to close down the Modeler and
restart it.

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

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

Message:
Logged In: YES 
user_id=19748

A fix for this issue has been merged into the CVS HEAD. 
This fix
will become generally available in the OpenSTA 1.4.3 release.
Thanks to Thierry @Kereval for providing this fix.

TModeller_Web.exe: 1.4.3.5
OpenSTA: 1.4.3.10

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

Comment By: Thierry Boullet (tboullet)
Date: 2004-11-24 12:50

Message:
Logged In: YES 
user_id=949869

Another solution is to use the Stop button of the Modeler to
stop the recording instead of closing the window of the
browser.  When the browser is closed, the gateway is also
closed.

By clicking the Stop button, it is possible to launch
several recordings with the same browser window.

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

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

[OpenSTA-devel] [ opensta-Bugs-783154 ] SCL command line usage message out of date

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

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

Category: Command Line
Group: Cosmetic
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: SCL command line usage message out of date

Initial Comment:
It appears that the SCL command line usage message, the
text message output when -h, --help is supplied or a
mistake is made on the command line, is out of date and
help is given for more command line options than exist
in the current SCL.

This is reported for -V, --variant but it is suspect
that at least -I, --include and -l, --list fall into
this category as well.

This problem shown to exist on OpenSTA 1.4.2
installation,  SCL version 1.4.2.1 running XPpro, but
will inevitably exist on other platforms and earlier
versions.

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-22 15:42

Message:
Logged In: YES 
user_id=19748

The mentioned update has been merged into the CVS HEAD.  It
will become generally available in the OpenSTA 1.4.3 Release.

scl.exe: 1.4.3.2
OpenSTA: 1.4.3.15

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-12-22 15:38

Message:
Logged In: YES 
user_id=19748

I have an update for this message after doing some general
investigation.  -V(--variant) is indeed useless and
non-functional
so I've removed all mention of it - although the SCL
compiler still
has the capability internally.  The -I(--include) was badly
worded
and is actually to provide an include directory not a file - so
updated the message for that.  The rest of the options do 
actually work although most don't make a great deal of sense
within OpenSTA. 

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

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

[OpenSTA-devel] [ opensta-Bugs-760485 ] Modeler HTML tabs don't contain all elements for 'bad' HTML

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

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

Category: GUI Issue
Group: Inconvenience
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Modeler HTML tabs don't contain all elements for 'bad' HTML

Initial Comment:
The Modeler tree view tabs (HTML Tree and Structure)
should display the breakdown contents of HTML body
content when a GET (or POST) request is selected and
"Url details" requested.

This may be due to the fact the HTML is not formed in a
normal manner.  The tree tabs seem to expect that HTML
will be rooted all in a single <html></html> pair. 
Items that occur outside this block confuse the code
that set up the tree views and it appears that only the
last top level tag pair will be shown.

At runtime HTML parsing using DOM identifiers still
works and LOAD RESPONSE_INFO BODY's can still be used
but you must code them by hand.

Workaround: make your application generate nice HTML :-)

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2004-05-18 14:30

Message:
Logged In: YES 
user_id=19748

The fix has been merged into the CVS HEAD.  It will become
generally available in release 1.4.3.  Problem found to be
the same as report 414448.

The fix creates a new top level folder to the HTML tree,
called 'document' and places any 'rooted' HTML tags below
this.  Previously only the last 'rooted' HTML tag would show
up in the HTML tree tab.  Work on diagnosing and fixing this
issue was kindly sponsored by Bernie @ Performax, Thanks.

Modeler: 1.4.3.2
OpenSTA: 1.4.3.3

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

Comment By: Daniel Sutcliffe (dansut)
Date: 2003-07-26 08:28

Message:
Logged In: YES 
user_id=19748

The problem is exactly as described previously.  The HTML
shown by the Modeler in its tabs is only that between the
last pair of root level tags in the HTTP body.  The parser
assumes there will only be a single set of root level tags.
 A solution to this problem needs to acknowledge the
possibility of multiple root level tags but not change the
DOM addressing in any way, as this would break compatibility.

Problem reproduced on all OS's, NT4 upwards, and using
OpenSTA 1.4.2 and all previous releases tested.

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

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

[OpenSTA-devel] [ opensta-Bugs-746154 ] Browsing NTPerf counter instances with same name unavailable

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

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

Category: Performance Monitor
Group: Inconvenience
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Browsing NTPerf counter instances with same name unavailable

Initial Comment:
Trying to create NT Performance counter queries where
there are multiple instances with the same name is not
possible using the Browse Queries dialog when editing
an NT Performance Query for an NT Performance 
collector.

The browse (Add Counters) dialog in M$'s Performance
Monitor tool puts #1, #2, #3, ... on the end of instances
with the same name (on W2K).  This does not happen
in the, very similar, OpenSTA dialog.

This has been reproduced under OpenSTA 1.4.2 with
NT4sp6a and W2Ksp3 (it is not possible to even get 
the "browse" dialog under WinXP, see bug# 730308).
It is believed all previous version of OpenSTA also
exhibit this behaviour.

The workaround is to cut/paste queries from the M$
tool or write them by hand.

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

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

Message:
Logged In: YES 
user_id=19748

This fix has been merged into the CVS HEAD.  It will become
generally available in the OpenSTA 1.4.3 release.

NTPerfPlugin.exe: 1.4.3.4
OpenSTA: 1.4.3.14

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

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

Message:
Logged In: YES 
user_id=19748

The fix for this is simply to set bIncludeInstanceIndex to TRUE
in the PDH_BROWSE_DLG_CONFIG that is passed to Microsoft's
PdhBrowseCounters().  Once this is done the GUI dialog
provides the indexes on all queries with the same name.

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

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

[OpenSTA-devel] [ opensta-Bugs-730308 ] Perf counter not listed under Windows XP

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

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

Category: GUI Issue
Group: Behavioral
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jerome Delamarche (trickyjer)
Assigned to: Geoff Hall (ghall)
Summary: Perf counter not listed under Windows XP

Initial Comment:
When run under Windows XP, OpenSTA does not 
display the available Performance Object.
A workaround has been already posted by Alain Ribault. 

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

Comment By: Geoff Hall (ghall)
Date: 2003-06-21 19:48

Message:
Logged In: YES 
user_id=81187

Fix tested and checked into CVS. 
This fix is available in NTPerfPlugin.exe version 1.4.3.2. 
This component will be available within the OpenSTA 1.4.3 
release.

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

Comment By: Geoff Hall (ghall)
Date: 2003-06-06 20:44

Message:
Logged In: YES 
user_id=81187

In order to determine the required buffer size for the query 
string an initial call is made to PdhParseCounterPath with a 
passed in buffer length of zero. On NT/2000 a succesfull call 
returns ERROR_SUCCESS but on XP the same call returns 
PDH_MORE_DATA (not enough buffer space).  

The error checking within the function has been modified to 
accept either return status.

The fix will be checked into CVS after formal testing.



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

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