[undertow-dev] Retrieving request entity

[Stuart Douglas]

Miere Teixeira wrote:
>     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?

If you have dispatched to a worker thread it will work fine. If you are 
doing it in an IO thread you can have some serious performance issues, 
as other connections that the IO thread is servicing will not be handled 
until the blocking operation is complete.

Stuart


>
>
>
>
> On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene <jason.greene at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
>
>     On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur <flushdia at gmail.com
>     <mailto: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 <mailto: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 <mailto: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 <mailto: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
>
>
>     _______________________________________________
>     undertow-dev mailing list
>     undertow-dev at lists.jboss.org <mailto: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