opensta-devel Mailing List for OpenSTA (Page 5)
Brought to you by:
dansut
Menu
▾
▴
opensta-devel — OpenSTA developer discussions
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: SourceForge.net <no...@so...> - 2006-07-13 20:40:13
|
Bugs item #1522078, was opened at 2006-07-13 16:40 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=1522078&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Architecture Group: Design Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Using OpenSTAs tools without Admin privs gives poor errors Initial Comment: It was never originally intended that OpenSTA be run as anything as a user with Administration privs - that being said if it is attempted the errors and symptoms the tools show are not at all obvious as to what the problem is. This bug exists mainly to alert the user to the above fact and to point to this FAQ entry: http://portal.opensta.org/faq.php?topic=NonAdminProblems If you hit new symptoms that are not mentioned in the above FAQ then please add them to that FAQ and not this bug request. The solution of this bug may be: to simply cause the tools to fail gracefully with good error messages in this situation, to fix the tools so they can run, or some conbination of the above. The direction that is taken will depend on information gethered through the FAQ entry and discussed on the OpenSTA-Users mailing list. Please also reference bug#1199254 which addresses similar issues attempting to run OpenSTA on WinXP Home edition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1522078&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-07-13 19:50:09
|
Bugs item #1468855, was opened at 2006-04-11 17:06 Message generated for change (Comment added) made by dansut 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: Deleted >Resolution: Duplicate Priority: 5 Submitted By: John Arrowwood (jarrowwx) Assigned to: Nobody/Anonymous (nobody) Summary: 'LOAD RESPONSE_INFO' affected by subroutine order 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. ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2006-07-13 15:50 Message: Logged In: YES user_id=19748 Problem deleted as there is no specific problem 'lost in confusion' here just a whole can of worms that needs addressing as a single issue. The mentioned 2 existing problems have now been merged and bug#645735 should be referenced for the status of problems in this area. Please check this FAQ: http://portal.opensta.org/faq.php?topic=NoDataForConnection Also it should be noted that this report would never have happend if the poster had followed the instruction: "Before submitting any new problem here, please check the FAQ, specifically the entry on reporting bugs" that is in bold large letters at the top of the form to submit new bugs. ---------------------------------------------------------------------- Comment By: John Arrowwood (jarrowwx) Date: 2006-04-13 14:25 Message: Logged In: YES user_id=1500024 The following demonstrates the problem: ----- BEGIN ----- Environment description "" mode http wait unit milliseconds Definitions CHARACTER*255 server CHARACTER*255 path CHARACTER*65535 headers CHARACTER*65535 body_text Code SET server = 'www.google.com' CALL Get [ '/' ] SUBROUTINE DebugRequest LOAD Response_Info Header ON 1 INTO headers LOAD Response_Info Body ON 1 INTO body_text LOG headers LOG body_text END SUBROUTINE SUBROUTINE Get [ path ] PRIMARY GET URI "http://"+server+path+" HTTP/1.0" ON 1 & HEADER "Host: "+server & ,WITH { "User-Agent: testing" } CALL DebugRequest END SUBROUTINE ----- END ----- The following DOES NOT demonstrate the problem. Notice how subtle the difference? ----- BEGIN ----- Environment description "" mode http wait unit milliseconds Definitions CHARACTER*255 server CHARACTER*255 path CHARACTER*65535 headers CHARACTER*65535 body_text Code SET server = 'www.google.com' CALL Get [ '/' ] SUBROUTINE Get [ path ] PRIMARY GET URI "http://"+server+path+" HTTP/1.0" ON 1 & HEADER "Host: "+server & ,WITH { "User-Agent: testing" } CALL DebugRequest END SUBROUTINE SUBROUTINE DebugRequest LOAD Response_Info Header ON 1 INTO headers LOAD Response_Info Body ON 1 INTO body_text LOG headers LOG body_text END SUBROUTINE ----- END ----- The only difference is subroutine declaration order! This ought to give the developers a great way to narrow down what is going on. And it may well be that fixing this will fix some other subtle and hard to reproduce bugs, as well. ---------------------------------------------------------------------- Comment By: John Arrowwood (jarrowwx) Date: 2006-04-13 13:55 Message: Logged In: YES user_id=1500024 Sample code that reproduces the issue, that can be used to debug the problem: Environment description "" mode http wait unit milliseconds Definitions ! HTTP Global Variables INTEGER connection_id CHARACTER*255 server CHARACTER*255 path CHARACTER*255 referrer CHARACTER*65535 headers CHARACTER*1024 cookie_temp CHARACTER*1024 cookie_contents CHARACTER*1024 redirect CHARACTER*65535 body_text INTEGER body_length_int CHARACTER*5 body_length_char INTEGER DEBUG CONSTANT USER_AGENT = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" Code SET DEBUG = 1 SET server = 'www.google.com' CALL Get [ '/' ] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE NextConnection IF ( connection_id > 0 ) THEN DISCONNECT FROM connection_id ENDIF SET connection_id = connection_id + 1 END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE CheckPath IF ( path <> redirect ) THEN IF ( redirect <> "" ) THEN LOG "Requesting: ", path LOG "Expecting: ", redirect ENDIF ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE DebugRequest IF ( DEBUG = 1 ) THEN LOAD Response_Info Header ON connection_id INTO headers LOAD Response_Info Body ON connection_id INTO body_text LOG headers LOG body_text ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE UpdateCookie LOAD Response_Info Header ON connection_id INTO cookie_temp, WITH "Set-Cookie,PHPSESSID" IF ( cookie_temp <> "" ) THEN SET cookie_contents = cookie_temp ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE CheckRedirect LOAD Response_Info Header ON connection_id INTO redirect, WITH "Location" IF ( redirect = "/system_errors/please_login.php" ) THEN LOG "!!!!! Oops !!!!!" EXIT ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE Post [ path, body_text ] CALL CheckPath CALL NextConnection SET body_length_int = ~LENGTH( body_text ) CONVERT body_length_int TO body_length_char LOG body_length_char LOG body_text PRIMARY POST URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " & "application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, " & "application/x-shockwave-flash, */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Content-Type: application/x-www-form-urlencoded", & "Connection: Keep-Alive", & "Content-Length: " + body_length_char, & "Pragma: no-cache", & "Cookie: "+cookie_contents & } & ,BODY body_text CALL DebugRequest CALL CheckRedirect SET referrer = path END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE Get [ path ] CALL CheckPath CALL NextConnection PRIMARY GET URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " & "application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, " & "application/x-shockwave-flash, */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Connection: Keep-Alive", & "Pragma: no-cache", & "Cookie: "+cookie_contents & } CALL DebugRequest CALL CheckRedirect SET referrer = path END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE RefersTo [ path ] CALL NextConnection GET URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Connection: Keep-Alive", & "Cookie: "+cookie_contents & } END SUBROUTINE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1468855&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-07-13 19:44:34
|
Bugs item #645735, was opened at 2002-11-29 10:11 Message generated for change (Comment added) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=645735&group_id=10857 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: Inconvenience Status: Open Resolution: Accepted Priority: 5 Submitted By: Ralph Hendriks (ralluph) Assigned to: Daniel Sutcliffe (dansut) >Summary: LOAD RESPONSE_INFO => No data available for connection Initial Comment: The script compiler allows the connection ID parameter in a LOAD RESPONSE_INFO command to be an integer variable, value or expression, as documented in the SCL Reference Guide. It appears that the HTTP Task Group Executer code only allows an integer value. This makes it uncomfortable to parametrize conid's. see also: http://sourceforge.net/mailarchive/forum.php? thread_id=1355570&forum_id=4763 used version: OpenSTA 1.4.1 on Windows 2000 SP 3 ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2006-07-13 15:44 Message: Logged In: YES user_id=19748 The below info comes from the now closed bug#433574 - this area obviously has many more problems than the original bug report and this bug is now being used as a hold all for problems in this area. Rather than adding more info here please discuss your theories on the Users list AFTER reading this FAQ: http://portal.opensta.org/faq.php?topic=NoDataForConnection Charlie JH original report: ------------------------------------------ The following error occurs on the LOAD RESPONSE_INFO (HEADER or BODY) command during replay: !HTTPRESPONSE: No data available for connection id(1) !TScript::run: ERROR: TOF execution failed !Script Execution Failed. >From the test commander, it shows up as a W* ERROR script execution error with the same message. This error has a very high occurrence (50+%) under specific conditions: 1) When the time between web interactions is greater than 40 seconds (i.e. WAIT 40000 [ms]). 2) When the LOAD RESPONSE_INFO statement is in a subroutine separate from the PRIMARY GET. The interesting thing is that when I put the LOAD RESPONSE_INFO statement back into the same subroutine as the PRIMARY GET, the error pretty much disappears, even with large wait times between web interactions. Similarly, when the time between web interactions is lessened, the errors are less frequent, even when the LOAD_RESPONSE_INFO statement is in a subroutine separate from the PRIMARY GET. The error also seems to occur sometimes on the very first web interaction (the LOAD RESPONSE_INFO command after the first PRIMARY GET). ---------------------------------------- The now closed bug#433574 contains more information and should be checked. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2005-04-25 18:08 Message: Logged In: YES user_id=19748 There is something much more subtle going on here. My earlier provided fix does not work all the time and Antony's IF fix makes little sense if this is really a SCL syntax problem. I have also found that adding a LOAD REPONSE_INFO HEADER on the same conid and request causes the LOAD RESPONSE_INFO BODY to work fine. My suspicions are now that this has something to do with event sequencing and using a variable for the connection id somehow doesn't cause the LOAD command to wait until it is sensible to perform - the evidence that this is not the case is that a SYNCHRONIZE before the LOAD does not help... I give in. Workaround: Do a LOAD RESPONSE_INFO HEADER on the same connection id variable and request. ---------------------------------------------------------------------- Comment By: Antony Marcano (antonym) Date: 2003-11-18 01:47 Message: Logged In: YES user_id=403001 Another observation: When the "LOAD RESPONSE_INFO BODY ON iVar" is wrapped in an "if then" statement the integer variable does not require the integer expression work-around. i.e. The integer variable can be used as you would expect. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-09-15 13:55 Message: Logged In: YES user_id=19748 Problem reported again by Antony Marcano of etest associates - details below come from his bug report (804342) which is merged with this report and removed: Playback error (in Modeller and Commander): --------------------------------------------- TModeller_Web.exe|1632|1-1|FE_HOME|64|E*HTTPRESPONSE: No data available for connection id(1) TModeller_Web.exe|1632|1-1|FE_HOME|64|E*TScript::run: ERROR in TOF execution; resuming at ON ERROR handler. 1-1 :[286]:LABEL: ERR_LABEL --------------------------------------------- Above error occurs when using INTEGER variable or array as the connection ID: LOAD RESPONSE_INFO BODY ON conID (Where conID is an Integer variable; eg. conID=1) Or: LOAD RESPONSE_INFO BODY ON conID[1] (Where conID[] is an array of INTEGERS; e.g. conID[1]=1) This does not affect RESPONSE_INFO HEADER. It is possible to use an integer variable. ---- Dan - Some extra info: Providing an Integer expression works fine, so a sneaky workaround for this is to do something like: LOAD RESPONSE_INFO BODY ON (0+conID) INTO ... Alll other HTTP commands which use conid's appear to work fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=645735&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-07-13 19:32:49
|
Bugs item #433574, was opened at 2001-06-15 18:17 Message generated for change (Comment added) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=433574&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: HTTP Replay Group: Crash >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Charlie Hewett (cjhewett) Assigned to: Daniel Sutcliffe (dansut) Summary: Replay may fail during LOAD RESPONSE_INFO Initial Comment: The following error occurs on the LOAD RESPONSE_INFO (HEADER or BODY) command during replay: !HTTPRESPONSE: No data available for connection id(1) !TScript::run: ERROR: TOF execution failed !Script Execution Failed. >From the test commander, it shows up as a W* ERROR script execution error with the same message. This error has a very high occurrence (50+%) under specific conditions: 1) When the time between web interactions is greater than 40 seconds (i.e. WAIT 40000 [ms]). 2) When the LOAD RESPONSE_INFO statement is in a subroutine separate from the PRIMARY GET. The interesting thing is that when I put the LOAD RESPONSE_INFO statement back into the same subroutine as the PRIMARY GET, the error pretty much disappears, even with large wait times between web interactions. Similarly, when the time between web interactions is lessened, the errors are less frequent, even when the LOAD_RESPONSE_INFO statement is in a subroutine separate from the PRIMARY GET. The error also seems to occur sometimes on the very first web interaction (the LOAD RESPONSE_INFO command after the first PRIMARY GET). ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2006-07-13 15:32 Message: Logged In: YES user_id=19748 Merging the relevant info from this bug in with 645735 and closing as this area seems to be a can of worms and want it all addressed at one time until it is clear there are in fact multiple distinct problems. ---------------------------------------------------------------------- Comment By: vectorGirl (vectorgirl) Date: 2004-03-02 13:53 Message: Logged In: YES user_id=988955 I was experiencing similar problems with a set of scripts. Each script replayed fine from modeller or by itself in a test, but when I combined the scripts in the test, or added multiple users, I would start to get errors on LOAD RESPONSE_INFO commands. I tried some of the work arounds listed here, but I still had errors. The different scripts all use a common set of subroutines, via an include, one for each app function with a PRIMARY POST and related LOADS and GETS. I found that the problems would begin with certain subroutines which had multiple LOAD RESPONSE_INFO statements. I rewrote the subroutines to do a single monolithic LOAD RESPONSE_INFO into a string variable long enough to cover the data I needed, then replaced the other LOAD statements with code to extract the data I needed from the dump string. It's not very pretty, though for some of the data it's actually simpler and it seems to have cleared up the problem in my tests. There's a chance these tests will lead into a bigger project for the same client. If so, perhaps then I can invest some time looking at the code behind it. Until then, hope this helps. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-10 11:58 Message: Logged In: NO Can someone explain the LOAD RESPONSE_INFO and SYNCHRONIZE REQUEST commands? If I put synch request before a load response should that force the script to wait until it receives the response from the primary get/post before trying to load the response? So I imagine that if I'm getting "HTTPRESPONSE: No data available for connection id(1) !TScript::run: ERROR: TOF execution failed !Script Execution Failed. " Errors it's because the page did not return properly? Thanks, ---------------------------------------------------------------------- Comment By: Marius Strumyla (i5mast) Date: 2001-11-08 13:40 Message: Logged In: YES user_id=76189 i've had this problem, too. here's what i did to fix it. the pattern of a script that would _occasionally_ fail looked like this. PRIMARY GET ... ON 1 GET <image> ON 2 DISCONNECT FROM 1 SYCHRONIZE REQUESTS PIMARY GET ... ON 2 LOAD RESPONSE_INFO BODY ON 2 ! here i would get a failure INTO ... this script would run fine from Script Modeler, but would fail with 2 virtual users (however, not always). so, i inserted DISCOENNCT FROM 2 line before SYNCHRONIZE REQUESTS. that reduced the frequency of this failure, but still didn't remove it completely. the next thing i did was added a line DISCONNECT ALL at the end of a script. PRIMARY GET ... ON 1 GET <image> ON 2 DISCONNECT FROM 1 SYCHRONIZE REQUESTS PIMARY GET ... ON 2 LOAD RESPONSE_INFO BODY ON 2 ! here i would get a failure INTO ... DISCONNECT ALL some interesting notes... when you record a script and press [] button to finish the script recording, Script Modeler doesn't close opened http connections. closing browser, however, finishes script recording in the right way. all opened connections are closed. i'm saying this, because when i recorded my scripts i would finish them in both ways. therefore, i think, some of my scripts had these failures while the others didn't. ---------------------------------------------------------------------- Comment By: David K Gleeson (nzrower) Date: 2001-06-18 18:46 Message: Logged In: YES user_id=248364 -- This describes exactly the problem that I am having as well. I make several long web requests, > 1500 ms, however this is not related. I took the WAIT statements out when I learned that the LOAD RESPONSE_INFO HEADER / BODY command waits until the request is complete. I am using POST requests. the follow scenario also avoided this issue (placing the code from the function call inline, and also calling the function straight after): PRIMARY POST URI "http://myURL/url" ON 33 & HEADER DEFAULT_HEADERS & ,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms" & "-powerpoint, application/vnd.ms-excel, application/msword, */*", & "Accept-Language: en-us", & "Content-Type: application/x-www-form-urlencoded", & "Content-Length: 411", & "Pragma: no-cache", & "Cookie: "+S_cookie_5_0+"; "+S_cookie_5_1+"; "+cookie_5_0} & ,BODY "<!-- request body goes here -->" !! this is the function call DUMP_RESPONSE contents inserted inline load response_info header on 33 into VAR_TMP set buf = "x_33_h.txt" open buf as ofile for output write VAR_TMP to ofile close ofile !! call DUMP_RESPONSE, inserted from an included file !! someplace DUMP_RESPONSE(33, "x_33_h2.txt") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=433574&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-07-03 20:11:31
|
Bugs item #1516604, was opened at 2006-07-03 15:11 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=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: None Priority: 5 Submitted By: Danny Faught (faught) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1516604&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-06-17 07:14:41
|
Bugs item #1507652, was opened at 2006-06-17 09:14 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=1507652&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: denis-0 (denis-0) Assigned to: Nobody/Anonymous (nobody) Summary: CFilterDlg::OnGetdispinfoUserIdList bug Initial Comment: Hello This following code from the FilterDlg.cpp file probably has a bug. void CFilterDlg::OnGetdispinfoUserIdList(NMHDR* pNMHDR, LRESULT* pResult) { LV_DISPINFO* pDispInfo = (LV_DISPINFO*)pNMHDR; LV_ITEM &lv = pDispInfo->item; if(lv.mask | LVIF_TEXT ) { lv.pszText = m_arstrUserIds[lv.iItem].GetBuffer(0); } *pResult = 0; } lv.mask & LVIF_TEXT was probably meant instead of lv.mask | LVIF_TEXT Best regards Denis Linine ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1507652&group_id=10857 |
|
From: <co...@go...> - 2006-06-16 02:12:29
|
here is the doc i was talking about: www.goldb.org/docs/opensta_log_analysis.pdf i'll respond to antony's comments when i get a few minutes. does anyone have other ideas? or is anyone working with OpenSTA in a unique way that users or developers might benefit from? suggestions welcome.. post to the list. -corey ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Antony M. \(e. associates\)
<ant...@et...> - 2006-06-12 21:26:30
|
> -----Original Message----- > From: co...@go... > > Hey Antony, > I was hoping you'd show up here :) [Antony Marcano] Glad to oblige :-) > Well I am writing a document that goes into some detail on what I have > done so > far.. basically I have had 2 marathon hacking weekends working on this, > and > thats all. It wasn't until 2 night ago that I even realized the stuff I'm > working on was applicable for use with OpenSTA. [Antony Marcano] Cool! Look forward to reading about it > I meant in terms of dynamically typed and interpreted (though the > definition of > "interpreted" and "compiled" is so blurred these days i'm not sure that > even > means anything). [Antony Marcano] Fair enough. > > > > I'd encourage choosing the language carefully, however. It should be > based > > on the best one for the task. If Python is the language then great! But > it > > shouldn't be based on familiarity... > > absolutely.. if others have ideas, I'd love to discuss them. I have lots > of > ideas regarding language selection and would happy to elaborate on my > thoughts. [Antony Marcano] That's why I tried to start a list of categories to help the short list (see previous e-mail). > well.. right now as far as I can tell, the developer community is mostly > dormant > except for a trickle of bug reports and patches.. nothing is really going > on (or > has anything beyond the opensta-devel discussions been done?). So, if a > process > of language selection and architecture is done.. who is willing to > implement the > chosen design? If people are out there watching this list and want to get > involved, please speak up. I'm sure we all have our ideas about languages > and > methodologies and how development should be done. We went through that > excersize a few years back but nothing much came of it. Perhaps things > have > changed and it is worthwhile to explore again. I would be happy to > participate > in that process. However, once that concludes, people need to throw down > and > start writing code... we never made it there last time. [Antony Marcano] Sounds like a plan. Perhaps, if we get a short-list, we might then be able to spike a couple of approaches to get a better feel. > > What I am saying is that I have something built.. working code. Whether > or not > this is an implementation that others want to collaborate on and extend.. > or > feel should be part of the future of OpenSTA.. is another story :) I am > working on something unrelated to OpenSTA and will have a a full GUI > framework > for parsing logs, creating time series, running numerical calculations, > and > graphic output. I was able to adapt it to work with OpenSTA timer logs in > < 10 > lines of code. So this is going to be available.. and it's in Python ;) > sort > of independent to discussions by the opensta-devel community. [Antony Marcano] Cool... if nothing else it prompted this discussion... If I am honest, I am pushed to the limit in my day-to-day life at the moment but happy to throw my 2 pence/cents worth in once in a while if it helps in any small way. Antony |
|
From: <co...@go...> - 2006-06-11 22:51:18
|
Hey Antony, I was hoping you'd show up here :) > Dan and I discussed this at length in Hebden Bridge and I believe that it > has to be the next big step! good to see we have early concensus. > I'd like to take a look at what you've done but so short of time it would be > really hard to fit it in... Well I am writing a document that goes into some detail on what I have done so far.. basically I have had 2 marathon hacking weekends working on this, and thats all. It wasn't until 2 night ago that I even realized the stuff I'm working on was applicable for use with OpenSTA. > So, when you say "dynamic" what do you mean? As in dynamic typing or > interpreted or just one that has an active community? I meant in terms of dynamically typed and interpreted (though the definition of "interpreted" and "compiled" is so blurred these days i'm not sure that even means anything). > I'd encourage choosing the language carefully, however. It should be based > on the best one for the task. If Python is the language then great! But it > shouldn't be based on familiarity... absolutely.. if others have ideas, I'd love to discuss them. I have lots of ideas regarding language selection and would happy to elaborate on my thoughts. > I'd encourage looking at the features we want and start - one by one - > implementing enough of the GUI, intermediate layers and Bridges (as in > Bridge Design Pattern) for the core to support each feature (i.e. using an > Agile approach). well.. right now as far as I can tell, the developer community is mostly dormant except for a trickle of bug reports and patches.. nothing is really going on (or has anything beyond the opensta-devel discussions been done?). So, if a process of language selection and architecture is done.. who is willing to implement the chosen design? If people are out there watching this list and want to get involved, please speak up. I'm sure we all have our ideas about languages and methodologies and how development should be done. We went through that excersize a few years back but nothing much came of it. Perhaps things have changed and it is worthwhile to explore again. I would be happy to participate in that process. However, once that concludes, people need to throw down and start writing code... we never made it there last time. What I am saying is that I have something built.. working code. Whether or not this is an implementation that others want to collaborate on and extend.. or feel should be part of the future of OpenSTA.. is another story :) I am working on something unrelated to OpenSTA and will have a a full GUI framework for parsing logs, creating time series, running numerical calculations, and graphic output. I was able to adapt it to work with OpenSTA timer logs in < 10 lines of code. So this is going to be available.. and it's in Python ;) sort of independent to discussions by the opensta-devel community. -Corey Goldberg www.goldb.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: <co...@go...> - 2006-06-11 19:50:20
|
Quoting "Danny R. Faught" <fa...@te...>: > I have been considering doing something like this in Perl. I already > built a Perl utility with a GUI front end that configures an SCL script > I wrote for a client, and I've been considering expanding it to do > monitoring and results analysis as well. I'm very interested in seeing > what you've done. Cool.. I've done quite a bit of tool development over the years and Perl is an old favorite.. I'd be interested in seeing what you have done and what ideas you have also. But I absolutely want something in Python.. I am working on another project that will be able to share most of the code base I want to finish building... I also have a lot of experience in large Perl development projects and have some personal issues with it for larger projects. > For a permanent replacement of the Commander, it may be more feasible to > stick with C++ and just switch to the gcc compiler (I'm sure this has > been discussed here at length before I joined the list). Well the problem with the Commander is that it is developed in an older version of MFC.. which ties it pretty tight to a complex build environment with lots of proprietary dependencies. I'm sure Dan could elaborate, but that was my impression. I am imaging more of a complete new GUI framework. The end goal would be to create a portable OpenSTA "core", which only includes the SCL compilation, and batch execution components. This seems straightforward enough since the components are currently compiled into modular executables. Perhaps this would help create a build environment free of platform dependencies, os specific compilers, and proprietary libraries. If that happened, I could picture significantly more developer appeal. I have no idea the feasibility of this part (Dan?). > But for > interim solutions that just solve some interesting subset of the > problem, I thinking a scripting language is the way to go. totally agree. I'll post more later with some info on what I have done so far. -Corey ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Danny R. F. <fa...@te...> - 2006-06-11 13:08:11
|
co...@go... wrote: > I would like to post a document showing my results analysis module in Python. > Would people be interested in seeing it? I have been considering doing something like this in Perl. I already built a Perl utility with a GUI front end that configures an SCL script I wrote for a client, and I've been considering expanding it to do monitoring and results analysis as well. I'm very interested in seeing what you've done. For a permanent replacement of the Commander, it may be more feasible to stick with C++ and just switch to the gcc compiler (I'm sure this has been discussed here at length before I joined the list). But for interim solutions that just solve some interesting subset of the problem, I thinking a scripting language is the way to go. -- Danny R. Faught Tejas Software Consulting http://tejasconsulting.com/ |
|
From: Antony M. \(e. associates\)
<ant...@et...> - 2006-06-11 12:33:07
|
Hi Corey, Dan and I discussed this at length in Hebden Bridge and I believe that = it has to be the next big step!=20 I'd like to take a look at what you've done but so short of time it = would be really hard to fit it in...=20 So, when you say "dynamic" what do you mean? As in dynamic typing or interpreted or just one that has an active community? I think all your other motivations are good ones - open-source, well supported language etc. As an example, Facilita have developed their commercial tool's gui with Python. I'd encourage choosing the language carefully, however. It should be = based on the best one for the task. If Python is the language then great! But = it shouldn't be based on familiarity... So, what are the needs (IMHO)?=20 * Open source=20 * Popular (to encourage more developers to get involved) * Cross-platform support (for obvious future motivations) * Flexibility (i.e. Object Oriented, facilitating 'strangling' the = existing code (see http://www.martinfowler.com/bliki/StranglerApplication.html)=20 * Longevity of the language and community support * Availability of libraries (e.g. CORBA library for test orchestration) * Performance (for future extension of the core) Do we want the core and GUI to be in different languages? Do we care? = Dan considered XML-RPC as a means of providing a GUI with interfacing to the core... so, anyone could then write their own GUI in any language they wanted. So, then XML-RPC / Web services support would become an issue in = the availability of libraries category. Ideally, we'd weight each of the above categories, short-list some = languages (e.g. Python, Java, Ruby, C++) and score them. If that meant it was a language most of us weren't familiar with, we could try to recruit a developer who could act as the language expert on the project. I'd also encourage looking at the Eclipse Test & Performance Tools = Platform Project (TPTP) http://www.eclipse.org/tptp/ as a potential platform = that may reduce some of the development overhead... eclipse is very pluggable = so a lot of the IDE and graphing features would already exist in the = platform. I'd encourage looking at the features we want and start - one by one - implementing enough of the GUI, intermediate layers and Bridges (as in Bridge Design Pattern) for the core to support each feature (i.e. using = an Agile approach). JMHO Antony ___________________________________________ e: ant...@et... t: +44 (0)845 056 8817 m: +44 (0)795 628=A06228 w: www.etest-associates.com b: am.testingReflections.com etest associates (UK) ltd. Kemp House 152-160 City Road London EC1V 2NX ___________________________________________ The contents of this message are intended for the addressees only and = should not be forwarded, copied or distributed in any medium without the = permission of the author. Any statements made in this message are solely the views = of the originator and do not necessarily represent the views of etest associates (UK) limited. etest associates (UK) limited does not accept = legal responsibility for any statements or commitments made in this message. > -----Original Message----- > From: ope...@li... = [mailto:opensta-devel- > bo...@li...] On Behalf Of co...@go... > Sent: 11 June 2006 05:33 > To: ope...@li... > Subject: [OpenSTA-devel] Alternate GUI for OpenSTA? >=20 > I have followed OpenSTA closely for a pretty long time and was = involved in > conversations on this list a few years back about the future = development > of > OpenSTA. We discussed lots of issues and possible future directions. >=20 > Since then, no major shifts have happened and developer involvement = seems > to be > ultra low. >=20 > The GUI in OpenSTA is built using MFC and is showing its age. Its > editing, test > setup, and execution are adequate.. but its monitoring, results = analysis, > and > graphing abilites are far behind what proprietary rivals offer and are > also > very brittle. Furthermore, the fact that its development environment = is > complex and proprietary may drive prospective contributors away. >=20 > However, a strong point of OpenSTA is its fast and scalable load > generating > core. This is accessible in a batch mode via the command line. >=20 > info here: > = http://portal.opensta.org/modules.php?op=3Dmodload&name=3DphpWiki&file=3D= index&p > agename=3DOstaCommandLine >=20 > some related utilities: > http://www.trickytools.com/php/opensta.php >=20 > For results reporting, OpenSTA also logs to csv files that you can > process. So > basically OpenSTA's core can be driven without its existing GUI.. both > execution and results analysis. >=20 > As a proof of concept, I built a Python based framework for OpenSTA > results > analysis. It parses timers, generates time series, runs calculations, = and > graphs results that come out of OpenSTA. >=20 > I would like to post a document showing my results analysis module in > Python. > Would people be interested in seeing it? >=20 > As a next step, a wrapper could be built around the CLI and a new GUI = for > test > execution and management could be developed. Eventually all UI = modules > couldbe > con verted over, while leaving the core of OpenSTA in tact. >=20 > As to why Python.. the goal I have in mind is to create a flexible = open > source > UI written in a dynamic object oriented language that has a lot of > existing > module/library support, can integrate well with a C++ execution core, = and > can > be developed using all Free tools. Another reason is an eye towards > future > cross-platform compatibilty. >=20 > Does anyone have any thoughts about this idea? From what I can tell = it > seems > very feasible. >=20 > -Corey Goldberg >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. >=20 >=20 >=20 > _______________________________________________ > OpenSTA-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensta-devel |
|
From: <co...@go...> - 2006-06-11 05:56:54
|
I have followed OpenSTA closely for a pretty long time and was involved in conversations on this list a few years back about the future development of OpenSTA. We discussed lots of issues and possible future directions. Since then, no major shifts have happened and developer involvement seems to be ultra low. The GUI in OpenSTA is built using MFC and is showing its age. Its editing, test setup, and execution are adequate.. but its monitoring, results analysis, and graphing abilites are far behind what proprietary rivals offer and are also very brittle. Furthermore, the fact that its development environment is complex and proprietary may drive prospective contributors away. However, a strong point of OpenSTA is its fast and scalable load generating core. This is accessible in a batch mode via the command line. info here: http://portal.opensta.org/modules.php?op=modload&name=phpWiki&file=index&pagename=OstaCommandLine some related utilities: http://www.trickytools.com/php/opensta.php For results reporting, OpenSTA also logs to csv files that you can process. So basically OpenSTA's core can be driven without its existing GUI.. both execution and results analysis. As a proof of concept, I built a Python based framework for OpenSTA results analysis. It parses timers, generates time series, runs calculations, and graphs results that come out of OpenSTA. I would like to post a document showing my results analysis module in Python. Would people be interested in seeing it? As a next step, a wrapper could be built around the CLI and a new GUI for test execution and management could be developed. Eventually all UI modules couldbe con verted over, while leaving the core of OpenSTA in tact. As to why Python.. the goal I have in mind is to create a flexible open source UI written in a dynamic object oriented language that has a lot of existing module/library support, can integrate well with a C++ execution core, and can be developed using all Free tools. Another reason is an eye towards future cross-platform compatibilty. Does anyone have any thoughts about this idea? From what I can tell it seems very feasible. -Corey Goldberg ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: SourceForge.net <no...@so...> - 2006-05-30 19:08:23
|
Bugs item #908947, was opened at 2004-03-03 04:19 Message generated for change (Comment added) made by faught You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=908947&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: Accepted Priority: 5 Submitted By: Marc MAZAS (mmazas) Assigned to: Daniel Sutcliffe (dansut) Summary: "Call Subroutine: xxxx" logs stop in Test Audit Log Initial Comment: OpenSTA 1.4.2.34, W2K SP4, IE 6.0 (very long ~10000 lines) Script with numerous Calls to subroutines (every 10/20 lines) In "Test Audit log", "Call Subroutine: <mysub>(line#)" logs start well, but stop ; it seems they stop when my script makes an iteration and goes back from near the end to near the beginning (Goto). ---------------------------------------------------------------------- Comment By: Danny Faught (faught) Date: 2006-05-30 14:08 Message: Logged In: YES user_id=576825 I think that the Call Subroutine log entries are a bit of a nuisance, especially when subroutines are used extensively. I'd like to see this logging removed from the code. Most recently observed in v. 1.4.3.20. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2005-05-09 19:54 Message: Logged In: YES user_id=19748 The "Call Subroutine" logs only occur once for a specific CALL on a particular line for each individual VU. Any flow control (GOTO, DO, CALL SCRIPT, etc.) will illustrate this, as will reusing a script in a TaskGroup by Task or iteration. I'm not sure if the "Call Subroutine" should even be logged once per VU... there is no such log for CALL SCRIPT commands. Some consistancy needs to be brought to this logging situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=908947&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-05-30 16:44:52
|
Bugs item #703393, was opened at 2003-03-13 21:55 Message generated for change (Comment added) made by faught You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=703393&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: Inconvenience Status: Open Resolution: Accepted Priority: 5 Submitted By: Danny Faught (faught) Assigned to: Daniel Sutcliffe (dansut) Summary: Can't get Properties pane when Show Properties button gone Initial Comment: 1. Create a test and open it in the test pane in Commander (I'm using OpenSTA 1.4.1 on Windows 2000). 2. Close the Properties pane. 3. Tear off the toolbar with the Show/Hide Properties button so it's separated from the parent window. 4. Click the X on the toolbar to close. There is now no Properties pane and no button to bring it back. This can be confusing and distressing to the user. The workaround is to close the test and reopen it. The button reappears when I do this. I'm thinking that either the toolbar on the main window should reappear when the floating toolbar is closed, or there shouldn't be a close button on the floating toolbar at all. There may be a similar issue with the Compile/Start/Stop/Kill toolbar. ---------------------------------------------------------------------- >Comment By: Danny Faught (faught) Date: 2006-05-30 11:44 Message: Logged In: YES user_id=576825 I reproduced this with OpenSTA 1.4.3.20 on Windows XP Home SP2. The X widget in the undocked toolbar works fine for me. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2005-05-10 15:28 Message: Logged In: YES user_id=19748 Addititionally to this: sometimes when starting viewing a Test the TestPlugin Configuration tab does not seem to initialize properly and the Properties button and pane don't appear. Changing to any other tab and back to the Configuration tab seems to fix the problem. This only seems to happen occasionally - usually after a reboot. Although the initial problem is really fixed on XP, this whole area should be looked at and the ability for these additional toolbars to be floated removed. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-05-01 12:30 Message: Logged In: YES user_id=19748 On WinXP the X button in the undocked props toolbar does not work (shouldn't be there?). Double clicking on header returns bar to being docked. This needs checking on other versions of Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=703393&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-05-03 14:43:47
|
Bugs item #696350, was opened at 2003-03-02 23:18 Message generated for change (Comment added) made by faught You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=696350&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: None Priority: 5 Submitted By: Ranjit Shewale (jcrvs) Assigned to: Daniel Sutcliffe (dansut) Summary: OpenSTA limit of 1664 vusers/users ? Initial Comment: OpenSTA does not display and message when it reaches the user/vuser limit of 1664. As the test continues the vusers go on loading to a limit of 1664 and donot increase beyond that for the http or web scripts. This is observed on platform as Windows NT Server 4.0 with SP6. The marked observations (reported by perfmon) as the 1664 user limit are as follows:- 1. Handle count for the TExecutor_htp.exe - it rises gradually as the test starts till it reaches the saturation point and then remains stable (drops to 0 when the test stops). Now the saturation point corresponds to the point where cpu utilization starts increasing and later reaches 100%. 2. Context switches of system are high in the region where the cpu utilization is 100%. 3. Exception dispatches per sec are high in the region where the cpu utilization is 100%. 4. File Control Operations/sec are high in the region where the cpu utilization is 100% (My conculsion: This makes me conclude that the NT machine 'handle limit' is probably around 3734 or so and when opensta requests more handles to the system the system starts returning exceptions, hence the exceptions observed are high here as mentioned in point 3 above The NT help for 'File Control Operations/sec' says 'operations usually include file system control requests or requests for information about device characteristics or status'. This could alos be one of the reasons for the problem. Something like opensta is internally making calls to get the status of cretain threads etc and results into pushing the server queue to higher value. This in turn increases the context switches amongst threads) For other non-http scripts with huge delays as 10 minutes or so, the OpenSTA is able to exceedd the user limit of 1664. There is no documentation that mentions the above 1664 vuser limit/bug. The perfmon file is attached for reference. Unzip the file and open it using the NT4.0 perfom tool. ---------------------------------------------------------------------- Comment By: Danny Faught (faught) Date: 2006-05-03 09:43 Message: Logged In: YES user_id=576825 I'm copying this from bug 1480597 at Dan's request: I'm seeing an easily reproducible crash with OpenSTA 1.4.3.20 on Windows XP Pro SP2. 1. In the Commander, create a test and add a task group with any test script. I reproduced the crash using a variety of scripts, including a skeleton script no with executable statements at all. 2. Click the cell in the Start column and choose a method for stopping the task group. The crash is reproducible with any of the options - Manually, After fixed time, and On Completion. 3. Set the number of virtual users for the task group to 1666 or more. 4. Run the test. When it completes, I get the error "TExecuter_HTP.exe has encountered a problem and needs to close." Sometimes the error repeats when I dismiss the error dialog, for a total of 6 times. The Commander seems to still be running fine, though I'm not sure if the results are recorded correctly. The Test Error Log shows an error for the location "TestExecuter" - "General exception while running the thread pool." This error also appears when I run with 1665 virtual users, though I don't reproduce the crash in that case. The workaround seems to be to not try to use more virtual users than OpenSTA can handle (as per bug #696350). ---------------------------------------------------------------------- Comment By: Danny Faught (faught) Date: 2006-05-02 13:31 Message: Logged In: YES user_id=576825 Bug 1480597 is related to this one, but the result in that case is a crash. ---------------------------------------------------------------------- Comment By: thefuzzball (thefuzzball) Date: 2005-11-15 15:19 Message: Logged In: YES user_id=1379239 Using opensta 1.4.3.20 ---------------------------------------------------------------------- Comment By: thefuzzball (thefuzzball) Date: 2005-11-15 15:16 Message: Logged In: YES user_id=1379239 Replicated this on Windows Server 2003 standard edition. Dual 3.2 GHZ Xeon w/ 2G ram CPU load hovered around 97% avg. for both processors. It crashed the box within seconds after the 1664 users were met. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-04-29 21:05 Message: Logged In: YES user_id=19748 More info can be added and read at: http://portal.opensta.org/faq.php?topic=BugsMaxVu ---------------------------------------------------------------------- Comment By: Ranjit Shewale (jcrvs) Date: 2003-03-02 23:22 Message: Logged In: YES user_id=721091 Sorry forgot to attach the file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=696350&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-05-02 18:48:40
|
Bugs item #1480597, was opened at 2006-05-02 14:29 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1480597&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: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Danny Faught (faught) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in TExecuter_HTP with VUs >= 1666 Initial Comment: I'm seeing an easily reproducible crash with OpenSTA 1.4.3.20 on Windows XP Pro SP2. 1. In the Commander, create a test and add a task group with any test script. I reproduced the crash using a variety of scripts, including a skeleton script no with executable statements at all. 2. Click the cell in the Start column and choose a method for stopping the task group. The crash is reproducible with any of the options - Manually, After fixed time, and On Completion. 3. Set the number of virtual users for the task group to 1666 or more. 4. Run the test. When it completes, I get the error "TExecuter_HTP.exe has encountered a problem and needs to close." Sometimes the error repeats when I dismiss the error dialog, for a total of 6 times. The Commander seems to still be running fine, though I'm not sure if the results are recorded correctly. The Test Error Log shows an error for the location "TestExecuter" - "General exception while running the thread pool." This error also appears when I run with 1665 virtual users, though I don't reproduce the crash in that case. The workaround seems to be to not try to use more virtual users than OpenSTA can handle (as per bug #696350). ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2006-05-02 14:48 Message: Logged In: YES user_id=19748 Please add this crash information to the 696350 bug report - we have no need for multiple bug entries for obviously closely related problems. This one will be deleted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1480597&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-05-02 18:31:12
|
Bugs item #696350, was opened at 2003-03-02 23:18 Message generated for change (Comment added) made by faught You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=696350&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: None Priority: 5 Submitted By: Ranjit Shewale (jcrvs) Assigned to: Daniel Sutcliffe (dansut) Summary: OpenSTA limit of 1664 vusers/users ? Initial Comment: OpenSTA does not display and message when it reaches the user/vuser limit of 1664. As the test continues the vusers go on loading to a limit of 1664 and donot increase beyond that for the http or web scripts. This is observed on platform as Windows NT Server 4.0 with SP6. The marked observations (reported by perfmon) as the 1664 user limit are as follows:- 1. Handle count for the TExecutor_htp.exe - it rises gradually as the test starts till it reaches the saturation point and then remains stable (drops to 0 when the test stops). Now the saturation point corresponds to the point where cpu utilization starts increasing and later reaches 100%. 2. Context switches of system are high in the region where the cpu utilization is 100%. 3. Exception dispatches per sec are high in the region where the cpu utilization is 100%. 4. File Control Operations/sec are high in the region where the cpu utilization is 100% (My conculsion: This makes me conclude that the NT machine 'handle limit' is probably around 3734 or so and when opensta requests more handles to the system the system starts returning exceptions, hence the exceptions observed are high here as mentioned in point 3 above The NT help for 'File Control Operations/sec' says 'operations usually include file system control requests or requests for information about device characteristics or status'. This could alos be one of the reasons for the problem. Something like opensta is internally making calls to get the status of cretain threads etc and results into pushing the server queue to higher value. This in turn increases the context switches amongst threads) For other non-http scripts with huge delays as 10 minutes or so, the OpenSTA is able to exceedd the user limit of 1664. There is no documentation that mentions the above 1664 vuser limit/bug. The perfmon file is attached for reference. Unzip the file and open it using the NT4.0 perfom tool. ---------------------------------------------------------------------- Comment By: Danny Faught (faught) Date: 2006-05-02 13:31 Message: Logged In: YES user_id=576825 Bug 1480597 is related to this one, but the result in that case is a crash. ---------------------------------------------------------------------- Comment By: thefuzzball (thefuzzball) Date: 2005-11-15 15:19 Message: Logged In: YES user_id=1379239 Using opensta 1.4.3.20 ---------------------------------------------------------------------- Comment By: thefuzzball (thefuzzball) Date: 2005-11-15 15:16 Message: Logged In: YES user_id=1379239 Replicated this on Windows Server 2003 standard edition. Dual 3.2 GHZ Xeon w/ 2G ram CPU load hovered around 97% avg. for both processors. It crashed the box within seconds after the 1664 users were met. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-04-29 21:05 Message: Logged In: YES user_id=19748 More info can be added and read at: http://portal.opensta.org/faq.php?topic=BugsMaxVu ---------------------------------------------------------------------- Comment By: Ranjit Shewale (jcrvs) Date: 2003-03-02 23:22 Message: Logged In: YES user_id=721091 Sorry forgot to attach the file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=696350&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-05-02 18:29:42
|
Bugs item #1480597, was opened at 2006-05-02 13:29 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=1480597&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: Danny Faught (faught) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in TExecuter_HTP with VUs >= 1666 Initial Comment: I'm seeing an easily reproducible crash with OpenSTA 1.4.3.20 on Windows XP Pro SP2. 1. In the Commander, create a test and add a task group with any test script. I reproduced the crash using a variety of scripts, including a skeleton script no with executable statements at all. 2. Click the cell in the Start column and choose a method for stopping the task group. The crash is reproducible with any of the options - Manually, After fixed time, and On Completion. 3. Set the number of virtual users for the task group to 1666 or more. 4. Run the test. When it completes, I get the error "TExecuter_HTP.exe has encountered a problem and needs to close." Sometimes the error repeats when I dismiss the error dialog, for a total of 6 times. The Commander seems to still be running fine, though I'm not sure if the results are recorded correctly. The Test Error Log shows an error for the location "TestExecuter" - "General exception while running the thread pool." This error also appears when I run with 1665 virtual users, though I don't reproduce the crash in that case. The workaround seems to be to not try to use more virtual users than OpenSTA can handle (as per bug #696350). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1480597&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-05-01 22:54:24
|
Bugs item #1199460, was opened at 2005-05-10 17:52 Message generated for change (Comment added) made by faught You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&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: Behavioral Status: Open Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Updating FVR from Modeler doesn't work Initial Comment: The symptom here is that when you intitally create an file variable file (FVR) it is editable and saves correctly, but thereafter it appears to revert to its original contents sometime after you try to update it. Here's what happens: When you open a script in the Commander for the Modeler to edit, a temp dir is created in Repository\.TMP\ called CYR???.tmp\ . Into this dir are copied; the scripts .ALL file from Repository\Captures\ , the actual SCL script (.HTP) from Repository\Scripts\ and any referenced .FVR files from Repository\Data\ . While you are editing your script, if you compile and/or run it then this temp copy is updated. When you run the script from the Modeler it uses the files in this temp dir - except the .FVR files which are used from the Repository\Data\ directory. Any edits you perform to the .FVR using the GUI are also performed on the copies in Repository\Data\ . So if you edit an FVR then run your script you won't see an issue... Here's the crunch though - when you save your SCL script in the Modeler the files from the Repository\.TMP\CYR???.tmp\ are copied into their normal places in the Repository! And yes, this includes the .FVR files that have been saved from when you first opened the script... :-) I guess that GUI editing and running were supposed action on the Repository\.TMP\CYR???.tmp\ copies of the .FVRs. The fix could make this happen, or simply get rid of the .FVRs in this temp dir... I'd like to hear opinions on which of these is preferable from the user point of view? Workarounds: - edit .FVRs by hand with Modeler closed - delete .FVRs in Repository\.TMP\CYR???.tmp\ after starting Modeler ---------------------------------------------------------------------- Comment By: Danny Faught (faught) Date: 2006-05-01 17:54 Message: Logged In: YES user_id=576825 I'm reproducing similar problem2 with OpenSTA 1.4.3.20 on Windows XP Home SP2, but the workarounds mentioned here aren't helping much. Usually I simply attempt to edit the .FVR files using the vim editor, independent of the Modeler. Shutting down Commander and the Modeler and deleting files under .TMP is not sufficient to get the Commander to find the new data. The Modeler seems to be much quicker at finding the updated data. The best workaround I've found is to shut down the NameServer and restart it. I can't find any place in .TMP or anywhere else on the disk where the old contents of the file are cached, so I think it's the NameServer that's keeping the old data in my case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-04-28 23:02:46
|
Bugs item #1013510, was opened at 2004-08-21 14:44 Message generated for change (Comment added) made by faught You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1013510&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Results Analysis Group: Fatal Error Status: Open Resolution: Accepted Priority: 6 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Blank graphs or TestPlugin errors from bad results analysis Initial Comment: A large result set from a test may cause issues when trying to view graphs (the results analysis phase). When this happens the results graphs are empty or an "Out of memory" can be shown. This issue seems to occur more with the graphs that are "v Elapsed Time" but not exclusively so. All reports have been with large result sets. The issues also may not occur the first time you view your results but once it has happened it will not go away on its own. Deleting the HttpStats.cache and Combined_HTTPDataFile.dat will cause your results to be analysed again and may help avoid the problem in your specific instance. This problem seems to happen more if your test did not finish cleanly, either through another problem or through user aborting during the run. Monitoring results whilst the test is running also seems to increase the chance of this happening. A sure sign that you have a problem is the TestPlugin process using up large amounts of memory or CPU. If an "Out of memory" condition is reported it will come from this TestPlugin process. Please add any more useful information to this bug report. We are specifically interested in a simple consistent way of reproducing this error and/or small resultsets which are known to cause the error. ---------------------------------------------------------------------- Comment By: Danny Faught (faught) Date: 2006-04-28 18:02 Message: Logged In: YES user_id=576825 I can easily reproduce this error in v. 1.4.3.20 by corrupting the contents of HttpStats.cache. 1. I captured a single web page hit, and built a test with the resulting script and a cpu utilization collector for the local host. 2. I ran the test. 3. In the results directory, I chopped the last byte off of the HttpStats.cache file. It doesn't matter if the Commander is running when I do this. 4. In the Results tab for the test, as soon as I try to expand the tree for the test run, I get a non-fatal "Out of memory" error dialog from TestPlugin. I don't know if it's actually out of memory - the error is coming very quickly, so it may be just a wild integer value asking for an unreasonably large single block of memory. Whether the HttpStats.cache file is really getting corrupted by something is another matter, but this proves that the tool is not robust against unexpected contents in the test results. I also have a reproducible crash that seems related to this where I didn't intentionally corrupt the HttpStats.cache file. I've had three different real-world test runs that produced results directories that give me a fatal crash every time I try to expand the results in the tree. Removing HttpStats.cache fixes the problem. I can try to scrub the file sufficiently for my client to allow me to send it in if that would help. ---------------------------------------------------------------------- Comment By: chris mead (chrisrmead) Date: 2005-08-25 11:29 Message: Logged In: YES user_id=1335128 For me, there is no clear correlation between large result sets and the crash. I get the crash repeatedly with a test that only has 1060 rows in the Data List, but I get no crash with a test that has 50,856 rows, for instance. I have a ZIP to attach, but I don't see how to do it yet, maybe a comment is required first? ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2005-06-09 10:51 Message: Logged In: YES user_id=19748 From deleted bug#1216593 by javier_dba: Out of memory error appears while trying to show "HTTP Responses v Elapsed time". Test was done successfully ramping 400 vusers along 1 hour. Attached a zip file ResultsAnalysisCrash.zip containing: - picture with the error. - test file - script file - output from dir command of Repository folder - zipped Scripts folder from Repository - zipped ObjectCode folder from Repository - zipped ArchMgr folder from Repository - zipped Profiles folder from Repository Ten computers generating load, sharing the repository, one commanding the load. Used OpenSTA 1.4.2 and 1.4.3. Both versions have the same behaviour "out of memory". ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-12-13 06:48 Message: Logged In: YES user_id=19748 The results analysis phase has multiple problems - especially when dealing with large result sets. Instead of filing multiple bug reports please add any useful and concrete information here that may help us get to the bottom of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1013510&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-04-27 15:51:12
|
Bugs item #809451, was opened at 2003-09-19 14:23 Message generated for change (Comment added) made by faught You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=809451&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: Cosmetic Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Nobody/Anonymous (nobody) Summary: Unhelpful InjectorStatus error messages Initial Comment: Sometimes when a test comes to an end you will find some InjectorStatus errors in the error log. These are usually of the form: XXXXXXXXX,TEST,InjectorStatus,HTTPInjectorStatusImpl::HTTP_GetBothStatsSnapshot: Exception getting both snapshots from TG Executer 'XXX_XXX_XXX_XXX_0000XXXX'; Could be TG stopped or completed, XXXXXXXXX,TEST,InjectorStatus,InjectorStatusImpl::GetInjectorTotalAndActiveVUs: Exception getting VU count from TG Executer 'XXX_XXX_XXX_XXX_0000XXXX'; Could be TG stopped or completed, If these occur at the end of your test they can safely be ignored and should not be logged as errors if at all. If you find them occurring during your test and/or being a symptom of any other issues with your test then please post full details to the users list: http://lists.sf.net/lists/listinfo/opensta-users This currently happens on all OSs when running multi VU tests under OpenSTA 1.4.2 and earlier. ---------------------------------------------------------------------- Comment By: Danny Faught (faught) Date: 2006-04-27 10:51 Message: Logged In: YES user_id=576825 I am reproducing this with OpenSTA 1.4.3.20. HTTPInjectorStatusImpl::HTTP_GetBothStatsSnapshot: Exception getting both snapshots from TG Executer '10_1_3_112_000005E8'; Could be TG stopped or completed I get the error at the end of the run even when running just one virtual user, as long as at least one test script and one collector is enabled. ---------------------------------------------------------------------- Comment By: Kevin McLoughlin (kmcloughlin) Date: 2004-07-15 11:23 Message: Logged In: YES user_id=181891 Yep, thats cos when i wrote it the IS has no way of knowing that the test has finished. So you are correct that if it happens at the end of the test then you can ignore it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=809451&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-04-14 23:01:53
|
Bugs item #1199448, was opened at 2005-05-10 18:35 Message generated for change (Comment added) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199448&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: Behavioral Status: Open Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) >Summary: Result Graphs scaled wrong so some parts are unviewable Initial Comment: If you've changed the default Windows DPI setting (96dpi) then the Result graphs will be generated scaled wrong to fit in the window. If the DPI value has been made larger then the graph may actually be bigger than the window and no scroll bars will be provided, meaning you won't be able to see the top right corner of the graph. Normally the scaling of the graph follows the window size so the graph always exactly fits in the Window. Workaround: change DPI setting back to 96dpi, or export data and generate graphs yourself in spreadsheet software. ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2006-04-14 19:01 Message: Logged In: YES user_id=19748 Also: even without changing the Windows DPI, graphs that can contain mutlple colored plots occasionally 'lose' their keys off the bottom of the viewable area. When this happens you can't see what color line represents what plot - in some graphs you can work out what is what using right-click>filter in the graph, or for some plots maximising the graph may let you see the key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199448&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-04-13 18:25:51
|
Bugs item #1468855, was opened at 2006-04-11 14:06 Message generated for change (Comment added) made by jarrowwx 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' affected by subroutine order 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. ---------------------------------------------------------------------- >Comment By: John Arrowwood (jarrowwx) Date: 2006-04-13 11:25 Message: Logged In: YES user_id=1500024 The following demonstrates the problem: ----- BEGIN ----- Environment description "" mode http wait unit milliseconds Definitions CHARACTER*255 server CHARACTER*255 path CHARACTER*65535 headers CHARACTER*65535 body_text Code SET server = 'www.google.com' CALL Get [ '/' ] SUBROUTINE DebugRequest LOAD Response_Info Header ON 1 INTO headers LOAD Response_Info Body ON 1 INTO body_text LOG headers LOG body_text END SUBROUTINE SUBROUTINE Get [ path ] PRIMARY GET URI "http://"+server+path+" HTTP/1.0" ON 1 & HEADER "Host: "+server & ,WITH { "User-Agent: testing" } CALL DebugRequest END SUBROUTINE ----- END ----- The following DOES NOT demonstrate the problem. Notice how subtle the difference? ----- BEGIN ----- Environment description "" mode http wait unit milliseconds Definitions CHARACTER*255 server CHARACTER*255 path CHARACTER*65535 headers CHARACTER*65535 body_text Code SET server = 'www.google.com' CALL Get [ '/' ] SUBROUTINE Get [ path ] PRIMARY GET URI "http://"+server+path+" HTTP/1.0" ON 1 & HEADER "Host: "+server & ,WITH { "User-Agent: testing" } CALL DebugRequest END SUBROUTINE SUBROUTINE DebugRequest LOAD Response_Info Header ON 1 INTO headers LOAD Response_Info Body ON 1 INTO body_text LOG headers LOG body_text END SUBROUTINE ----- END ----- The only difference is subroutine declaration order! This ought to give the developers a great way to narrow down what is going on. And it may well be that fixing this will fix some other subtle and hard to reproduce bugs, as well. ---------------------------------------------------------------------- Comment By: John Arrowwood (jarrowwx) Date: 2006-04-13 10:55 Message: Logged In: YES user_id=1500024 Sample code that reproduces the issue, that can be used to debug the problem: Environment description "" mode http wait unit milliseconds Definitions ! HTTP Global Variables INTEGER connection_id CHARACTER*255 server CHARACTER*255 path CHARACTER*255 referrer CHARACTER*65535 headers CHARACTER*1024 cookie_temp CHARACTER*1024 cookie_contents CHARACTER*1024 redirect CHARACTER*65535 body_text INTEGER body_length_int CHARACTER*5 body_length_char INTEGER DEBUG CONSTANT USER_AGENT = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" Code SET DEBUG = 1 SET server = 'www.google.com' CALL Get [ '/' ] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE NextConnection IF ( connection_id > 0 ) THEN DISCONNECT FROM connection_id ENDIF SET connection_id = connection_id + 1 END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE CheckPath IF ( path <> redirect ) THEN IF ( redirect <> "" ) THEN LOG "Requesting: ", path LOG "Expecting: ", redirect ENDIF ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE DebugRequest IF ( DEBUG = 1 ) THEN LOAD Response_Info Header ON connection_id INTO headers LOAD Response_Info Body ON connection_id INTO body_text LOG headers LOG body_text ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE UpdateCookie LOAD Response_Info Header ON connection_id INTO cookie_temp, WITH "Set-Cookie,PHPSESSID" IF ( cookie_temp <> "" ) THEN SET cookie_contents = cookie_temp ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE CheckRedirect LOAD Response_Info Header ON connection_id INTO redirect, WITH "Location" IF ( redirect = "/system_errors/please_login.php" ) THEN LOG "!!!!! Oops !!!!!" EXIT ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE Post [ path, body_text ] CALL CheckPath CALL NextConnection SET body_length_int = ~LENGTH( body_text ) CONVERT body_length_int TO body_length_char LOG body_length_char LOG body_text PRIMARY POST URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " & "application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, " & "application/x-shockwave-flash, */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Content-Type: application/x-www-form-urlencoded", & "Connection: Keep-Alive", & "Content-Length: " + body_length_char, & "Pragma: no-cache", & "Cookie: "+cookie_contents & } & ,BODY body_text CALL DebugRequest CALL CheckRedirect SET referrer = path END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE Get [ path ] CALL CheckPath CALL NextConnection PRIMARY GET URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " & "application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, " & "application/x-shockwave-flash, */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Connection: Keep-Alive", & "Pragma: no-cache", & "Cookie: "+cookie_contents & } CALL DebugRequest CALL CheckRedirect SET referrer = path END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE RefersTo [ path ] CALL NextConnection GET URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Connection: Keep-Alive", & "Cookie: "+cookie_contents & } END SUBROUTINE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1468855&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-04-13 17:55:04
|
Bugs item #1468855, was opened at 2006-04-11 14:06 Message generated for change (Comment added) made by jarrowwx 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. ---------------------------------------------------------------------- >Comment By: John Arrowwood (jarrowwx) Date: 2006-04-13 10:55 Message: Logged In: YES user_id=1500024 Sample code that reproduces the issue, that can be used to debug the problem: Environment description "" mode http wait unit milliseconds Definitions ! HTTP Global Variables INTEGER connection_id CHARACTER*255 server CHARACTER*255 path CHARACTER*255 referrer CHARACTER*65535 headers CHARACTER*1024 cookie_temp CHARACTER*1024 cookie_contents CHARACTER*1024 redirect CHARACTER*65535 body_text INTEGER body_length_int CHARACTER*5 body_length_char INTEGER DEBUG CONSTANT USER_AGENT = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" Code SET DEBUG = 1 SET server = 'www.google.com' CALL Get [ '/' ] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE NextConnection IF ( connection_id > 0 ) THEN DISCONNECT FROM connection_id ENDIF SET connection_id = connection_id + 1 END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE CheckPath IF ( path <> redirect ) THEN IF ( redirect <> "" ) THEN LOG "Requesting: ", path LOG "Expecting: ", redirect ENDIF ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE DebugRequest IF ( DEBUG = 1 ) THEN LOAD Response_Info Header ON connection_id INTO headers LOAD Response_Info Body ON connection_id INTO body_text LOG headers LOG body_text ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE UpdateCookie LOAD Response_Info Header ON connection_id INTO cookie_temp, WITH "Set-Cookie,PHPSESSID" IF ( cookie_temp <> "" ) THEN SET cookie_contents = cookie_temp ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE CheckRedirect LOAD Response_Info Header ON connection_id INTO redirect, WITH "Location" IF ( redirect = "/system_errors/please_login.php" ) THEN LOG "!!!!! Oops !!!!!" EXIT ENDIF END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE Post [ path, body_text ] CALL CheckPath CALL NextConnection SET body_length_int = ~LENGTH( body_text ) CONVERT body_length_int TO body_length_char LOG body_length_char LOG body_text PRIMARY POST URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " & "application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, " & "application/x-shockwave-flash, */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Content-Type: application/x-www-form-urlencoded", & "Connection: Keep-Alive", & "Content-Length: " + body_length_char, & "Pragma: no-cache", & "Cookie: "+cookie_contents & } & ,BODY body_text CALL DebugRequest CALL CheckRedirect SET referrer = path END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE Get [ path ] CALL CheckPath CALL NextConnection PRIMARY GET URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " & "application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, " & "application/x-shockwave-flash, */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Connection: Keep-Alive", & "Pragma: no-cache", & "Cookie: "+cookie_contents & } CALL DebugRequest CALL CheckRedirect SET referrer = path END SUBROUTINE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SUBROUTINE RefersTo [ path ] CALL NextConnection GET URI "http://"+server+path+" HTTP/1.0" ON connection_id & HEADER "Host: "+server & ,WITH { & "User-Agent: "+USER_AGENT, & "Accept: */*", & "Referer: http://"+server+referrer, & "Accept-Language: en-us", & "Connection: Keep-Alive", & "Cookie: "+cookie_contents & } END SUBROUTINE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1468855&group_id=10857 |
32 messages has been excluded from this view by a project administrator.
