Hi Steve,
My guess would be that you are reading the log file in the status query, while it is locked for update in the update query. Could your status query be running in update mode? If you have everything in one xqy, you might want to put it in a separate xqy.. Instead of manipulating a log file at each change, you could write separate log records in some collection as well. Do an xdmp:estimate on the collection and you have your count.. Cheers, Geert *Van:* [email protected] [mailto: [email protected]] *Namens *Steve Carton *Verzonden:* woensdag 19 december 2012 0:37 *Aan:* [email protected] *Onderwerp:* Re: [MarkLogic Dev General] running two queries at the same time Mike, I implemented your test below and it seems to work fine - I can access a similar test xqy that returns the contents of the server field and both run in parallel. So whatever is blocking my queries is something else. I had wondered if the second query is simply not getting a chance to run - that the first one is hogging the cycles. But that seems unlikely. On 12/18/2012 5:25 PM, Michael Blakeley wrote: 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]> <[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]> <[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 -- *Steve*
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
