As you have discovered, you must call xdmp:spawn on the host where you want the task to run. In this respect the task server acts like any other app-server: configuration is shared by the entire group, but each instance runs independently.
I agree that it would be handy to have a 'host' option to xdmp:spawn. You could contact support and open an RFE. Meanwhile, one way around this is to build a simple web service that spawns a task. Each task server will still run independently, but that gives you a way to balance new tasks across multiple hosts. You might want to keep your code in a Modules database, so you don't have to worry about keeping it in sync across all your hosts. -- Mike On 15 Aug 2014, at 10:24 , Harry Bakken <[email protected]> wrote: > I am having a hard time finding information about spawning tasks in a > clustered environment. I have a process for ingesting data from a web service > that will queue up service calls in the task server using xdmp:spawn. It > works fine and does what we need, but when we run it in a clustered > environment, only one node ends up with all the work. > > It seems that the node where the xdmp:spawn call was made is the node where > the task server will handle the work. Is there a way to have the nodes in the > cluster work off of one task server queue, or is it node-specific? Is it a > matter of simply queuing up work on each node in order to leveral all nodes > in the cluster? > > Thanks, > Harry > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
