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 Sep 4, 2024. It is now read-only.
Currently, clients waiting on an existing pending job are counted as workers as far as the concurrency/backlog limits are concerned.
This means that clients that do not really consume any resources (they just poll an already scheduled build), may end up filling our internal backlog limits and cause the server to stop accepting new builds until one of the pending ones complete, even though the number of pending builds might be less than the concurrency limit. This in conjunction with not having a global timeout limit for builds (#4), may result in mistry not accepting new builds while it could (and should).
Clients coalesced with a pending build should not be taken into account when checking the concurrency and backlog configuration settings.
The text was updated successfully, but these errors were encountered:
Currently, clients waiting on an existing pending job are counted as workers as far as the concurrency/backlog limits are concerned.
This means that clients that do not really consume any resources (they just poll an already scheduled build), may end up filling our internal backlog limits and cause the server to stop accepting new builds until one of the pending ones complete, even though the number of pending builds might be less than the concurrency limit. This in conjunction with not having a global timeout limit for builds (#4), may result in mistry not accepting new builds while it could (and should).
Clients coalesced with a pending build should not be taken into account when checking the
concurrency
andbacklog
configuration settings.The text was updated successfully, but these errors were encountered: