You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 31, 2021. It is now read-only.
Coupled with #43, this would mean that services which are down for "prolonged" periods of time would have their queues removed, resulting in requesters getting immediate feedback that the endpoint they're trying to hit is not available.
There are a few issues with this currently:
Utilising this functionality would, under the current design, mean that the endpoint would have to be transient and the requester would have to have the mandatory setting. That's a lot of assumptions/configuration.
When do we expire the queue? We could do it on a default timeout of 30 seconds, but request timeouts are changeable; should endpoint timeouts be?
A service being down and requests still being queued is a nice feature. Rather than this feature being an additional help, it removes one feature in place of another. Is that good?
The text was updated successfully, but these errors were encountered:
Pretty heavily related to the new #58, though that works on the assumption that endpoints should be "transient" by default. We'll discuss the possibility of a "transient" option as an alternative in #58 instead.
Coupled with #43, this would mean that services which are down for "prolonged" periods of time would have their queues removed, resulting in requesters getting immediate feedback that the endpoint they're trying to hit is not available.
There are a few issues with this currently:
The text was updated successfully, but these errors were encountered: