[undertow-dev] Retrieving request entity

[Jason Greene]

On Aug 18, 2014, at 11:48 AM, Miere Teixeira <miere.teixeira at gmail.com> wrote:

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

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.


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

While I am not aware of any non-blocking JSON parsers, it would be possible to build an event based JSON parser, which dispatches to non-blocking handlers to take action. 

> 
> 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 at 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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at 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