7:22 a.m.
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(a)redhat.com>
wrote:
On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur <flushdia(a)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(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev