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(a)redhat.com
<mailto:jason.greene@redhat.com>> wrote:
On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur <flushdia(a)gmail.com
<mailto:flushdia@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 <mailto:sdouglas@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 <mailto:undertow-dev@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 <mailto:undertow-dev@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 <mailto:undertow-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/undertow-dev
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev