Allow configuration of workers to back off completely if the server is not available
See original GitHub issueIs your feature request related to a problem? Please describe.
I want the workers to stop trying to connecting to the server if the server is not available using WorkflowServiceStubsOptions
Describe the solution you’d like I’d like to configure workers to stop polling/trying to connecting to the server if the server is not available after a specified time period.
Describe alternatives you’ve considered N/A
Additional context Slack discussion https://temporalio.slack.com/archives/CTT84KXK9/p1620663515093300
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Avoiding the Top 10 NGINX Configuration Mistakes
We help you avoid the 10 most common NGINX configuration errors, explaining the problems caused by each and how to fix them.
Read more >Module ngx_http_upstream_module - Nginx.org
Default value is zero, meaning there is no limit. If the server group does not reside in the shared memory, the limitation works...
Read more >Configure the max worker threads Server Configuration Option
Using SQL Server Management Studio Use the max worker threads option to configure the number of worker threads available to SQL Server ...
Read more >Configure the bundled Puma instance of the GitLab package
This error occurs when the Web server times out (default: 60 s) after not hearing back from the Puma worker. If the CPU...
Read more >1.2.5 Running a worker node - Concourse CI
It is possible to have a Concourse cluster made up of only team workers and have zero non-team workers, though this is not...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think we may have both backoff and a parameter that specifies maximum retry period after which we give up and kill the worker. I can see situations where both types of behavior might be desirable based on the specifics of the deployment infrastructure being used.
@eminn Will implement health check. This has already been done in Go SDK see client.go#L417