opensta-devel Mailing List for OpenSTA
Brought to you by:
dansut
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
(19) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(5) |
2002 |
Jan
(17) |
Feb
(11) |
Mar
(11) |
Apr
(16) |
May
(11) |
Jun
(9) |
Jul
(22) |
Aug
(8) |
Sep
(22) |
Oct
(9) |
Nov
(11) |
Dec
(5) |
2003 |
Jan
(15) |
Feb
(26) |
Mar
(35) |
Apr
(85) |
May
(103) |
Jun
(35) |
Jul
(37) |
Aug
(19) |
Sep
(16) |
Oct
(11) |
Nov
(4) |
Dec
(10) |
2004 |
Jan
(11) |
Feb
(24) |
Mar
(7) |
Apr
(1) |
May
(13) |
Jun
(6) |
Jul
(7) |
Aug
(93) |
Sep
(4) |
Oct
(30) |
Nov
(16) |
Dec
(64) |
2005 |
Jan
(30) |
Feb
(4) |
Mar
(8) |
Apr
(22) |
May
(63) |
Jun
(32) |
Jul
(11) |
Aug
(14) |
Sep
(1) |
Oct
(11) |
Nov
(2) |
Dec
(13) |
2006 |
Jan
(53) |
Feb
(6) |
Mar
(6) |
Apr
(6) |
May
(7) |
Jun
(8) |
Jul
(7) |
Aug
(3) |
Sep
(2) |
Oct
(6) |
Nov
(3) |
Dec
(11) |
2007 |
Jan
(2) |
Feb
(9) |
Mar
|
Apr
(10) |
May
(5) |
Jun
(1) |
Jul
(14) |
Aug
(5) |
Sep
|
Oct
(10) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Balaji M <bal...@gm...> - 2013-01-05 09:30:48
|
http://voltashop.nl/kyrsxcm.php |
From: SourceForge.net <no...@so...> - 2012-02-02 07:36:59
|
Bugs item #3483098, was opened at 2012-02-01 23:36 Message generated for change (Tracker Item Submitted) made by popgualy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=3483098&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: vijaysubramanian (popgualy) Assigned to: Nobody/Anonymous (nobody) Summary: Facing an issue in OpenSTA Initial Comment: Hi, I am facing a issue in my current project using OpenSTA I have tried to record the script in OpenSTA using Firefox. I have successfully recorded the script and the script also get generated. In the Script modeler while click the "URL Details"it showing some error message as "The webpage is unavailable because you are offline" in the HTML response page its not possible to view the requested page. Please go through the attached screenshot for your reference Regards Vijay.S ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=3483098&group_id=10857 |
From: SourceForge.net <no...@so...> - 2010-09-01 09:43:29
|
Bugs item #3057317, was opened at 2010-09-01 15:03 Message generated for change (Settings changed) made by mmcsivakumar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=3057317&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: Environment Status: Open Resolution: None >Priority: 9 Private: No Submitted By: Sivakumar Chellappan (mmcsivakumar) Assigned to: Nobody/Anonymous (nobody) Summary: Using SCL, To get the response with load response_info body Initial Comment: For HTTP Service, i can get the response using the below code. CHARACTER*32000 VER_BODY , SCRIPT LOAD RESPONSE_INFO BODY ON 2 INTO VER_BODY LOG "HTTP RESPONSE---'", VER_BODY, "," But while trying with BlazeDS Remote Object, i cant get the response. Just i got the empty value. Can you help me how we can get the response with BlazeDS RemoteObjct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=3057317&group_id=10857 |
From: SourceForge.net <no...@so...> - 2010-09-01 09:33:01
|
Bugs item #3057317, was opened at 2010-09-01 15:03 Message generated for change (Tracker Item Submitted) made by mmcsivakumar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=3057317&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: Environment Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sivakumar Chellappan (mmcsivakumar) Assigned to: Nobody/Anonymous (nobody) Summary: Using SCL, To get the response with load response_info body Initial Comment: For HTTP Service, i can get the response using the below code. CHARACTER*32000 VER_BODY , SCRIPT LOAD RESPONSE_INFO BODY ON 2 INTO VER_BODY LOG "HTTP RESPONSE---'", VER_BODY, "," But while trying with BlazeDS Remote Object, i cant get the response. Just i got the empty value. Can you help me how we can get the response with BlazeDS RemoteObjct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=3057317&group_id=10857 |
From: SourceForge.net <no...@so...> - 2009-10-19 09:31:52
|
Bugs item #2881618, was opened at 2009-10-19 10:31 Message generated for change (Tracker Item Submitted) made by ronlowe5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2881618&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: HTTP Capture Group: Inconvenience Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ron Lowe (ronlowe5) Assigned to: Nobody/Anonymous (nobody) Summary: Possibly invalid proxy setup assumption Initial Comment: When gateway sets up its proxy for recording purposes it assumes that the proxy setting is on a per user basis. This may not be so in some locked down environments, for example domains. It is possible using group policy to set the proxy on a machine basis. If this is so then the proxy settings are stored in an area of the registry where gateway does not look. This means that the proxy setup to allow recording has to be input manually into IE. Applies to: IE6 with latest stable version of OpenSTA ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2881618&group_id=10857 |
From: SourceForge.net <no...@so...> - 2009-08-26 12:35:16
|
Bugs item #2844908, was opened at 2009-08-26 12:35 Message generated for change (Tracker Item Submitted) made by mcheepati You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2844908&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: madhu sudhana reddy (mcheepati) Assigned to: Nobody/Anonymous (nobody) Summary: I am not able to pass paired values in sequence Initial Comment: Hi, I was made some changes in script,that am sending one valu(iccid),it has some corresponding value(esn) this value should pass some where in the script, but it is not taking the values in sequence ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2844908&group_id=10857 |
From: SourceForge.net <no...@so...> - 2009-04-23 19:19:31
|
Bugs item #2779789, was opened at 2009-04-23 15:19 Message generated for change (Tracker Item Submitted) made by doug_eckert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2779789&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 Private: No Submitted By: Doug Eckert (doug_eckert) Assigned to: Nobody/Anonymous (nobody) Summary: Error opening file for output while compiling Initial Comment: Created a test script to yahoo.com and get the following when trying to compile after capture: Compiling... YAHOO.HTP scl: error (openout), Error Opening YAHOO.TOF as Output -Invalid argument Running on a Dell PE1950 w/MS Windows 2008 Std 64-bit. OpenSTA v1.4.4.11 Commander v1.4.4.1 8/29/07 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2779789&group_id=10857 |
From: SourceForge.net <no...@so...> - 2009-04-08 09:01:27
|
Bugs item #2743501, was opened at 2009-04-08 11:01 Message generated for change (Tracker Item Submitted) made by frougeot2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2743501&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: Fatal Error Status: Open Resolution: None Priority: 5 Private: No Submitted By: frederic rougeot (frougeot2) Assigned to: Nobody/Anonymous (nobody) Summary: Test does not open from commander Initial Comment: Just installed Open sta latest version 1.4.4, on XP and also on Vista (two different computers) Don't wait for reboot, I tried instantly, it was not working. Reboot the pc, open commmander, create a test, tryu to open it; nothing happens at all. Maybe due to IE 8 installation ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2743501&group_id=10857 |
From: SourceForge.net <no...@so...> - 2009-01-06 15:52:12
|
Bugs item #2490319, was opened at 2009-01-06 10:52 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=2490319&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Bigham (dbigham) Assigned to: Nobody/Anonymous (nobody) Summary: Corruption of large HTTP POST data Initial Comment: Version: 1.4.4.11 I gave OpenSTA a try yesterday and unfortunately ran into trouble right away. It appears that memory is being blown when HTTP POST data is of a significant size. I'm not sure exactly how large ours is, but it's somewhere between 10 and 50K. The symptoms I've noticed are that when I'm recording a script, the .NET application complains about JSON parsing errors and unexpected tokens. When I examined the script that it had recorded, I noticed a bunch of <00>~<00>~<00> junk, which are likely a representation of null characters. (Several hundred of them) In some cases, after the <00>s, there were old HTTP requests concatenated onto the end of the post data. Definitely seems like corruption. An example: ... ... ... st%22%2C%22targetE~<00>" & "s]~<05>]~<03>~<FC>~<01>~<HT>~<01>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>~<00>" & "vent%22%3A2%2C%22active%22%3Afalse%7D%5D%7D&ctl00_ctl00_bodyContent_ma ... ... ... This is likely a show-stopper for us, so we may need to look at another load testing system. Thanks, Daniel Bigham ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2490319&group_id=10857 |
From: SourceForge.net <no...@so...> - 2008-12-24 11:06:04
|
Bugs item #2464178, was opened at 2008-12-24 16: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=2464178&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Results Analysis Group: Inconvenience Status: Open Resolution: None Priority: 5 Private: No Submitted By: sam (sameer_gitay) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP graphs not displayed Initial Comment: Sometimes, when a user goes to “Results” tab without taking any test run, none of HTTP graphs for previous runs get displayed. After you do a test run, the graphs for previous run are also displayed Version 1.4.4.1 OS Windows XP Professional SP2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=2464178&group_id=10857 |
From: Ivan M. <iva...@gm...> - 2008-12-05 16:16:32
|
Hi Guys, Are there tools or ways for developing OpenSTA modules? How can I start developing modules for OpenSTA rather than enhancing it from source code? Best regards, Ivan |
From: <van...@cr...> - 2008-09-17 04:01:21
|
Hi all, Please suggest me a solution related to the problem I?m getting in OpenSTA. I am not been able to access any web page or website running on HTTPS protocol. On accessing any HTTPS website, I am getting Page cannot Be Displayed Error. Waiting for your reply ASAP Regards, Vanshdeep |
From: SourceForge.net <no...@so...> - 2008-08-25 13:18:31
|
Bugs item #1199408, was opened at 2005-05-11 00:31 Message generated for change (Comment added) made by jos32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199408&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: SNMP Monitor Group: Behavioral Status: Open Resolution: None Priority: 5 Private: No 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: jos (jos32) Date: 2008-08-25 16:18 Message: Logged In: YES user_id=1903527 Originator: NO I can reproduce this bug in this environment: server1: HP-UX B.11.00 U 9000/800 server2: Linux 2.6.9-5.0.3.ELsmp #1 SMP Sat Feb 19 19:38:02 CST 2005 i686 i686 i386 GNU/Linux OpenSTA1: 2003Server OpenSTA2: W2K OpenSTA 1.4.4.11 is used. The same SMP-file is used in the both workstations. OID's are checked using SNMPwalk (included in Net-SNMP 5.4.1.2) in both Windows OpenSTA workstations. An additional workstation (Linux 2.6.9-5.0.3.EL #1 Sat Feb 19 18:26:49 CST 2005 i686 athlon i386 GNU/Linux) is used in Linux to verify OID's by SNMPwalk (NET-SNMP version: 5.1.3.1 ). OpenSTA results: Object type: OID, OpenSTA1 SNMPwalk / OpenSTA2 SNMPwalk server1: 1b) Gauge32: .1.3.6.1.4.1.11.2.3.1.1.7, 12 / 1 2b) Counter32: .1.3.6.1.2.1.2.2.1.11.1, OK result / 0 3b) Gauge32: .1.3.6.1.4.1.11.2.3.1.4.2.1.5.25904, 12 / 1 4b) Gauge32: .1.3.6.1.4.1.11.2.3.1.1.7, 12 / 1 5b) Integer: .1.3.6.1.4.1.11.2.3.1.1.15, 12 / 1 server2: 6b) Counter32: .1.3.6.1.2.1.4.3, 12 / 1 7b) Integer: .1.3.6.1.4.1.2021.10.1.5.1, OK result / OK result Conclusions: Object type is not the issue. SNMPwalk gives reasonable and expectexd result in the each cases. OpenSTA results varies quite a lot. OpenSTA1 gives constant value (error) 12 (twelve) while OpenSTA2 gives 1 (one). As shown in line 2b, OpenSTA1 gives correct response while OpenSTA2 error response. ---------------------------------------------------------------------- Comment By: Christian Baumann (chbaumann) Date: 2008-08-15 16:27 Message: Logged In: YES user_id=2182089 Originator: NO I can reproduce this for all MIB-entries I tried so far ... :( I´m using OpenSTA 1.4.4.11 on a Win XP SP2 machine and querying an SNMP agent running on Red Hat Enterprise Linux. ---------------------------------------------------------------------- Comment By: Vahan Harput (vharput) Date: 2005-05-16 19: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 18: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 |
From: SourceForge.net <no...@so...> - 2008-08-20 21:22:29
|
Bugs item #730317, was opened at 2003-04-30 10:24 Message generated for change (Comment added) made by sam_squarewave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=730317&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: Design Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerome Delamarche (trickyjer) Assigned to: Nobody/Anonymous (nobody) Summary: Bad Windows Auth handling Initial Comment: The script generated by the Modeler when the session requires a login/password cannot be replayed successfully. The Server first challenges for a "Basic" authentification, then it turns this auth. into a NTLM auth. The generated script includes statements such as: BUILD AUTHENTICATION BLOB & FOR BASIC & FROM USER "admin" PASSWORD "" DOMAIN "" & INTO blob_2_1 and further: Load Response_Info Header on 3 & Into blob_3_0 & ,WITH "WWW-Authenticate" BUILD AUTHENTICATION BLOB & FOR NTLM & FROM BLOB blob_3_0 & INTO blob_3_0 But requests are all denied by the Web server. IIS server just require a valid user for itself, it does not belong to a Windows Domain. ---------------------------------------------------------------------- Comment By: samuel greene (sam_squarewave) Date: 2008-08-20 14:22 Message: Logged In: YES user_id=2187702 Originator: NO I would love to see this fixed. I know us windows folks aren't supposed to use open source products though... ---------------------------------------------------------------------- Comment By: Brian Collins (brianavid) Date: 2005-06-23 06:35 Message: Logged In: YES user_id=1214182 Also note that the space declared for NTLM blobs is 256 CHARACTERS, but HTTP www-authenticate responses have been seen larger than this. I manually edit the generated declarations to 512 CHARACTERs to get it to work (mostly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=730317&group_id=10857 |
From: SourceForge.net <no...@so...> - 2008-08-15 13:26:59
|
Bugs item #1199408, was opened at 2005-05-10 23:31 Message generated for change (Comment added) made by chbaumann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199408&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: SNMP Monitor Group: Behavioral Status: Open Resolution: None Priority: 5 Private: No 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: Christian Baumann (chbaumann) Date: 2008-08-15 15:27 Message: Logged In: YES user_id=2182089 Originator: NO I can reproduce this for all MIB-entries I tried so far ... :( Im using OpenSTA 1.4.4.11 on a Win XP SP2 machine and querying an SNMP agent running on Red Hat Enterprise Linux. ---------------------------------------------------------------------- Comment By: Vahan Harput (vharput) Date: 2005-05-16 18: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 17: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 |
From: Ivan M. <iva...@gm...> - 2008-05-14 21:08:02
|
Dear developers of OpenSTA, We enjoyed a lot the work that has been done with OpenSTA. It is the first time we ever took our hands on this kind of work and were surprised by the software maturity. But in order to fully recommend its use to our costumers, it is imperative that we have a few enhancements. And by "recommend" I mean that our costumers would be advised to contribute with donations to the project if they chose to use your software over commercial ones. We would be in no way responsible to force any kind of donations. Back to the enhancements - So to recommend OpenSTA would mean that the product should have support for gziped responses (~EXTRACT, etc) and larger support for command LOAD RESPONSE BODY INTO (i.e. more than 64K). Would any developer be interested in developing these features? If so, how much would it cost? If paid to develop, would it be expected some sort of schedule term agreement? Anyone interested, please make a business proposition by e-mail directly to me. Thanks in advance. Best regards, Ivan |
From: SourceForge.net <no...@so...> - 2008-03-04 15:15:05
|
Bugs item #1907071, was opened at 2008-03-04 10:15 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=1907071&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Architecture Group: Inconvenience Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bernie Velivis (velivis) Assigned to: Nobody/Anonymous (nobody) Summary: DEFAULT_HEADERS "Source Line is Too Long" error Initial Comment: After recording a script, the SCL generated produces source code that will not compile due to the source line being too long. Only occurs when the contents of the DEFAULT_HEADER string is sufficiently long. Example: CONSTANT DEFAULT_HEADERS = "Host: www.google.com^J" & "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; EmbeddedWB 14,52 from: http://www.bsalsa.com/ EmbeddedWB 14.52; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)" Workaround: Manually break the line into a multi-line statement CONSTANT DEFAULT_HEADERS = "Host: www.google.com^J" & "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;" & " EmbeddedWB 14,52 from: http://www.bsalsa.com/ EmbeddedWB 14.52; .NET CLR 1.1.4322; InfoPath.1;" & " .NET CLR 2.0.50727)" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1907071&group_id=10857 |
From: SourceForge.net <no...@so...> - 2007-10-25 14:18:04
|
Bugs item #751953, was opened at 2003-06-10 09:43 Message generated for change (Comment added) made by dragonfyre13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=751953&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: HTTP Capture Group: Inconvenience Status: Open Resolution: None Priority: 3 Private: No Submitted By: James Ward (jmrward) Assigned to: Daniel Sutcliffe (dansut) Summary: Cookie variable size not matched to size of cookies recorded Initial Comment: Cookies that end with "==" lose these characters when saved in a cookie variable. An example from a replayed script is below: 1-1 :[525]:HTTPRESPONSE(18): Setting COOKIE_18_1 to 'SMSESSION=ig/.....sVZgQ==' 1-1 :[529]:LOG: cookie_18_1: SMSESSION=ig/.....sVZgQ Could possibly happen with other trailing characters in cookies. workaround: manually add +"==" after any cookie that is supposed to have these characters ---------------------------------------------------------------------- Comment By: Tim Alexander (dragonfyre13) Date: 2007-10-25 09:18 Message: Logged In: YES user_id=916501 Originator: NO I'll second this, and as I had a bit of trouble understanding the bug report, I will put in a bit of clarification from my perspective. The specific Characters above are not relevant, the length of the Char array is. As it is now, it simply defaults to 1024. However, this is not long enough to handle some cookies (one of mine is almost 3000 chars long) This is quite frustrating, as there is no error, or warning, or anything when it truncates a char field. I would propose this as the solution. I originally had the thought to dynamically resize the cookie Char length when recording it, but as said previously, there is no way to ensure that the cookie will not be a different, larger size next time. This also adds a degree of complexity to what is now a simple process. I believe that logging on truncation is a much cleaner, and much more stable fix for the issue. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-06-25 07:35 Message: Logged In: YES user_id=19748 Thanks for investigating your issue and finding the root cause of your propblem. In future discussing issues like this on the OpenSTA users mailing list first is likely to find you quicker solutions and allow accurate bug descriptions first time: http://lists.sf.net/lists/listinfo/opensta-users I'm not sure there can ever be a perfect answer to this problem though; yes we should make sure the variables are big enough to store the cookies recorded but whose to say that the runtime cookies won't be bigger still. Perhaps we also need some sort of warning generated when filling vars truncates the content as well. ---------------------------------------------------------------------- Comment By: James Ward (jmrward) Date: 2003-06-13 11:37 Message: Logged In: YES user_id=798053 I figured this one out myself. The cookies were not being generated incorrectly. However, the default cookies that the script was declaring were not quite large enough. I realized that the cookie I was having trouble with was 1026 characters long while the automatic cookies were declared as 1024 characters long (cutting off the last two characters, which in this case was "=="). So, the real issue is that automatic cookie generation does not dynamically size the cookies used, which is just inconvenient. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=751953&group_id=10857 |
From: SourceForge.net <no...@so...> - 2007-10-19 02:10:10
|
Bugs item #1773940, was opened at 2007-08-14 11:20 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1773940&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 Private: No Submitted By: steve2k (steve2k) Assigned to: Nobody/Anonymous (nobody) >Summary: Empty SUBROUTINE params cause later params to be invalid Initial Comment: With the Modeler that ships with OpenSTA 1.4.3.20, if you pass an empty string, i.e. "" as a parameter to a subroutine, all following parameters are ignored. There is an example script below. The first time CHECKRESPONSE is called with all 3 parameters populated, it works fine. The second time CHECKRESPONSE is called with the first parameter set to "", it ignores all the parameters and uses the parameters passed the first time. Problem has been confirmed by Bernie Velivis: "I tried a simple subroutine with 4 string args. As soon as one (counting from left to right) is set to "", then all remaining arguments are set to "" or 0 if numeric. Looks like the code that parses arguments passed to subroutines quits when it see's a null. I would definitely report it on sourceforge." ============ EXAMPLE SCRIPT ================== !Browser:IE5 !Date : 14/08/2007 Environment Description "" Mode HTTP Wait UNIT MILLISECONDS Definitions ! Standard Defines Include "RESPONSE_CODES.INC" Include "GLOBAL_VARIABLES.INC" CHARACTER*512 USER_AGENT Integer USE_PAGE_TIMERS CHARACTER*256 MESSAGE CHARACTER*256 p1 CHARACTER*256 p2 CHARACTER*256 p3 Timer T_QQQQ CONSTANT DEFAULT_HEADERS = "" Code !Read in the default browser user agent field Entry[USER_AGENT,USE_PAGE_TIMERS] Start Timer T_QQQQ CALL CHECKRESPONSE["1param1","1param2","1param3"] CALL CHECKRESPONSE["","2param2","2param3"] SYNCHRONIZE REQUESTS End Timer T_QQQQ SUBROUTINE CHECKRESPONSE[p1,p2,p3] Log "Parameter 1:", p1 Log "Parameter 2:", p2 Log "Parameter 3:", p3 END SUBROUTINE Exit ERR_LABEL: If (MESSAGE <> "") Then Report MESSAGE Endif Exit ---------------------------------------------------------------------- Comment By: Bernie Velivis (velivis) Date: 2007-10-15 11:46 Message: Logged In: YES user_id=1868094 Originator: NO Work around: If only one of your parameters may be empty, then make it the last in list of parameters. If more then one parameter may be empty, don't use parameters but instead pass the values in local variables. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1773940&group_id=10857 |
From: SourceForge.net <no...@so...> - 2007-10-19 02:08:21
|
Bugs item #1773940, was opened at 2007-08-14 11:20 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1773940&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 Private: No Submitted By: steve2k (steve2k) Assigned to: Nobody/Anonymous (nobody) >Summary: Empty SUBROUTINparams cause other params to become empty Initial Comment: With the Modeler that ships with OpenSTA 1.4.3.20, if you pass an empty string, i.e. "" as a parameter to a subroutine, all following parameters are ignored. There is an example script below. The first time CHECKRESPONSE is called with all 3 parameters populated, it works fine. The second time CHECKRESPONSE is called with the first parameter set to "", it ignores all the parameters and uses the parameters passed the first time. Problem has been confirmed by Bernie Velivis: "I tried a simple subroutine with 4 string args. As soon as one (counting from left to right) is set to "", then all remaining arguments are set to "" or 0 if numeric. Looks like the code that parses arguments passed to subroutines quits when it see's a null. I would definitely report it on sourceforge." ============ EXAMPLE SCRIPT ================== !Browser:IE5 !Date : 14/08/2007 Environment Description "" Mode HTTP Wait UNIT MILLISECONDS Definitions ! Standard Defines Include "RESPONSE_CODES.INC" Include "GLOBAL_VARIABLES.INC" CHARACTER*512 USER_AGENT Integer USE_PAGE_TIMERS CHARACTER*256 MESSAGE CHARACTER*256 p1 CHARACTER*256 p2 CHARACTER*256 p3 Timer T_QQQQ CONSTANT DEFAULT_HEADERS = "" Code !Read in the default browser user agent field Entry[USER_AGENT,USE_PAGE_TIMERS] Start Timer T_QQQQ CALL CHECKRESPONSE["1param1","1param2","1param3"] CALL CHECKRESPONSE["","2param2","2param3"] SYNCHRONIZE REQUESTS End Timer T_QQQQ SUBROUTINE CHECKRESPONSE[p1,p2,p3] Log "Parameter 1:", p1 Log "Parameter 2:", p2 Log "Parameter 3:", p3 END SUBROUTINE Exit ERR_LABEL: If (MESSAGE <> "") Then Report MESSAGE Endif Exit ---------------------------------------------------------------------- Comment By: Bernie Velivis (velivis) Date: 2007-10-15 11:46 Message: Logged In: YES user_id=1868094 Originator: NO Work around: If only one of your parameters may be empty, then make it the last in list of parameters. If more then one parameter may be empty, don't use parameters but instead pass the values in local variables. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1773940&group_id=10857 |
From: SourceForge.net <no...@so...> - 2007-10-18 13:40:47
|
Bugs item #1406888, was opened at 2006-01-15 17:31 Message generated for change (Comment added) made by velivis 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: Closed Resolution: Accepted Priority: 5 Private: No 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. ---------------------------------------------------------------------- >Comment By: Bernie Velivis (velivis) Date: 2007-10-18 08:40 Message: Logged In: YES user_id=1868094 Originator: NO Dan wrote: "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 is not true. True random number generators will generate duplicates quite often. However this does tend to even out over time (larger ranges and more samples both lead to more uniform distributions). The randomness of a set of numbers can be quantified by calculating the standard deviation. I generated 100 random numbers in SCL and using the Excel STDEVA function calculated a standard deviation of 28. I also created a list of 100 numbers using the excel rand() function and for it I calculated a standard deviation of 31 (slightly more random). Both lists contained many duplicates. If you want to generate a list of pseudo random numbers with no repeating values, generate it outside of SCL, randomize its order, and import the numbers into a list of integers and use the NEXT command to access them sequentially ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1406888&group_id=10857 |
From: SourceForge.net <no...@so...> - 2007-10-18 13:13:14
|
Bugs item #1516604, was opened at 2006-07-03 15:11 Message generated for change (Comment added) made by velivis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1516604&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: Behavioral Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Danny Faught (faught) Assigned to: Daniel Sutcliffe (dansut) Summary: Batch startup options unintuitive and don't work as intended Initial Comment: There is a timing problem when I check "Introduce Virtual Users in Batches". This is most noticable if I'm starting VUs no faster than 1 per second. If there is more than one batch, then the actual batch ramp up time is less than what I specify. The actual ramp up time is "(specified) ramp up time" divided by "number of users per batch" too short. I'm running OpenSTA 1.4.3.20. An example illustrating this issue is posted at http://portal.opensta.org/modules.php?op=modload&name=phpWiki&pagename=TestBatchOptions&file=index. Another problem mentioned there - the time between VUs within the last batch is longer than for all other batches if the total number VUs in the task group is not evenly divisible by the number of users per batch. ---------------------------------------------------------------------- >Comment By: Bernie Velivis (velivis) Date: 2007-10-18 08:13 Message: Logged In: YES user_id=1868094 Originator: NO The smaller the number of VUs, the worse the problem. Ramping 5 users over 5 minutes it is noticeable. Ramping 40 users over 5 minutes it was not. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2006-12-11 19:42 Message: Logged In: YES user_id=19748 Originator: NO See this mail Thread for more info and thoughts: http://sourceforge.net/mailarchive/message.php?msg_id=16520493 As I say in the mails there - unlikely to see a fix in the 1.4 series but at least its logged for the future ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1516604&group_id=10857 |
From: SourceForge.net <no...@so...> - 2007-10-17 18:51:09
|
Bugs item #1570977, was opened at 2006-10-04 16:23 Message generated for change (Settings changed) made by velivis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1570977&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: Documentation Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Jerome Delamarche (trickyjer) Assigned to: Nobody/Anonymous (nobody) Summary: ACQUIRE MUTEX Initial Comment: The SCL Manual says "ACQUIRE MUTEX" is used for inter- script synchronization. It also says the Timeout value is in seconds. It appears that: - ACQUIRE MUTEX works also to synchronize threads (and fortunately it works !) - the Timeout value is dependent of the WAIT UNIT instruction - the ON TIMEOUT GOTO and ON ERROR GOTO clauses are mandatory to avoid a "TOF error" at runtime ---------------------------------------------------------------------- Comment By: Bernie Velivis (velivis) Date: 2007-10-17 13:49 Message: Logged In: YES user_id=1868094 Originator: NO The SCL manual says that ACQUIRE MUTEX is used to synchronize either scripts running on the local machine (scope local) or all scripts across all injectors (Test-wide). It works as documented. The ON TIMEOUT and ON ERROR clauses are documented as being optional and I am unable to reproduce TOF errors by omitting them. The SCL documentation in the modeler states incorrectly that units for the wait time in the ACQUIRE MUTEX command are in seconds. All my testing shows the wait time units for the ACQUIRE MUTEX command are in milliseconds regardless of WAIT UNIT (seconds or milliseconds). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1570977&group_id=10857 |
From: SourceForge.net <no...@so...> - 2007-10-17 18:49:13
|
Bugs item #1570977, was opened at 2006-10-04 16:23 Message generated for change (Comment added) made by velivis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1570977&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: Documentation Group: None Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Jerome Delamarche (trickyjer) Assigned to: Nobody/Anonymous (nobody) Summary: ACQUIRE MUTEX Initial Comment: The SCL Manual says "ACQUIRE MUTEX" is used for inter- script synchronization. It also says the Timeout value is in seconds. It appears that: - ACQUIRE MUTEX works also to synchronize threads (and fortunately it works !) - the Timeout value is dependent of the WAIT UNIT instruction - the ON TIMEOUT GOTO and ON ERROR GOTO clauses are mandatory to avoid a "TOF error" at runtime ---------------------------------------------------------------------- >Comment By: Bernie Velivis (velivis) Date: 2007-10-17 13:49 Message: Logged In: YES user_id=1868094 Originator: NO The SCL manual says that ACQUIRE MUTEX is used to synchronize either scripts running on the local machine (scope local) or all scripts across all injectors (Test-wide). It works as documented. The ON TIMEOUT and ON ERROR clauses are documented as being optional and I am unable to reproduce TOF errors by omitting them. The SCL documentation in the modeler states incorrectly that units for the wait time in the ACQUIRE MUTEX command are in seconds. All my testing shows the wait time units for the ACQUIRE MUTEX command are in milliseconds regardless of WAIT UNIT (seconds or milliseconds). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1570977&group_id=10857 |
From: SourceForge.net <no...@so...> - 2007-10-17 17:21:44
|
Bugs item #1622218, was opened at 2006-12-26 00:06 Message generated for change (Comment added) made by velivis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1622218&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Architecture Group: Serious Status: Open Resolution: None Priority: 5 Private: No Submitted By: justin (justinhungthai) Assigned to: Nobody/Anonymous (nobody) Summary: Time Limit donot run correctly when setup time overcome 24h Initial Comment: Hi all, I setup time of "After fixed time" of Stop stask group is 36h. If I return back GUI to check it, its value is 12:00:00 and the OpenSTA will run test in 12h. Any people meet the above problem as me, please help me. Thank you in advance ---------------------------------------------------------------------- >Comment By: Bernie Velivis (velivis) Date: 2007-10-17 12:21 Message: Logged In: YES user_id=1868094 Originator: NO Further investigation shows there are two distinct issues with time limits; 1) Occasionally when time limit expires, VU count drops to the single digits but the task group and subsequently the test does not end. 2) When setting time limit > 23, it is set to the new number modulo 24. (e.g. 24 become 0, 25 becomes 1, etc.) ---------------------------------------------------------------------- Comment By: Bernie Velivis (velivis) Date: 2007-10-15 10:32 Message: Logged In: YES user_id=1868094 Originator: NO I encounter this problem frequently. Using a single task group, I run a one hour test where I introduce users in batches of N/4 users with ramp up time of 5 minutes and time between batches of 10 minutes. At the end of one hour, most of the VUs are stopped, but very often I seen from 1 to 3 VUs "stuck" which prevents the test from ending properly. Stopping the test manually (black square button in Commander) terminates the test, but half the time the HTTP* reports (e.g. HTTP monitored bytes/sec) graphs do not appear in the test results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1622218&group_id=10857 |