If you look at the app-server status, can you see both queries running at the same time?
You might try replacing the update task with one that just sleeps and updates progress. Something like: for $i in 1 to 2000 let $_ := progress-update($i) return xdmp:sleep(500) The progress-update function would set the server field state. That should eliminate everything that might block, except for the server-fields calls themselves. -- Mike On 18 Dec 2012, at 14:03 , Steve Carton <[email protected]> wrote: > Hi Mike, > > Well, I'm puzzled by it too. The approach you describe below is exactly what > I am doing - the browser launches the long-running query as an async ajax > request and then polls using subsequent async requests. The only ideas I've > come up with so far are that maybe, since the long-running query is updating, > it is somehow blocking the subsequent queries. Which is why I tried wrapping > those portions in an eval. But it doesn't seem to matter. > > I don't think the longer query is blocking on the server fields, unless maybe > the query analyzer figures that out in advance (as it does for updates). I > also make async calls for other info and those are blocked too. > > Steve > > > > > > On 12/18/2012 4:53 PM, Michael Blakeley wrote: >> You're right that server-fields are server-specific, so the Task Server >> can't see other app-server fields. You could take advantage of that: put the >> real work for both queries on the task server so they can both see the same >> server fields. But the ajax request will need to see the result of the task, >> so use the 'result' option to xdmp:spawn to get that. Oddly that option is >> documented at http://docs.marklogic.com/xdmp:eval - but >> http://docs.marklogic.com/xdmp:spawn#spawnresultex >> shows an example. >> >> I think that's probably the right approach, because it allows you to further >> break up the long-running update into multiple tasks. But I'm puzzled by >> your description of blocking. The way I would structure this would be to >> load a page that doesn't really do anything itself. Once loaded it fires off >> an async HTTP request to start the long-running update task. Then it sits >> back and polls the progress query with more async requests. Given that >> setup, I can't see why they would block each other. Last I heard, >> server-fields don't take locks. >> >> -- Mike >> >> On 18 Dec 2012, at 13:33 , Steve Carton >> <[email protected]> >> wrote: >> >> >>> I have a query that works through many documents looking for certain >>> elements/values (basically, cross references to other documents). It first >>> creates a new document for logging results. For each cross-reference found, >>> the query updates the log document by adding a new element as a child. It >>> also increments a counter in a server field. The query can run for a while >>> - there is a lot of content to go through, and it is a web application, so >>> I'd like to let the user know how the query is coming along. So a separate >>> query is initiated as an Ajax request that should return the contents of >>> the server-field. Some javscript on the browser uses the response from that >>> second query to update a progress bar in the browser. >>> >>> The problem is, the second query (the Ajax request for the contents of the >>> server field) won't start until the first query (the main one) is finished. >>> I've fooled with any number of techniques, including wrapping the inner >>> portions of the first query inside xdmp:eval wrappers to isolate the update >>> transactions and also spawning the query. Neither works (well, not quite >>> accurate - the spawn allows the second ajax query to run, but it doesn't >>> access the server-field, under spawn, the query seems to have its own >>> server fields?). >>> >>> Any suggestions? What am I missing here. >>> >>> -- >>> Steve >>> _______________________________________________ >>> General mailing list >>> >>> [email protected] >>> http://developer.marklogic.com/mailman/listinfo/general >> _______________________________________________ >> General mailing list >> >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> >> >> >> >> > > -- > Steve > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
