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
Use case: mod_proxy as reverse proxy in front of a pair of backend servers, for upload only (no downloads) of moderately large files where there are two backend servers for resilience, not performance.
It is desired to be able to resume interrupted uploads if the whole FTP session is interrupted, so reconnecting needs to use the same backend server if it is available, but still fail over to a different server if needed.
For this use case, a 'sequential' connect policy that always starts at the beginning of the list and tries each server in turn would be useful, as it would mean that under normal conditions the first server is always used and therefore interrupted STORE operations can be resumed, but if that goes offline, it will use the second. (This trivially applies to more than two servers, of course).
Using PerHost policy does not work for this case - it selects the same backend each time for a given client host, but does not fail over to using another backend if the selected one is down.
The text was updated successfully, but these errors were encountered:
Yes, I read #186 looking for any related open issues and that sounds like a useful future thing too. I am hoping that a simple sequential policy without the extra complexity of state tracking etc. would be easier to add than the full state tracking.
When I get a bit more time I plan to look at the relevant pieces of the code, if a patch that added a sequential mode might be acceptable.
Use case: mod_proxy as reverse proxy in front of a pair of backend servers, for upload only (no downloads) of moderately large files where there are two backend servers for resilience, not performance.
It is desired to be able to resume interrupted uploads if the whole FTP session is interrupted, so reconnecting needs to use the same backend server if it is available, but still fail over to a different server if needed.
For this use case, a 'sequential' connect policy that always starts at the beginning of the list and tries each server in turn would be useful, as it would mean that under normal conditions the first server is always used and therefore interrupted STORE operations can be resumed, but if that goes offline, it will use the second. (This trivially applies to more than two servers, of course).
Using PerHost policy does not work for this case - it selects the same backend each time for a given client host, but does not fail over to using another backend if the selected one is down.
The text was updated successfully, but these errors were encountered: