Hi, Eliot and Ron:

The return option is explained with the rest of the options in the eval article:

    http://docs.marklogic.com/xdmp:eval

The second example under spawn uses the promise:

    http://docs.marklogic.com/xdmp:spawn

As Ron notes, the server field is only useful if the polling requests go back 
to the same host.

To allow for restarts, the polling logic should check for the persisted final 
status document if the server field is empty.  (That's the motivation for 
persisting a final status document even when using server fields.)

Thanks for the feedback on the documentation -- I'll pass that along.


Erik Hennum

________________________________
From: [email protected] 
[[email protected]] on behalf of Ron Hitchens 
[[email protected]]
Sent: Monday, August 14, 2017 7:55 AM
To: MarkLogic Developer Discussion
Subject: Re: [MarkLogic Dev General] Tracking Spawned Tasks?


   Proceed with caution when using server fields.  They exist only on a single 
machine, they are not propagated across nodes in a cluster.  If you have a 
cluster behind a load balancer (as most are) and you stash something in a 
server field to be checked later, the next request may be vectored to a 
different cluster node, where your stashed value will not be present.  
Likewise, if you put something in a field to be picked up by a spawned task, 
the spawned task may run on a different node.

----
Ron Hitchens [email protected]<mailto:[email protected]>, +44 7879 358212



On August 14, 2017 at 3:24:32 PM, Eliot Kimber 
([email protected]<mailto:[email protected]>) wrote:

I like using set-server-field: my requirement feels like just what server 
fields were intended for.

Cheers,

E.
--
Eliot Kimber
http://contrext.com



On 8/14/17, 8:32 AM, 
"[email protected]<mailto:[email protected]>
 on behalf of Erik Hennum" 
<[email protected]<mailto:[email protected]>
 on behalf of [email protected]<mailto:[email protected]>> 
wrote:

Hi, Eliot:

xdmp:spawn() doesn't return an identifier because, if it is used as a future 
via the result option, it is obligated to return the result.

The approach you sketch below -- passing in an identifier and writing tickets 
to a status database -- is pretty much what InfoStudio did.

One refinement would be to log status in a server field via 
xdmp:set-server-field() and, on completion, write final status to a database 
(for durability in the case of a restart).


Hoping that helps,


Erik Hennum

________________________________________
From: 
[email protected]<mailto:[email protected]>
 
[[email protected]<mailto:[email protected]>]
 on behalf of Eliot Kimber [[email protected]<mailto:[email protected]>]
Sent: Saturday, August 12, 2017 10:15 AM
To: MarkLogic Developer Discussion
Subject: [MarkLogic Dev General] Tracking Spawned Tasks?

Using ML 8

I’m refining a profiling application that spawns a number of tasks and then, 
eventually, reports on the results once all the tasks have completed.

Right now I just fire off the tasks and then refresh my app, which looks for 
results.

It would be nice to be able to show the status of the spawned tasks but it 
looks like xdmp:spawn() doesn’t return anything (sort of expected to get some 
sort of task ID or something) and so there’s no obvious way to track spawned 
tasks from the spawning application.

I could do something like generate private task IDs and pass those as 
parameters to the spawned tasks and then maintain a set of task status docs, 
but I was hoping there was some something easier.

It seems like it would be a common requirement but I couldn’t find anything 
useful in the ML 8 docs or searching the web.

Thanks,

Eliot
--
Eliot Kimber
http://contrext.com




_______________________________________________
General mailing list
[email protected]<mailto:[email protected]>
Manage your subscription at:
http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]<mailto:[email protected]>
Manage your subscription at:
http://developer.marklogic.com/mailman/listinfo/general



_______________________________________________
General mailing list
[email protected]<mailto:[email protected]>
Manage your subscription at:
http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
Manage your subscription at: 
http://developer.marklogic.com/mailman/listinfo/general

Reply via email to