In a customer cluster there is a special cluster node dedicated to running tasks,
and another cluster node dedicated node to running admin applications.
In the admin application I want to show the tasks progress from the task running cluster node.
It would be nice if the libTask.list had a parameter to get tasks from all cluster nodes, perhaps similar to how libEvent does:
libTask.list({localOnly: false})
--
I could implement a WORKAROUND like this:
On the admin cluster node send a distributed custom event "A", when an admin application asks for task status.
On the task cluster node setup a custom event listener "A" which would get the local task list,
and send the data as a distributed custom event "B".
On the admin cluster node setup a listener for "B" which would push the result to the client via ws.
Or perhaps just let the client request for task status wait synchronously for the listener before responding back to the client.
We recently closed and opposite issue #6982 as "won't fix".
List of tasks if fetched from entire cluster not just local.
Fill free to document this behavior.
The documentation does not specify, and I do belive lib-task only operates on the current cluster node. https://developer.enonic.com/docs/xp/stable/api/lib-task#list
In a customer cluster there is a special cluster node dedicated to running tasks, and another cluster node dedicated node to running admin applications.
In the admin application I want to show the tasks progress from the task running cluster node.
It would be nice if the libTask.list had a parameter to get tasks from all cluster nodes, perhaps similar to how libEvent does: libTask.list({localOnly: false})
--
I could implement a WORKAROUND like this:
On the admin cluster node send a distributed custom event "A", when an admin application asks for task status.
On the task cluster node setup a custom event listener "A" which would get the local task list, and send the data as a distributed custom event "B".
On the admin cluster node setup a listener for "B" which would push the result to the client via ws. Or perhaps just let the client request for task status wait synchronously for the listener before responding back to the client.