I am in a military context where a worker will communicate with the temporal server through a satellite connection. This connection being expensive, I have as a requirement the prohibition of polling.
I understand that the worker needs to regularly open a connection to the temporal server to know if he has a message to process on his task queue.
Is it possible to configure this polling so that there is a connection between the worker and the temporal server only every n minutes? Is there another alternative ?
I’m curious about the specifics of your use case.
Are you maintaining some sort of session on the worker that has limited connectivity?
Does that worker need to run the workflow logic or only the activities?
I’m asking because we typically recommend running the workflow logic for session-aware (localized to a specific worker) activities in a global worker pool so the workflow can continue to be responsive in case the specific worker goes offline for any reason.
The use case is as follows : we have a kubernetes cluster (in the cloud) with :
temporal server
temporal worker in a pod which runs workflows.
We have a worker that runs the activities in another kubernetes cluster (on premise).
The worker (on premise) polls the temporal server on a task queue continuously to process the activities triggered by the cloud worker.
Each link between the worker (on premise) and the temporal server opens an expensive satellite link.
The requirement restricts us that the link between the two workers is established only when it is necessary whereas the principle of a temporal worker is to listen continuously on the task queue (and thus to permanently maintain an open link).
I saw that it is possible progammatically in the worker (on premise) to pause the polling but I don’t know if this is the right use case.
I wonder if my use case is compatible with the principle of temporal ?
You can switch from long poll to push by running an activity worker on the cloud that would synchronously call the remote service on-premise. Is on-prem cluster addressible from the cloud?
Polling will always be more expensive as it will consume the expensive link periodically even if there are no tasks to deliver.
In most SDKs the worker doesn’t give you control over the poller, Java allows suspending the worker for some control.
With the Java SDK you can have a routine that wakes up periodically, starts the poller, waits a for a while and suspends again.
What you don’t get though is insight into when the task queue has been drained (e.g. when a poll request times out with no task in the response), you can get that from metrics but it’s a pretty complex workaround.
Another approach would be to use the gRPC API directly to poll for activity tasks on that task queue but you’d have to implement some parts of the worker yourself so that’s also not an ideal solution.