-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decode percent encoding on-the-fly to avoid HttpData.usingBuffer #22
Conversation
Motivation: HttpData.usingBuffer may require copying data when the data is only present on disk. This is slow and defeats the purpose of moving the data to disk in the first place. Likely most large files will use multipart where this is not an issue, but the possibility still makes alternative HttpData implementations awkward. Thus, usingBuffer should be avoided where possible. Modification: Alter HttpPostStandardRequestDecoder to decode data on-the-fly instead of all at once. Result: usingBuffer is not called anymore. usingBuffer is now unused outside the HttpData implementations themselves.
@pderop @violetagg can you take a look at this |
@yawkat , I will take a look (probably next wednesday), thanks. |
thanks. no rush, i dont need this change urgently. |
@pderop bump |
@yawkat , thanks for this PR, I could review and validate it, nice improvement ! The reason why usingBuffer/usingContent has been introduced is explain in #17 (old getBuffer/content methods were also returning a copy in case of file-based HttpData). Now, even in reactor-netty, we do not use The @chrisvest or @normanmaurer , do you want to review this PR or may I merge it ? let me know |
yea, in netty 4 micronaut would memory map the file for getBuffer so it still worked. but this is not possible anymore with netty 5. so this change became necessary for our implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@franz1981 , thanks for the review ! |
@yawkat , thanks a lot for the PR, which has just been merged. |
Motivation:
HttpData.usingBuffer may require copying data when the data is only present on disk. This is slow and defeats the purpose of moving the data to disk in the first place. Likely most large files will use multipart where this is not an issue, but the possibility still makes alternative HttpData implementations awkward. Thus, usingBuffer should be avoided where possible.
Modification:
Alter HttpPostStandardRequestDecoder to decode data on-the-fly instead of all at once.
Result:
usingBuffer is not called anymore. usingBuffer is now unused outside the HttpData implementations themselves.