[undertow-dev] Retrieving request entity

[Jason Greene]

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

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

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