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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev



--
Vladimir Tsukur
Software Architect, Design Engineer and Scrum Master