mirror of
https://github.com/scylladb/scylladb.git
synced 2026-05-23 16:22:15 +00:00
908d0d2e6a
When uploading a part (and a piece) there can be one or more background fibers handling the upload. In case client needs to abort the operation it calls .close() without flush()ing. In this case the S3 API Abort is made and the sink can be terminated. It's expected that background fibers would resolve on their own eventually, but it's not quite the case. First, they hold units for the semaphore and the semaphore should be alive by the time units are returned. Second, the PUT (or copy) request can finish successfully and it may be sitting in the reactor queue waiting for its continuation to get scheduler. The continuation references sink via "this" capture to put the part etag. Finally, in case of piece uploading the copy fiber needs _client at the end to issue delete-object API call dropping the no longer needed part. Said that -- background fibers must be waited upon on .close() if the closing is aborting (if it's successfull close, then the fibers mush have been picked up by final flush() call). Signed-off-by: Pavel Emelyanov <xemul@scylladb.com>