Cyberduck
Mountain Duck
CLI#8634 closed defect (fixed)
Connection lost regularly
| Reported by: | stefan jacobi | Owned by: | dkocher |
|---|---|---|---|
| Priority: | normal | Milestone: | 4.7 |
| Component: | openstack | Version: | 4.6.5 |
| Severity: | normal | Keywords: | openstack swift connection |
| Cc: | Architecture: | ||
| Platform: |
Description
Since I updated to 4.6.5 (17000), I have huge problems with the connection via Swift Openstack. The connection is lost after nearly every step (change folder, up/download files, etc.). The initial connection need several tries until it's opened. Rolled back to 4.6.4 16110 - no problems there. Connecting via HTTP proxy (but also happening without proxy, direct network access to the storage).
I guess it has something to do with the new multiple transfers.
Change History (15)
comment:1 Changed 3 years ago by dkocher
- Component changed from core to openstack
- Milestone set to 4.7
- Owner set to dkocher
- Summary changed from Swift Openstack: Since 4.7 connection lost regularly to Connection lost regularly
comment:2 Changed 3 years ago by dkocher
- Resolution set to fixed
- Status changed from new to closed
comment:3 Changed 3 years ago by dkocher
#8635 closed as duplicate.
comment:4 Changed 3 years ago by dkocher
#8637 closed as duplicate.
comment:5 Changed 3 years ago by dkocher
- Resolution fixed deleted
- Status changed from closed to reopened
comment:6 Changed 3 years ago by dkocher
Other potential fix in r17154. From the Http Components release notes
Non-blocking connection should not trigger end-of-stream callback as long as there is still data in the session input buffer. This can cause a series of short pipelined requests to fail prematurely in case of an unexpected connection termination by the opposite endpoint.
comment:7 Changed 3 years ago by dkocher
#8651 closed as duplicate.
comment:8 Changed 3 years ago by dkocher
- Resolution set to fixed
- Status changed from reopened to closed
Please try r17201 or later.
comment:9 Changed 3 years ago by dkocher
This issue was caused by a bug in the HTTP library.
[HTTPCLIENT-1609] Stale connection check in PoolingHttpClientConnectionManager has no effect. Internal connection pool does not correctly implement connection validation.
comment:10 Changed 3 years ago by dkocher
Reverted in r17224.
comment:11 Changed 3 years ago by dkocher
Updated library dependency with fix in r17222.
comment:12 Changed 3 years ago by dkocher
Please update to the latest snapshot build available.
comment:13 follow-up: ↓ 14 Changed 3 years ago by stefan jacobi
The file list still won't update after uploading a file, only restarting build 17342 helps with that. Also after deleting or moving a file.
comment:14 in reply to: ↑ 13 Changed 3 years ago by dkocher
Replying to stefan jacobi:
The file list still won't update after uploading a file, only restarting build 17342 helps with that. Also after deleting or moving a file.
comment:15 Changed 3 years ago by dkocher
#8697 closed as duplicate.
Please try r17124 or later.