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
Doing remote-remote testing I found something interesting. Using three machines (gyller: etc, skirner_x: data source, TARGET: data target) I decided to check how it handles broken connections. I tested two situations
A) I run etc on gyller, having etd running on target, but not on source. etc cannot connect, so it waits and then retries to connect. After a while, I start etd on source, and then etc finds the connection and starts the transfer. All good.
B) However, if I now kill the etd instance on source, the transfer stops. etc now tries to re-transfer the file, but it does NOT try to reconnect! So, even if I restart etd on source, the transfer is not resumed because the connection is never re-established (so the transfer-retries do not work).
Doing remote-remote testing I found something interesting. Using three machines (gyller: etc, skirner_x: data source, TARGET: data target) I decided to check how it handles broken connections. I tested two situations
A) I run etc on gyller, having etd running on target, but not on source. etc cannot connect, so it waits and then retries to connect. After a while, I start etd on source, and then etc finds the connection and starts the transfer. All good.
B) However, if I now kill the etd instance on source, the transfer stops. etc now tries to re-transfer the file, but it does NOT try to reconnect! So, even if I restart etd on source, the transfer is not resumed because the connection is never re-established (so the transfer-retries do not work).
Here is very verbose output from the etc side:
The text was updated successfully, but these errors were encountered: