S3 extension does not work correctly with range requests to HawkBit artifacts #91
Comments
|
I suspect #71 is also showing another aspect of this problem. |
zyga
added a commit
to zyga/hawkbit-extensions
that referenced
this issue
Oct 2, 2023
The basic itent is to allow expressing an input stream for a fragment that corresponds to a single range request. This patch is not ready to land, because it requires lock-step update in HawkBit proper. The long story short, is that the current abstraction of getFileInputStream is just insufficient to efficiently implement range requests for artifacts. There are two goals for efficiency: - We should not request or discard data we do not need - We read all the data we requested and close the stream properly The second problem is somewhat elusive, since S3 input stream has a close() method that informs us of incorrect usage if not all content is drained, when S3 is sending the content but are are not reading. Corresponging HawkBit change is posted to HawkBit in a separate patch. Fixes: eclipse-hawkbit#91 Signed-off-by: Zygmunt Krynicki <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using the latest milestone snapshot of hawkbit and the s3 extension from this repository results in extremely poor performance (down to it not really working) for byte-range requests.
Casual inspection seems to indicate that the API for artifacts is not well suited for this. This prevents the use of hawkbit with s3 and rauc adaptive updates.
The text was updated successfully, but these errors were encountered: