You can serialize the last webservice call status into a document to create a sort of locl. For example, keep a document names /last-webservice-call.xml with an element showing the timestamp of the last call and another element showing some id from the caller. Something like:
<doc> <id>123456</id> <ts>output-from-fn:current-timestamp</ts> </doc> Then have your spawned webservice call do two transactions to the document in evals, the first to look at that document and make sure it is at least 1 second old and if so, change the id (so no one else gets it-that could just be a random 64-bit number), and then do the webservice call, then when the web call is done write the new time to it. -Danny From: [email protected] [mailto:[email protected]] On Behalf Of Will Thompson Sent: Monday, March 04, 2013 3:46 PM To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] Throttling webservice calls typo: "Task Scheduler" => "Task Server" From: Will Thompson <[email protected]<mailto:[email protected]>> Reply-To: MarkLogic Discussion <[email protected]<mailto:[email protected]>> Date: Monday, March 4, 2013 3:44 PM To: MarkLogic Discussion <[email protected]<mailto:[email protected]>> Subject: [MarkLogic Dev General] Throttling webservice calls Can anyone recommend a good way to throttle calls to a webservice API that has transaction limits? I.e.: one call per second restrictions to a remote webservice. My first thought was to configure Task Scheduler to handle only one thread. Then whenever someone needs to hit the webservice it spawns something like this (using <result>{fn:true()}</result>): let $response := xdmp:http-get('http://some-webservice') return ($response, xdmp:sleep(seconds-from-duration(xs:dayTimeDuration('PT1S') - xdmp:elapsed-time()) * 1000)) This would keep requests to a maximum 1 per second, but anyone calling it with an empty queue would still have to wait the full second to get their result. Also, if anything else relied on Task Server being able to execute tasks with multiple threads, this would break it. -Will
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
