Hi Vladmir,

I've faced the same problem before, but reading each byte manually didn't fit my needs.

When the JDK 1.4 released Java NIO API, they have already created a common way to

read data with less development effort, I'm talking about java.nio.channels.Channels class, which

has many helper methods able to convert data from old IO API to NIO API.

My prefered method is Channels.newReader. This method is able to convert a StreamSourceChannel
to a lightweight Reader implementation. I like this method because many object marshallers are

ready to handle Java IO Reader implementations.

Here is a sample implementation with this approach.
Note: could be some typos as I've wrote this code manually to send this mail.

I really hope it helps you.

Please Undertow devs let me know If I'm missing some important point on this.

Regards.

On Mon, Aug 18, 2014 at 5:16 AM, Vladimir Tsukur <flushdia@gmail.com> wrote:

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

_______________________________________________
undertow-dev mailing list
undertow-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev