[WIP] netty-cats: support multipart requests #3933
Conversation
| monad | ||
| .blocking { | ||
| // this operation is the one that does potential I/O (writing files) | ||
| // TODO not thread-safe? (visibility of internal state changes?) |
There was a problem hiding this comment.
question: This is the part that concerns me. The decoder is stateful, so it has an internal state changed with every call to offer. Each time a new HttpContent flows through the stream, the monad.blocking call gets a thread from the blocking pool, where it calls offer. There are no race conditions, but aren't internals of the decoder risking visibility issues because of such circumstances?
There was a problem hiding this comment.
This is fine as long as there's some memory barrier along the way (see e.g. https://stackoverflow.com/questions/12438464/volatile-variables-and-other-variables). There should be a couple of those along the way, I suspect putting back/obtaining a thread to execute blocking ops itself imposes at least one such barrier.
| file <- createFile(serverRequest) | ||
| _ <- writeBytesToFile(httpData.get(), file) | ||
| } yield file) | ||
| else monad.unit(httpData.getFile()) |
There was a problem hiding this comment.
note: Netty decoder creates the file (if it's > 16KB), so we can just get its handle here.
Partially addresses #499 - adds support for multipart requests. Responses will be implemented in a separate PR.
NettyServerHandler, a multipart request is just aStreamedHttpRequestpassed toNettyRequestBodyNettyRequestBodydelegates processing of such a request to backend-specific implementation ofpublisherToMultipartpublisherToMultipartprocesses converts the reactive Publisher to a fs2 Stream of elements of typeHttpContent. Then these elements are passed to a statefulio.netty.handler.codec.http.multipart.HttpPostRequestDecoder, which, after collecting enough of them, can produce full parts.NettyRequestBody.toRawPart- intended to be common for all backends.