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]> 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
--
/Steve/
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
