Steve,
When you use waitforresult=false, do you just use an EXIT action right after @URL? You can, and probably should, but all you’ve effectively done is started another instance (request) of the same TAF running, as if you went to another computer and typed in the URL, while the first instance was still running. If you run the taf from a browser, what happens? Does the browser just look like it stopped? If your TAF completes, then yes. The request that was called via @URL with waitforresult=false, will run to its conclusion in the TeraScript server, but it no longer has a client to send the response back to – nothing is listening. It would be the same effect if you browsed to a URL but immediately closed your browser. The request would still run, but the web server will throw the result away since the client connection will be closed. I am also assuming that when running this on a Pro version of TeraScript, using @URL to call the same taf over and over until a condition (based on arguments contained within the url) is met could result in the taf running on multiple instances. The request will be passed into your web server and through the TS client just like any other http request. @URL is not special in that regard. You can always control which TS service your request lands on using the FORCE_SERVER_ARG_NAME mechanism in clients.ini. To answer your question in general, yes, if you were to execute @URL with waitforresult=false at a rate of once per 1/100 of a second, but each request took 1/10 of a second to run, you would very quickly bog down and possibly overload your server. Consider using @SLEEP between each call to create a pause. If you are processing large work load and you want to hold data in memory so that subsequent requests can use it (eg. a large array) you’ll want to use the user scope to hold that data and then be sure to use the @USERREFERENCEARGUMENT in the url so that your new request picks up the same user session and variables. It is not a violation of the TS server to run multiple requests against the same user session simultaneously, but this should only be used to chain requests together (the end of one request starts the next). Don’t try to start multiple requests at the same time unless you build thread-safety into your code. Robert From: Fogelson, Steve [mailto:[email protected]] Sent: Monday, February 27, 2012 6:06 PM To: [email protected] Subject: TeraScript-Talk: FW: Witango-Talk: Re-Directs I have a couple more questions about @URL calling the same taf that is presently running. IE: Running through a large email table and the taf cannot finish within 5 minutes. When you use waitforresults=false, do you just use an EXIT action right after @URL? If you run the taf from a browser, what happens? Does the browser just look like it stopped? I am also assuming that when running this on a Pro version of TeraScript, using @URL to call the same taf over and over until a condition (based on arguments contained within the url) is met could result in the taf running on multiple instances. Thanks Steve Fogelson Internet Commerce Solutions From: Robert Shubert [mailto:[email protected]] Sent: Monday, August 15, 2011 2:28 PM To: [email protected] Subject: RE: Witango-Talk: Re-Directs Steve, Dale’s post is very thorough and you should review it. But I will say that using the <META HTTP-EQUIV="REFRESH" CONTENT="0; URL=<@APPFILE>"> method should avoid the redirect loop catch. Also, you mentioned using this in a cron job, in that case there is no browser so both the 302 Moved and the meta refresh methods won’t work (since both are functions of the browser). In the cron case, instead of refreshing/redirecting to a new request, you must use @URL to call the TAF again and start a new thread. Couple of things: You must be completely done with all variables and work since the new thread will begin before the old thread ends. @URL must be called with waitforresults=false (otherwise you’ll be calling recursively) @URL does not by default pass the user reference cookie. If you need to sustain user scoped variables, you must explicitly add the argument to the URL. Robert From: Fogelson, Steve [mailto:[email protected]] Sent: Monday, August 15, 2011 3:19 PM To: [email protected] Subject: RE: Witango-Talk: Re-Directs HTTP/1.0 302 Moved<@crlf>Location: <@var method$URL encoding=meta><@crlf><@setcookies><@userreferencecookie><@crlf><@crlf> From: Robert Shubert [mailto:[email protected]] Sent: Monday, August 15, 2011 10:37 AM To: [email protected] Subject: RE: Witango-Talk: Re-Directs Steve, It’s true that browsers have limiters to prevent infinite redirect loops. How are you handling the redirect? Which method? Robert From: Fogelson, Steve [mailto:[email protected]] Sent: Sunday, August 14, 2011 10:54 PM To: [email protected] Subject: Witango-Talk: Re-Directs Found something a little odd. I wrote a taf to import data into a db table. Because of the size I have broken it into increments of 500 records at a time and then redirect to the same taf until finished. I am using IE 8.0 and for some reason it fails after 10 redirects. I changed the number of records from 10 to 500 and it always fails after 10 redirects. I couldn’t determine why, so I tried FireFox. It paused after 20 redirects and displayed a message indicating a possible problem with the redirect. Is there a “check” programmed into BROWSERs to prevent runaway re-directs? If so, is there a work around for this. What happens when this is ran as a cron? Thanks Steve Fogelson Internet Commerce Solutions _____ To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body. _____ To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body. _____ To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body. _____ To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body. _____ To unsubscribe from this list, please send an email to [email protected] with "unsubscribe terascript-talk" in the body. ---------------------------------------- To unsubscribe from this list, please send an email to [email protected] with "unsubscribe terascript-talk" in the body.
