[undertow-dev] Retrieving request entity

[Miere Teixeira]

>
> 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 at redhat.com>
wrote:

>
> 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
>
>
> _______________________________________________
> 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/20140819/6d714e63/attachment.html