[OpenSTA-devel] [ opensta-Bugs-1468855 ] 'LOAD RESPONSE_INFO' fails if performed in a different scop
Brought to you by:
dansut
|
From: SourceForge.net <no...@so...> - 2006-04-11 21:06:35
|
Bugs item #1468855, was opened at 2006-04-11 14:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1468855&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Arrowwood (jarrowwx) Assigned to: Nobody/Anonymous (nobody) Summary: 'LOAD RESPONSE_INFO' fails if performed in a different scope Initial Comment: This is similar to issues 433574 and 645735, and in fact is explicitly mentioned in 433574, but is being lost in the confusion because there are multiple bugs being reported at once. So, to try and help this issue get some attention, here it is in a separate bug. Regardless of whether you use PRIMARY GET URI or GET URI or PRIMARY POST URI, the following applies: If you perform the HTTP request in a subroutine, and then try to LOAD Response_Info after the subroutine finishes, or if you attempt to call a subroutine in order to perform the LOAD, either way, it errors with the familiar: HTTPRESPONSE: No data available for connection id(1) TScript::run: ERROR in TOF execution; resuming... This appears to be an issue whether the connection ID is a constant, an integer variable, or an expression. This is why I chose to raise a separate bug, since the other two seem to be focused on the use of a variable for the connection id. The use of SYNCHRONIZE REQUESTS seems to be of no value, whether performed in the calling subroutine, or the called subroutine. The wrapping of the call in an IF block also likewise does not help. It would seem to be a scope issue. It seems like once the scope of execution changes, the connection id is no longer valid. Here's hoping that helps narrow down the source of the problem. And if this could be fixed, it would enable scripts to be much better organized and maintainable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1468855&group_id=10857 |