Thanks for explaining the option with getRequestChannel! Got it working by
reading content into a pre-allocated ByteBuffer.
if it returns 0 register a read listener and call resumeReads()
One thing I don't fully understand though is your note about registering a
read listener (+ calling resumeReads) and why this is needed. Is it a
mandatory step, and if it is, are you referring to application-specific
read listener or Undertow's
io.undertow.server.protocol.http.HttpReadListener? I guess this is pretty
basic question, so it would be great if you can just point me to the right
place at documentation, so that I can figure it out.
Thinking about it we probably just need some way to buffer a
complete/partial message and then invoke a callback with the data.
Yep, I guess this would be easier for the app developer to use.
On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
You can use the getRequestChannel() method to get the request
channel.
Basically call read() on the channel till it returns either 0 or -1, if it
returns -1 you are done, if it returns 0 register a read listener and call
resumeReads().
I have always been meaning to add a nicer non-blocking API for this, but I
have never been exactly sure what would be required here. Thinking about it
we probably just need some way to buffer a complete/partial message and
then invoke a callback with the data.
Stuart
Vladimir Tsukur wrote:
> One of the ways to obtain request entity is to call
> HttpServerExchange.startBlocking and then read content from the
> HttpServerExchange.getInputStream.
>
> Is there a way to obtain request entity in a non-blocking way?
>
> --
> Vladimir Tsukur
> Software Architect, Design Engineer and Scrum Master
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>
--
Vladimir Tsukur
Software Architect, Design Engineer and Scrum Master