opensta-devel — OpenSTA developer discussions

[OpenSTA-devel] [ opensta-Bugs-1468855 ] 'LOAD RESPONSE_INFO' fails if performed in a different scope

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

Bugs item #1468855, was opened at 2006-04-11 14:06
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=1468855&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Arrowwood (jarrowwx)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'LOAD RESPONSE_INFO' fails if performed in a different scope

Initial Comment:
This is similar to issues 433574 and 645735, and in
fact is explicitly mentioned in 433574, but is being
lost in the confusion because there are multiple bugs
being reported at once.  So, to try and help this issue
get some attention, here it is in a separate bug.

Regardless of whether you use PRIMARY GET URI or GET
URI or PRIMARY POST URI, the following applies:

If you perform the HTTP request in a subroutine, and
then try to LOAD Response_Info after the subroutine
finishes, or if you attempt to call a subroutine in
order to perform the LOAD, either way, it errors with
the familiar:

HTTPRESPONSE: No data available for connection id(1)
TScript::run: ERROR in TOF execution; resuming...

This appears to be an issue whether the connection ID
is a constant, an integer variable, or an expression. 
This is why I chose to raise a separate bug, since the
other two seem to be focused on the use of a variable
for the connection id.

The use of SYNCHRONIZE REQUESTS seems to be of no
value, whether performed in the calling subroutine, or
the called subroutine.

The wrapping of the call in an IF block also likewise
does not help.

It would seem to be a scope issue.  It seems like once
the scope of execution changes, the connection id is no
longer valid.

Here's hoping that helps narrow down the source of the
problem.  And if this could be fixed, it would enable
scripts to be much better organized and maintainable.

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

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

[OpenSTA-devel] Re: Browser Registration in Script Modeler

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

Federico Toledo wrote:
> I have had the same problem (with OpenSTA 1.4.3 and IExplorer 6.0)
> and I found the key looking the source code.
> 
> There are two registry entries that OpenSTA uses to find the
> Explorer:
>   SOFTWARE\\Microsoft\\Internet Explorer
>   SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\App Paths\\IEXPLORE.EXE
> 
> If you don't have Windows administrative permissions you can't run
> OpenSTA Modeler
> 
> I'll post a message in opensta-devel Archives and perhaps someone can
> repair this bug

I think this was meant to be a reply to a mail in the users list - you
sent it to the developer list - maybe you'd like to resend it to the
users for the archives?

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

[OpenSTA-devel] RE: Browser Registration in Script Modeler

[Federico T. <ft...@fi...>]

I have had the same problem (with OpenSTA 1.4.3 and IExplorer 6.0) and
I found the key looking the source code

 there are two registry entries that OpenSTA uses to find the Explorer

 SOFTWARE\\Microsoft\\Internet Explorer
 SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\App Paths\\IEXPLORE.EXE

 If you don't have Windows administrative permissions you can't run
OpenSTA Modeler

 I'll post a message in opensta-devel Archives and perhaps someone can
repair this bug

 my workaround was obtain permissions on these entries

 saludos
 Federico

[OpenSTA-devel] Browser Registration in Script Modeler

[Federico T. <ft...@fi...>]

See http://sourceforge.net/mailarchive/message.php?msg_id=3D531080
 Someone had a problem with OpenSTA 1.2.2 and IExplorer 5.0
 I have had the same problem (with OpenSTA 1.4.3 and IExplorer 6.0)
and I found the key looking the source code

 there are two registry entries that OpenSTA uses to find the Explorer

 SOFTWARE\\Microsoft\\Internet Explorer
 SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\App Paths\\IEXPLORE.EXE


 If you don't have Windows administrative permissions you can't record
with OpenSTA Modeler

 my workaround was obtain permissions on these entries, but i think
that this is a bug....what do you say?

 saludos
 Federico

[OpenSTA-devel] Re: Where to start with the source code?

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

Lei Shen wrote:
> Is there any documentation on how the OpenSTA code is organized?
>     
> Like how many components, and how each component is connected to
> each other?

Thierry Boullet created this from the 1.4.2 source:
  http://OpenSTA.org/devdocs/
The structure hasn't changed since then so it all still applies, here
is the mail from this lists archives giving a bit more info:
  http://sourceforge.net/mailarchive/message.php?msg_id=10163617

> Any test cases on http executors (I assume that's the part which
> will be responsible to make a request)?

Yes, Test Executers do the replay work - and no there are no formal
test cases that I know of.

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

[OpenSTA-devel] Where to start with the source code?

[Lei S. <ls...@ya...>]

Is there any documentation on how the OpenSTA code is
organized?
    
Like how many components, and how each component is
connected to each other?
    
Any test cases on http executors (I assume that's the
part which will be responsible to make a request)?
   
Thanks in advance
Lei
 

[OpenSTA-devel] [ opensta-Bugs-1439936 ] texecuter_htp.exe crash

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

Bugs item #1439936, was opened at 2006-02-27 16:58
Message generated for change (Comment added) made by kenmoon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1439936&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: kenmoon (kenmoon)
Assigned to: Nobody/Anonymous (nobody)
Summary: texecuter_htp.exe crash

Initial Comment:
(There is an old bug from 2001 -- 438946 -- that was
closed without resolution for an earlier version of
OpenSTA; I am experiencing a similar problem with 1.4.3.2.)

Running a load test using OpenSTA, after getting
through Task 1 (<40 VUs), both Commander and NameServer
crash with a TExecuter_htp.exe error.  Memory looked
fine across the board.

Software:
OpenSTA version 1.4.3.2
(TExecuter_htp.exe version 1.4.3.3)

