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
Currently it is not clear why a certain request is REPLICATING, but did not issue a FTS transfer yet. We should expose that a request is in WATING (or even MISMATCH) state. What would also be good to maybe show the queue length, although this might be more difficult as it is depending on throttle configuration.
The text was updated successfully, but these errors were encountered:
Hi @bari12. This change should be reflected where exactly? I mean, I can see the state of the rules in the 'Data Transfers/List my rules' menu. Am I looking at the right place?
Here for each file, in the RSEs column the lock status will be shown. Yellow for REPLICATING. However there are different request states for the REPLICATING lock which could be: WAITING, when the file is waiting in rucio to be released, Queued when it is still in the belly of rucio, but not submitted to FTS yet, or SUBMITTED, when it is actually within FTS. (At that point, in the FTS Monitoring column, you will be able to generate a FTS monitoring link)
I think we can perhaps expose this request state information next to the RSE name in the table.
Hi @bari12. Core changes are in a pull request, but review is required. JavaScript part still giving some errors, I'm working on it, will pull request soon.
Motivation
Currently it is not clear why a certain request is REPLICATING, but did not issue a FTS transfer yet. We should expose that a request is in WATING (or even MISMATCH) state. What would also be good to maybe show the queue length, although this might be more difficult as it is depending on throttle configuration.
The text was updated successfully, but these errors were encountered: