[undertow-dev] Retrieving request entity

[Miere Teixeira]

Thanks for the clarification Stuart,
I confused the concepts of IO Threads and Worker Threads.


On Wed, Aug 20, 2014 at 2:43 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

>
>
> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140821/26680f64/attachment-0001.html