This method doesn’t support non-blocking channels, so can’t be used in a non-blocking handler. You can, however, just use getInputStream after putting the exchange in blocking mode.
Jason, thanks for your clarification. I was focused on Vladmir's email subject and I've totally forget to consider non-blocking approach.

It leads me to a question, what's the real impact on my previously approach? I did apply a similar approach on a customer application, should I expect serious performance issue, or maybe a possible starvation on request peaks?




On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene <jason.greene@redhat.com> wrote:

On Aug 18, 2014, at 3: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.

The former, and it is required. We should add an example for this, but for now you can look at ReadTimeoutTestCase to get a rough idea. Basically the pattern is:

1. Read as much as you can (loop until 0 is returned)
2. Register a listener
3. Call resumeReads (which really means resume read notifications for your listener)

Then your listener needs to:

1. Read as much data as you can
2. Process/buffer it
3. If all data is read, suspend reads, and remove the listener from the exchange,
   otherwise return

It’s important that your listener be truly non-blocking, and have no possibility of calling blocking operations (e.g. reading files, interacting with JDBC etc).

>
> > 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

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


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