Because the DTS monitors a lot of long-running activities (files staging, transfers), it's important that we be able to stop and restart it without losing this information. We can support this feature by having the DTS maintain a persistent store of ongoing transfers instead of storing them in a map in memory.
While we're at it, we should probably keep records of completed transfers around for a configurable period of time so that users can query the DTS for information about these transfers. This means we should store the date/time at which each transfer completes, and set up a task that periodically scrubs information about transfers whose "age" (current time - transfer completion date) exceeds this configurable time period.
These changes require a couple of additional service parameters in the YAML config file:
data_dir: a directory in which data about ongoing/completed transfers can be stored
delete_after: a time period (seconds) after which information about a completed transfer is deleted
Because the DTS monitors a lot of long-running activities (files staging, transfers), it's important that we be able to stop and restart it without losing this information. We can support this feature by having the DTS maintain a persistent store of ongoing transfers instead of storing them in a
mapin memory.While we're at it, we should probably keep records of completed transfers around for a configurable period of time so that users can query the DTS for information about these transfers. This means we should store the date/time at which each transfer completes, and set up a task that periodically scrubs information about transfers whose "age" (current time - transfer completion date) exceeds this configurable time period.
These changes require a couple of additional
serviceparameters in the YAML config file:data_dir: a directory in which data about ongoing/completed transfers can be storeddelete_after: a time period (seconds) after which information about a completed transfer is deleted