Commander & NameServer running on:
Windows XP (Pro) SP 1
Pentium 4, 1GB RAM

Server on which load test is being performed:
Windows Server 2003 (Standard)
Pentium III, 2GB RAM

I am uploading a zip with TExecuter_htp_ipaddress log
file and the .htp scripts if that helps.

Thanks in advance for any insight.
Regards,
Ken.

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

>Comment By: kenmoon (kenmoon)
Date: 2006-02-27 18:15

Message:
Logged In: YES 
user_id=1463183

Adding .htp scripts

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

Comment By: kenmoon (kenmoon)
Date: 2006-02-27 17:01

Message:
Logged In: YES 
user_id=1463183

Adding .htp scripts

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

Comment By: kenmoon (kenmoon)
Date: 2006-02-27 17:00

Message:
Logged In: YES 
user_id=1463183

Adding second part of TExecuter_htp log....

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

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

[OpenSTA-devel] [ opensta-Bugs-1439936 ] texecuter_htp.exe crash

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

Bugs item #1439936, was opened at 2006-02-27 16:58
Message generated for change (Comment added) made by kenmoon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1439936&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: kenmoon (kenmoon)
Assigned to: Nobody/Anonymous (nobody)
Summary: texecuter_htp.exe crash

Initial Comment:
(There is an old bug from 2001 -- 438946 -- that was
closed without resolution for an earlier version of
OpenSTA; I am experiencing a similar problem with 1.4.3.2.)

Running a load test using OpenSTA, after getting
through Task 1 (<40 VUs), both Commander and NameServer
crash with a TExecuter_htp.exe error.  Memory looked
fine across the board.

Software:
OpenSTA version 1.4.3.2
(TExecuter_htp.exe version 1.4.3.3)

Commander & NameServer running on:
Windows XP (Pro) SP 1
Pentium 4, 1GB RAM

Server on which load test is being performed:
Windows Server 2003 (Standard)
Pentium III, 2GB RAM

I am uploading a zip with TExecuter_htp_ipaddress log
file and the .htp scripts if that helps.

Thanks in advance for any insight.
Regards,
Ken.

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

>Comment By: kenmoon (kenmoon)
Date: 2006-02-27 17:01

Message:
Logged In: YES 
user_id=1463183

Adding .htp scripts

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

Comment By: kenmoon (kenmoon)
Date: 2006-02-27 17:00

Message:
Logged In: YES 
user_id=1463183

Adding second part of TExecuter_htp log....

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

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

[OpenSTA-devel] [ opensta-Bugs-1439936 ] texecuter_htp.exe crash

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

Bugs item #1439936, was opened at 2006-02-27 16:58
Message generated for change (Comment added) made by kenmoon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1439936&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: kenmoon (kenmoon)
Assigned to: Nobody/Anonymous (nobody)
Summary: texecuter_htp.exe crash

Initial Comment:
(There is an old bug from 2001 -- 438946 -- that was
closed without resolution for an earlier version of
OpenSTA; I am experiencing a similar problem with 1.4.3.2.)

Running a load test using OpenSTA, after getting
through Task 1 (<40 VUs), both Commander and NameServer
crash with a TExecuter_htp.exe error.  Memory looked
fine across the board.

Software:
OpenSTA version 1.4.3.2
(TExecuter_htp.exe version 1.4.3.3)

Commander & NameServer running on:
Windows XP (Pro) SP 1
Pentium 4, 1GB RAM

Server on which load test is being performed:
Windows Server 2003 (Standard)
Pentium III, 2GB RAM

I am uploading a zip with TExecuter_htp_ipaddress log
file and the .htp scripts if that helps.

Thanks in advance for any insight.
Regards,
Ken.

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

>Comment By: kenmoon (kenmoon)
Date: 2006-02-27 17:00

Message:
Logged In: YES 
user_id=1463183

Adding second part of TExecuter_htp log....

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

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

[OpenSTA-devel] [ opensta-Bugs-1439936 ] texecuter_htp.exe crash

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

Bugs item #1439936, was opened at 2006-02-27 16:58
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=1439936&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: kenmoon (kenmoon)
Assigned to: Nobody/Anonymous (nobody)
Summary: texecuter_htp.exe crash

Initial Comment:
(There is an old bug from 2001 -- 438946 -- that was
closed without resolution for an earlier version of
OpenSTA; I am experiencing a similar problem with 1.4.3.2.)

Running a load test using OpenSTA, after getting
through Task 1 (<40 VUs), both Commander and NameServer
crash with a TExecuter_htp.exe error.  Memory looked
fine across the board.

Software:
OpenSTA version 1.4.3.2
(TExecuter_htp.exe version 1.4.3.3)

Commander & NameServer running on:
Windows XP (Pro) SP 1
Pentium 4, 1GB RAM

Server on which load test is being performed:
Windows Server 2003 (Standard)
Pentium III, 2GB RAM

I am uploading a zip with TExecuter_htp_ipaddress log
file and the .htp scripts if that helps.

Thanks in advance for any insight.
Regards,
Ken.

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

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

[OpenSTA-devel] [ opensta-Bugs-1424114 ] Gateway.exe 100% CPU

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

Bugs item #1424114, was opened at 2006-02-04 11:25
Message generated for change (Comment added) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1424114&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: Hang
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Yannick Robin (yrobin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gateway.exe 100% CPU

Initial Comment:
Our configuration is With W2K and IE.
Occasionally, we see the capture hangs and the http
gateway gets stuck at 100% of the CPU.

The logs show an infinite loop to the requested page.

The script contains a sequence of the following SCL
code: CONNECT TO <gate_hostname>:<gate_port>

The workaround is to remove the proxy configuration in
Internet Explorer and to restart the script modeler.

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

>Comment By: Daniel Sutcliffe (dansut)
Date: 2006-02-04 15:34

Message:
Logged In: YES 
user_id=19748

Your problem report does not contain enough information and
will be deleted.

Obviously you missed the text at the top of the bug listing
and submit new bug pages that says:
 "Before submitting any new problem here,
  please check the FAQ,
  specifically the entry on reporting bugs"
This is a link to the reporting bugs entry in the FAQ:
  http://portal.opensta.org/faq.php?topic=ReportingBugs

You should discuss your problem on the users list first to
avoid us getting bug reports like this one containing far
too little information to be considered a bug ... yet

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

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

[OpenSTA-devel] [ opensta-Bugs-1424114 ] Gateway.exe 100% CPU

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

Bugs item #1424114, was opened at 2006-02-04 16:25
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=1424114&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: Hang
Status: Open
Resolution: None
Priority: 5
Submitted By: Yannick Robin (yrobin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gateway.exe 100% CPU

Initial Comment:
Our configuration is With W2K and IE.
Occasionally, we see the capture hangs and the http
gateway gets stuck at 100% of the CPU.

The logs show an infinite loop to the requested page.

The script contains a sequence of the following SCL
code: CONNECT TO <gate_hostname>:<gate_port>

The workaround is to remove the proxy configuration in
Internet Explorer and to restart the script modeler.

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

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

Re: [OpenSTA-devel] Re: Platform SDK

[Mark E. <ma...@bo...>]

Wickersham, Peter wrote:
> Well, I would totally agree that the underlying system should be
> threadsafe without any regard to the SCL statements used. It shouldn't
> be required for the script writer to be concerned about those details.
> 
> That said, I am still barely scratching the surface of all the
> foundation classes that are in use in OpenSTA. So, is there already an
> abstraction of a mutex into a base class to be used for this purpose. I
> believe that I have seen some in looking through the code, but it would
> be helpful if I had a direct pointer on which class to use. I haven't
> had a lot of time to dig into the code to figure out which Projects
> (libraries) are base libraries for all the different executables in the
> system.

There's probably about 3 abstractions of a mutex in various shapes and
forms, including those that come with OmniORB (omni_mutex_lock) and a 
CLock from FastLock.hpp , there's also a CTMutex in the CyrToolsOS 
Project :-)

However, having looked a bit further the file TContext.cpp uses a lock
in TContext::set_variable and TContext::get_variable which I believe is
where all the calls for setting and retrieving values for variables
during script reply is handled (A TContext instance used to represent , 
for all intents and purposes, a thread context/virtual user). On closer 
inspection this lock is a member of TContext so probably wouldn't do 
much, maybe this should be made static? This seems a little overkill for 
within a single process (only one variable can be set/got at a time) but 
would seem to provide the protection required.

This does not hold true for CORBA based variables in a multi test-engine
scenario though. Here it is possible to have 2 or more processes try and
use the same variable simultaneously and I can't see any locking
mechanism. The workings of CORBA/OmniORB may mean that it is unlikely
(or even impossible) that two calls would be 'brokered' in this way but
I can't remember if this can be guaranteed, I can't even remember if I
ever knew if this was guaranteed :-)

If we wanted to make sure then GlabalVariableImpl::get_value and 
set_value etc. could probably be locked, but I think this would add 
extra locking for the 'normal' situation mentioned above as well. 
Personally I would rather be sure that locking was required before it 
was added but...

On an aside I suppose it would be nice to move towards just one 
abstraction of mutexes and other useful classes. Certainly if OpenSTA 
moved away from using the OmniORB thread classes etc I believe it would 
be possible to make the code work for different ORBs (how are MICO and 
TAO doing these days?).

Mark

RE: [OpenSTA-devel] Re: Platform SDK

[Wickersham, P. <Pet...@di...>]

Well, I would totally agree that the underlying system should be
threadsafe without any regard to the SCL statements used. It shouldn't
be required for the script writer to be concerned about those details.

That said, I am still barely scratching the surface of all the
foundation classes that are in use in OpenSTA. So, is there already an
abstraction of a mutex into a base class to be used for this purpose. I
believe that I have seen some in looking through the code, but it would
be helpful if I had a direct pointer on which class to use. I haven't
had a lot of time to dig into the code to figure out which Projects
(libraries) are base libraries for all the different executables in the
system.

thanks,
peter

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Mark
Elam
Sent: Thursday, January 19, 2006 3:22 PM
To: ope...@li...
Subject: Re: [OpenSTA-devel] Re: Platform SDK

Daniel Sutcliffe wrote:
> Peter Wickersham wrote:
>=20
>>I'm testing my random patch in the next day or so.  The only issue
>>that I am not clear on is whether or not I need to guard the calls
>>into the MTRand class (Mersenne Twister Random).  It is not
>>threadsafe, but is this a major issue?  I am not sure if we are
>>guarded upstream of these calls due to the use of MUTEX statements
>>in the SCL and other possible mutexes.  Anyone know this?
>=20
>=20
> It's a good question and one I, unfortunately, don't know the answer
> to.  The fact that Mark was concerned about the lack of controlled
> atomicity to the srand(),rand() pair would suggest to me that you do
> need to be somewhat concerned - Mark would have more idea than most
> as one of the original coders of this area.


I'll try and have a look at the weekend but if memory serves...

Using a MUTEX around your GENERATE and NEXT statements in SCL should
have the desired effect of 'protecting' the random variable, assuming,
of course, that the MTRand class is entirely contained as a member of
the CECVar derived class. However, I believe that the original purpose
of having the MUTEX and SEMAPHORE statements was more to do with
allowing synchronisation across virtual users for the purposes of
atomicity on multiple SCL statements and avoiding data race between
unrelated scripts, rather than the simple 'guarding' outlined above.

Certainly, if this is the case, it could be argued that we should allow
the use of variables to be thread safe without the need for extra SCL
statements. I do not believe that this is currently, explicitly, true.=20
However, the internal workings of the threading model used and the=20
mechanisms of CORBA used for the GLOBAL variables may mean that this=20
does not cause a problem for most situations.

The threading, in particular, has changed since I wrote the variable=20
code, and the CORBA variable handling has been moved to within the=20
Daemon process rather than the old TestManager Process(where it was=20
guaranteed that CORBA variable objects would be destroyed at the end of=20
a test). But I think the actual variable handling is still pretty much=20
the same.

In short I would say, I think that thread-safety is an issue, but that=20
it may be difficult to prove :-)

Mark






-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
_______________________________________________
OpenSTA-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensta-devel

Re: [OpenSTA-devel] Re: Platform SDK

[Mark E. <ma...@bo...>]

Daniel Sutcliffe wrote:
> Peter Wickersham wrote:
> 
>>I'm testing my random patch in the next day or so.  The only issue
>>that I am not clear on is whether or not I need to guard the calls
>>into the MTRand class (Mersenne Twister Random).  It is not
>>threadsafe, but is this a major issue?  I am not sure if we are
>>guarded upstream of these calls due to the use of MUTEX statements
>>in the SCL and other possible mutexes.  Anyone know this?
> 
> 
> It's a good question and one I, unfortunately, don't know the answer
> to.  The fact that Mark was concerned about the lack of controlled
> atomicity to the srand(),rand() pair would suggest to me that you do
> need to be somewhat concerned - Mark would have more idea than most
> as one of the original coders of this area.


I'll try and have a look at the weekend but if memory serves...

Using a MUTEX around your GENERATE and NEXT statements in SCL should
have the desired effect of 'protecting' the random variable, assuming,
of course, that the MTRand class is entirely contained as a member of
the CECVar derived class. However, I believe that the original purpose
of having the MUTEX and SEMAPHORE statements was more to do with
allowing synchronisation across virtual users for the purposes of
atomicity on multiple SCL statements and avoiding data race between
unrelated scripts, rather than the simple 'guarding' outlined above.

Certainly, if this is the case, it could be argued that we should allow
the use of variables to be thread safe without the need for extra SCL
statements. I do not believe that this is currently, explicitly, true. 
However, the internal workings of the threading model used and the 
mechanisms of CORBA used for the GLOBAL variables may mean that this 
does not cause a problem for most situations.

The threading, in particular, has changed since I wrote the variable 
code, and the CORBA variable handling has been moved to within the 
Daemon process rather than the old TestManager Process(where it was 
guaranteed that CORBA variable objects would be destroyed at the end of 
a test). But I think the actual variable handling is still pretty much 
the same.

In short I would say, I think that thread-safety is an issue, but that 
it may be difficult to prove :-)

Mark

[OpenSTA-devel] [ opensta-Bugs-1410173 ] Bad (but unimportant) installer actions for system DLLs

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

Bugs item #1410173, was opened at 2006-01-19 15:22
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=1410173&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: Installation
Group: Design
Status: Open
Resolution: None
Priority: 2
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: Bad (but unimportant) installer actions for system DLLs

Initial Comment:
The MSI package for the OpenSTA 1.4.3 release and
earlier is specified to install certain "system" DLLs.
 These specifically are PDH.DLL, PSAPI.DLL and
MGMTAPI.DLL.  The installer specification for these is
not as Microsoft recommends but this appears not to
matter except for reports on some (non-English)
installs where error messages may be given about an
inability to install over system versions.

PDH.DLL and PSAPI.DLL are only required to be installed
on NT4 and Microsoft recommends installation in the
application directory.  The OpenSTA installation has no
conitional for their installation and attempts to
install in the system directory.  It appears that the
installation will not be able to overwrite the files in
the system directory but that the installer "hides"
this error unless on some non-english Windows
installations.

MGMTAPI.DLL is seemingly not even required by any part
of the OpenSTA installation but is still listed in the
installer.

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

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

[OpenSTA-devel] [ opensta-Bugs-1410145 ] Starting Test: "TestPlugin.exe has encountered a problem..."

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

Bugs item #1410145, was opened at 2006-01-19 14:36
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=1410145&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: GUI Issue
Group: Crash
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Nobody/Anonymous (nobody)
Summary: Starting Test: "TestPlugin.exe has encountered a problem..."

Initial Comment:
On attempting to start a Test in the Commander you will
get the error message "TestPlugin.exe has encountered a
problem and needs to close" and the Test does not
start.  This problem seems to be very unpredictable and
little is
really known about what causes it.

This bug report is mostly intended to collect data on
when, where and how the issue might occur so that
eventually the problem will be understood enough to
maybe find a workaround and eventually a fix.  So if
you have seen this problem and can add unique (no
meto's thanks) data to this bug report then please take
the time to provide as much info as you can.  Here's
some ideas what data you can give:
OpenSTA version?
Windows version?
Other Networking/CORBA software installed?
Is it happening consistantly or intermitently?
Is it happening for just 1 specific Test? (Give Details)
Does rebooting help?
Does restarting the NamesServer Help?
Any stuck OpenSTA related processes at the time of the
error?
Any errors in the many OpenSTA logs?

Thanks 

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

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

[OpenSTA-devel] Re: Platform SDK

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

Peter Wickersham wrote:
> The Xtree patch was the one that I needed.  I now have CVS HEAD
> built with no STLPort, Feb 2003 Platform SDK, everything else the
> recommended. 

Thanks for the testing ;-)  I'm in the process of putting together an
old PC with an NT4 installation that will contain the old (1.4.3
recommended) build environment and act as an OpenSTA test platform,
once this is done I'll be testing and committing this and whole bunch
of other changes to the CVS HEAD - nothing too drastic but some nice
little bug fixes.

> I'm testing my random patch in the next day or so.  The only issue
> that I am not clear on is whether or not I need to guard the calls
> into the MTRand class (Mersenne Twister Random).  It is not
> threadsafe, but is this a major issue?  I am not sure if we are
> guarded upstream of these calls due to the use of MUTEX statements
> in the SCL and other possible mutexes.  Anyone know this?

It's a good question and one I, unfortunately, don't know the answer
to.  The fact that Mark was concerned about the lack of controlled
atomicity to the srand(),rand() pair would suggest to me that you do
need to be somewhat concerned - Mark would have more idea than most
as one of the original coders of this area.

If you come to any conclusion or have any thoughts on this matter
that you want to bounce of someone else then keep them coming to this
list and I'll do my best to give you my opinions, for what they're 
worth :-)

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

RE: [OpenSTA-devel] Re: Platform SDK

[Wickersham, P. <Pet...@di...>]

Great, thanks. The Xtree patch was the one that I needed. I now have CVS
HEAD built with no STLPort, Feb 2003 Platform SDK, everything else the
recommended.=20

I'm testing my random patch in the next day or so. The only issue that I
am not clear on is whether or not I need to guard the calls into the
MTRand class (Mersenne Twister Random). It is not threadsafe, but is
this a major issue? I am not sure if we are guarded upstream of these
calls due to the use of MUTEX statements in the SCL and other possible
mutexes. Anyone know this?

-peter

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Daniel
Sutcliffe
Sent: Sunday, January 15, 2006 7:22 PM
To: ope...@li...
Subject: [OpenSTA-devel] Re: Platform SDK

Pete Wickersham wrote:
> Ok, I'm in the midst of building CVS HEAD with no STLPort, VC 6 SP6,
> Platform SDK Feb 2003 edition, everything else standard.
>=20
> I'm running into some compilation errors with some of the STL
> classes.  Do you have these resolved already?  If so, I'll wait for
> any of your checkins.

I am building totally cleanly with no STLPort, but I am currently
using the later/current PSDK but I don't think that should make any
difference.  THe only thing that is holding me back in commiting my
changes to support building without the STLPort is a bit of extra
testing - specifically making sure that the changes will still work
with the existing recommended build environment... this wouldn't be
a real problem except my alternate build machine has "issues" at
the moment.

The other thing that I have found useful is that I'm now building
with BD Software's STLFilt:
  http://www.bdsoft.com/tools/stlfilt.html
I don't know if this is hiding any errors - I'll try a build with
it turned off and report back if there is anything tomorrow.

To help you get on quickly, I think this patch describes the source
changes that are required to build cleanly without the STLPort:
-------------- StartPatch --------------
--- C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\CyrToolsOS\ctime.hpp
Mon May 17 11:34:44 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\Architecture\CyrToolsOS\ctime.hpp
Tue Jun 21 16:15:47 2005
@@ -42,7 +42,7 @@
 #include <string>
 using std::string;
 #ifdef WIN32
-//#include <windows.h>
+#include <windows.h>
 #endif
---
C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\TestProcess\Common\Atvf\TR
ecCreator.h	Mon May 17 11:34:50 2004
+++
C:\OpenSTA\ostaw32-nostlp\src\Architecture\TestProcess\Common\Atvf\TRecC
reator.h	Fri Jun 24 11:58:31 2005
@@ -32,7 +32,9 @@
  **/
=20
 #include <string>
+#pragma warning(disable:4800)
 #include <map>
+#pragma warning(default:4800)
 #ifdef unix
 #elif defined (__VMS)
 #elif defined (WIN32)
---
C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\TestProcess\Common\Base\CE
CTofTxt.cpp	Mon May 17 11:34:51 2004
+++
C:\OpenSTA\ostaw32-nostlp\src\Architecture\TestProcess\Common\Base\CECTo
fTxt.cpp	Wed Jun 22 10:31:45 2005
@@ -572,7 +572,7 @@
     // Do the 'ltrim' and return function value.
     string::size_type iOff =3D ltrimstr.find_first_not_of(" \t\r\n");
     if(iOff =3D=3D string::npos)
-        resstrP->clear();
+        resstrP->erase();
     else
         *resstrP =3D ltrimstr.substr(iOff);
     return true;
@@ -664,7 +664,7 @@
     // Do the 'rtrim' and return function value.
     string::size_type iOff =3D rtrimstr.find_last_not_of(" \t\r\n");
     if(iOff =3D=3D string::npos)
-        resstrP->clear();
+        resstrP->erase();
     else
         *resstrP =3D rtrimstr.substr(0, iOff+1);
     return true;
---
C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\TestProcess\Common\Base\TC
ontext.h	Mon May 17 11:34:51 2004
+++
C:\OpenSTA\ostaw32-nostlp\src\Architecture\TestProcess\Common\Base\TCont
ext.h	Fri Jun 24 14:10:33 2005
@@ -38,7 +38,9 @@
 #endif
=20
 #include <string>
+#pragma warning(disable:4800)
 #include <map>
+#pragma warning(default:4800)
 #include <set>
 #include <stack>
 #include <list>
--- C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\xmlparser\XPath.inl
Mon May 17 11:35:14 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\Architecture\xmlparser\XPath.inl
Thu Jun 23 15:28:36 2005
@@ -2643,7 +2643,10 @@
                         if(val2.m_eType =3D=3D TYPE_NODESET)
                         {
                             // val and val2 are valid. Perform the
union.
-
val.m_nodeSet.insert(val2.m_nodeSet.begin(), val2.m_nodeSet.end());
+                            while(!val2.m_nodeSet.empty()) {
+
val.m_nodeSet.insert(*(val2.m_nodeSet.begin()));
+
val2.m_nodeSet.erase(val2.m_nodeSet.begin());
+                            }
                         }
                         else
                             val.Clear();
@@ -2706,7 +2709,10 @@
                         {
                             DocumentOrder
order(DocumentOrder::forward);
                             OrderedNodeSet tmpSet(order);
-                            tmpSet.insert(val.m_nodeSet.begin(),
val.m_nodeSet.end());
+                            while(!val.m_nodeSet.empty()) {
+
tmpSet.insert(*(val.m_nodeSet.begin()));
+
val.m_nodeSet.erase(val.m_nodeSet.begin());
+                            }
                             tmpSet.swap(val.m_nodeSet);
                         }
=20
--- C:\OpenSTA\sf-rw-src\ostaw32\src\HTTP\HTMLParser\TagParsing.hpp
Tue May 18 11:41:22 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\HTTP\HTMLParser\TagParsing.hpp
Fri Jun 24 12:18:28 2005
@@ -35,7 +35,9 @@
 #   pragma warning (disable: 4786)
 #endif
=20
+#pragma warning(disable:4800)
 #include<map>
+#pragma warning(default:4800)
=20
 // This enum contains all the tag types.
 enum Tags
--- C:\OpenSTA\sf-rw-src\ostaw32\src\HTTP\UI\iecacheman\IECache.h
Mon May 17 11:35:36 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\HTTP\UI\iecacheman\IECache.h	Fri Jun
24 12:24:25 2005
@@ -37,7 +37,9 @@
 #endif // _MSC_VER > 1000
=20
 #pragma warning (disable: 4786)
+#pragma warning(disable:4800)
 #include <map>
+#pragma warning(default:4800)
 #include <string>
 #include <list>
=20
--- C:\OpenSTA\sf-rw-src\ostaw32\src\HTTP\UI\Modeller\EndTimerDlg.cpp
Mon May 17 11:35:34 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\HTTP\UI\Modeller\EndTimerDlg.cpp
Wed Jun 22 11:21:08 2005
@@ -45,7 +45,7 @@
 void CEndTimerDlg::FillList()
 {
 	int index =3D 0;
-	for (stringStlSet::iterator itr =3D m_timerSet.begin(); itr !=3D
m_timerSet.end(); ++itr, ++index)
+	for (stringStlSet::const_iterator itr =3D m_timerSet.begin(); itr
!=3D m_timerSet.end(); ++itr, ++index)
 	{
 		m_TimerList.InsertString(index, (*itr));
 	}

--------------- End Patch ---------------

Cheers
/dan

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
_______________________________________________
OpenSTA-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensta-devel

[OpenSTA-devel] Re: Codemax

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

Federico Toledo wrote:
> I want to see the pages, complete html pages, that the server
> return with error (aplication errors), that don't pass the test
> case.

I understand that you want to save out the complete HTML files on
application errors, and you understand that spotting application
errors is something you will need to hand code for the SCL code for.

To try and say this absolutely clearly: you want to be able to write
downloaded HTTP reponses (Web pages) to individual files.  To do this
you need to be able to write data from SCL to a file ...  What you
then need to understand is that this basic capability is supposed to
be part of SCL but has always been broken, bug# 730311:
  http://sourceforge.net/tracker/index.php?func=detail&aid=730311&group_id=10857&atid=110857
The reason this has never been fixed is that apparently it isn't
easy, I understand this has lots to do with the distributed nature of
OpenSTAs replay capabilities.

I guess what I'm trying to say is, that to achieve your goals, what
you really need to do is to fix the above bug... ;-)

> > > > The Modeler can already use an ODBC data source to populate
> > > > an FVR file - is this the area you would like to extend?  Or
> > > > would you want to integrate into the Commander, or just be
> > > > another seperate tool?
> > >
> > > ok, but the functionality that you say in the Modeler populate
> > > an FVR at the moment that we create the variable.  After an
> > > execution we can not update the contenent of a FVR quickly and
> > > easily.
> >
> > OK, I think the "right" initial way forward is to expand the
> > Modeler's existing facilities to make it possible to update the
> > FVR contents at any time in the most flexible manner.
> 
> I'd like to expand the Commander with this facility, because I want
> to update all the variables existing in all the scripts contained
> in a Test.  Previusly we could set a couple of parameters, and then
> just with a click update all the FVRs corresponding.

I agree that the correct long term goal is to be able to manage your
"Test Data" from within the Commander.  However, there are currently
no features within Commander for dealing with FVR files, whereas the
Modeler already has the start of features for doing this ... I
suggest that improvements to the Modeler's current features would be
a great first step and more importantly something that could go into
the "stable" 1.4 series for all to use in the near future.  Further
features could be well thought through and put into a much improved
Commander in the 1.5 developer release series.

It's your time and effort though, I can only encourage you to use it
in ways that will help the OpenSTA community for the best in the
shortest time.

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

[OpenSTA-devel] Re: Platform SDK

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

Pete Wickersham wrote:
> Ok, I'm in the midst of building CVS HEAD with no STLPort, VC 6 SP6,
> Platform SDK Feb 2003 edition, everything else standard.
> 
> I'm running into some compilation errors with some of the STL
> classes.  Do you have these resolved already?  If so, I'll wait for
> any of your checkins.

I am building totally cleanly with no STLPort, but I am currently
using the later/current PSDK but I don't think that should make any
difference.  THe only thing that is holding me back in commiting my
changes to support building without the STLPort is a bit of extra
testing - specifically making sure that the changes will still work
with the existing recommended build environment... this wouldn't be
a real problem except my alternate build machine has "issues" at
the moment.

The other thing that I have found useful is that I'm now building
with BD Software's STLFilt:
  http://www.bdsoft.com/tools/stlfilt.html
I don't know if this is hiding any errors - I'll try a build with
it turned off and report back if there is anything tomorrow.

To help you get on quickly, I think this patch describes the source
changes that are required to build cleanly without the STLPort:
-------------- StartPatch --------------
--- C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\CyrToolsOS\ctime.hpp	Mon May 17 11:34:44 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\Architecture\CyrToolsOS\ctime.hpp	Tue Jun 21 16:15:47 2005
@@ -42,7 +42,7 @@
 #include <string>
 using std::string;
 #ifdef WIN32
-//#include <windows.h>
+#include <windows.h>
 #endif
--- C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\TestProcess\Common\Atvf\TRecCreator.h	Mon May 17 11:34:50 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\Architecture\TestProcess\Common\Atvf\TRecCreator.h	Fri Jun 24 11:58:31 2005
@@ -32,7 +32,9 @@
  **/
 
 #include <string>
+#pragma warning(disable:4800)
 #include <map>
+#pragma warning(default:4800)
 #ifdef unix
 #elif defined (__VMS)
 #elif defined (WIN32)
--- C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\TestProcess\Common\Base\CECTofTxt.cpp	Mon May 17 11:34:51 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\Architecture\TestProcess\Common\Base\CECTofTxt.cpp	Wed Jun 22 10:31:45 2005
@@ -572,7 +572,7 @@
     // Do the 'ltrim' and return function value.
     string::size_type iOff = ltrimstr.find_first_not_of(" \t\r\n");
     if(iOff == string::npos)
-        resstrP->clear();
+        resstrP->erase();
     else
         *resstrP = ltrimstr.substr(iOff);
     return true;
@@ -664,7 +664,7 @@
     // Do the 'rtrim' and return function value.
     string::size_type iOff = rtrimstr.find_last_not_of(" \t\r\n");
     if(iOff == string::npos)
-        resstrP->clear();
+        resstrP->erase();
     else
         *resstrP = rtrimstr.substr(0, iOff+1);
     return true;
--- C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\TestProcess\Common\Base\TContext.h	Mon May 17 11:34:51 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\Architecture\TestProcess\Common\Base\TContext.h	Fri Jun 24 14:10:33 2005
@@ -38,7 +38,9 @@
 #endif
 
 #include <string>
+#pragma warning(disable:4800)
 #include <map>
+#pragma warning(default:4800)
 #include <set>
 #include <stack>
 #include <list>
--- C:\OpenSTA\sf-rw-src\ostaw32\src\Architecture\xmlparser\XPath.inl	Mon May 17 11:35:14 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\Architecture\xmlparser\XPath.inl	Thu Jun 23 15:28:36 2005
@@ -2643,7 +2643,10 @@
                         if(val2.m_eType == TYPE_NODESET)
                         {
                             // val and val2 are valid. Perform the union.
-                            val.m_nodeSet.insert(val2.m_nodeSet.begin(), val2.m_nodeSet.end());
+                            while(!val2.m_nodeSet.empty()) {
+                                val.m_nodeSet.insert(*(val2.m_nodeSet.begin()));
+                                val2.m_nodeSet.erase(val2.m_nodeSet.begin());
+                            }
                         }
                         else
                             val.Clear();
@@ -2706,7 +2709,10 @@
                         {
                             DocumentOrder order(DocumentOrder::forward);
                             OrderedNodeSet tmpSet(order);
-                            tmpSet.insert(val.m_nodeSet.begin(), val.m_nodeSet.end());
+                            while(!val.m_nodeSet.empty()) {
+                                tmpSet.insert(*(val.m_nodeSet.begin()));
+                                val.m_nodeSet.erase(val.m_nodeSet.begin());
+                            }
                             tmpSet.swap(val.m_nodeSet);
                         }
 
--- C:\OpenSTA\sf-rw-src\ostaw32\src\HTTP\HTMLParser\TagParsing.hpp	Tue May 18 11:41:22 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\HTTP\HTMLParser\TagParsing.hpp	Fri Jun 24 12:18:28 2005
@@ -35,7 +35,9 @@
 #   pragma warning (disable: 4786)
 #endif
 
+#pragma warning(disable:4800)
 #include<map>
+#pragma warning(default:4800)
 
 // This enum contains all the tag types.
 enum Tags
--- C:\OpenSTA\sf-rw-src\ostaw32\src\HTTP\UI\iecacheman\IECache.h	Mon May 17 11:35:36 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\HTTP\UI\iecacheman\IECache.h	Fri Jun 24 12:24:25 2005
@@ -37,7 +37,9 @@
 #endif // _MSC_VER > 1000
 
 #pragma warning (disable: 4786)
+#pragma warning(disable:4800)
 #include <map>
+#pragma warning(default:4800)
 #include <string>
 #include <list>
 
--- C:\OpenSTA\sf-rw-src\ostaw32\src\HTTP\UI\Modeller\EndTimerDlg.cpp	Mon May 17 11:35:34 2004
+++ C:\OpenSTA\ostaw32-nostlp\src\HTTP\UI\Modeller\EndTimerDlg.cpp	Wed Jun 22 11:21:08 2005
@@ -45,7 +45,7 @@
 void CEndTimerDlg::FillList()
 {
 	int index = 0;
-	for (stringStlSet::iterator itr = m_timerSet.begin(); itr != m_timerSet.end(); ++itr, ++index)
+	for (stringStlSet::const_iterator itr = m_timerSet.begin(); itr != m_timerSet.end(); ++itr, ++index)
 	{
 		m_TimerList.InsertString(index, (*itr));
 	}

--------------- End Patch ---------------

Cheers
/dan

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

[OpenSTA-devel] Re: When is Random not random?

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

Peter Wickersham wrote:
> Ok, so now that I can build, I have added a random number generator
> class based on the Mersenne Twister PRNG.  It is fast, uniform, and
> has a long period (iterations before repeating).

That's great!  Can't wait to give it a go ...

> However, I have run into issues in actually getting the seed from
> the script set in the code.  I reviewed the current code in
> CECRangeVar and CECListVar and it looked like those classes were
> always ignoring the seed and just using a random one to start.  So,
> I decided to test this, but I can't seem to get any SEED I set in
> the script to actually get passed into the constuctors for these
> variable classes.  They always get 0, which is the default higher
> in the stack if no seed is specified. 

Nice, I can't believe this one has never been reported before.  I've 
verified and reported this, it's now bug# 1406872:
  http://sourceforge.net/tracker/index.php?func=detail&aid=1406872&group_id=10857&atid=110857
I'm sure you've also seen I've also logged the fact that RANDOMs are
not uniformly distributed.  This is bug# 1406888:
  http://sourceforge.net/tracker/index.php?func=detail&aid=1406888&group_id=10857&atid=110857

I'm not going to log the fact there is a small possibility of
repeatable breaking because of threading and the non-atomicity of
srand(),rand() in the current implementation.  I didn't log because
reproducing wouldn't ever be easy and I'm sure that whatever code
replaces this will bear this possibility in mind, and avoid it
... ;-)

> Does anyone know the SCL parsing/compilation pieces enough to help
> me track down where the SEED seems to get lost.

I just tried out Mark's 1 line fix and tested out the results - seems
to totally fix the problem, which makes sense ... looks like it was
just an oversight somewhere down the line, the runtime looks for
"seed" in the TOF and the SCL compiler creates this qualifier as an
"ivalue".

Once I've got my build environments straight, re: STLport, PSDK, etc.
then I'll commit this into the CVS HEAD.  Hoping this will be
tomorrow...

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

[OpenSTA-devel] [ opensta-Bugs-1406888 ] Distribution of RANDOM variable sequences is non-uniform

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

Bugs item #1406888, was opened at 2006-01-15 17:31
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1406888&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: Daniel Sutcliffe (dansut)
>Assigned to: Daniel Sutcliffe (dansut)
Summary: Distribution of RANDOM variable sequences is non-uniform

Initial Comment:
Given a RANDOM variable you would expect that for every
call to GENERATE there was an equal chance of getting
any of the potential results - this appears to not be
the case and for any set of potential results there
will be certain result values which have a higher
chance of being returned and others which have a lower
chance.

As an example given potential results of 1 and 2, there
is roughly 53% chance of getting a 2 and 47% chance of
getting a 1.  This type/scale of result weighting
applies to all result set sizes - giving a random
result that although "fairly random" could potentially
throw out test results in certain very specific
circumstances.

This problem is present on all platforms for the
OpenSTA 1.4.3 release and earlier.

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

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

[OpenSTA-devel] [ opensta-Bugs-1406888 ] Distribution of RANDOM variable sequences is non-uniform

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

Bugs item #1406888, was opened at 2006-01-15 17:31
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=1406888&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: None
Priority: 5
Submitted By: Daniel Sutcliffe (dansut)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distribution of RANDOM variable sequences is non-uniform

Initial Comment:
Given a RANDOM variable you would expect that for every
call to GENERATE there was an equal chance of getting
any of the potential results - this appears to not be
the case and for any set of potential results there
will be certain result values which have a higher
chance of being returned and others which have a lower
chance.

As an example given potential results of 1 and 2, there
is roughly 53% chance of getting a 2 and 47% chance of
getting a 1.  This type/scale of result weighting
applies to all result set sizes - giving a random
result that although "fairly random" could potentially
throw out test results in certain very specific
circumstances.

This problem is present on all platforms for the
OpenSTA 1.4.3 release and earlier.

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

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

[OpenSTA-devel] [ opensta-Bugs-1406872 ] SEED for REPEATABLE RANDOM variables is ignored

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

Bugs item #1406872, was opened at 2006-01-15 17:05
Message generated for change (Settings changed) made by dansut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1406872&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: Daniel Sutcliffe (dansut)
Assigned to: Daniel Sutcliffe (dansut)
Summary: SEED for REPEATABLE RANDOM variables is ignored

Initial Comment:
The ability to specifiy a SEED value to variables
specified as REPEATABLE RANDOM is intended to give the
possibility of different repeatable psuedo random
sequences being attainable from the same set of
possible results.  In the OpenSTA 1.4.3 release, and
probably all other 1.x releases up to this one, the
specified SEED is ignored completely and the same
repeatable sequence is created whatever value is specified.

There is no real workaround for this issue.

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

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