Avoid increasing source ranking on submission failure #4916
Comments
rcarpa
added a commit
to rcarpa/rucio
that referenced
this issue
Nov 2, 2021
…o#4970 - Don't update source ranking on submission failures: these sources where not yet used by FTS, so there is no reason to decrease their ranking. - Bound sources in multihops to the initial request. Meaning that intermediate hop requests will not have any sources at all. This shouldn't be problematic, because we don't retry intermediate hops. The sources will be attached to the last hop (initial request). This way, if the transfer fails, all the path will be reduced in priority. In particular, the first hop (real source) will have its ranking decreased
joeldierkes
pushed a commit
to joeldierkes/rucio
that referenced
this issue
Nov 15, 2021
…o#4970 - Don't update source ranking on submission failures: these sources where not yet used by FTS, so there is no reason to decrease their ranking. - Bound sources in multihops to the initial request. Meaning that intermediate hop requests will not have any sources at all. This shouldn't be problematic, because we don't retry intermediate hops. The sources will be attached to the last hop (initial request). This way, if the transfer fails, all the path will be reduced in priority. In particular, the first hop (real source) will have its ranking decreased
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Motivation
When a request in a "submission failed" state is evaluated by the finished, it shouldn't deteriorate the source ranking. There is no reason to consider the source is bad and must be avoided.
The issue was brought to us when a transfer was scheduled from tape; while the disk (with higher priority) source was ignored because of an issue during the initial submission.
The text was updated successfully, but these errors were encountered: