<div dir="ltr"><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.<br></blockquote>
Jason, thanks for your clarification. I was focused on Vladmir's email subject and I've totally forget to consider non-blocking approach.<br><br></div>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?<br>
<div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur <<a href="mailto:flushdia@gmail.com">flushdia@gmail.com</a>> wrote:<br>
<br>
> Thanks for explaining the option with getRequestChannel! Got it working by reading content into a pre-allocated ByteBuffer.<br>
><br>
> > if it returns 0 register a read listener and call resumeReads()<br>
><br>
> 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.<br>
<br>
</div>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:<br>
<br>
1. Read as much as you can (loop until 0 is returned)<br>
2. Register a listener<br>
3. Call resumeReads (which really means resume read notifications for your listener)<br>
<br>
Then your listener needs to:<br>
<br>
1. Read as much data as you can<br>
2. Process/buffer it<br>
3. If all data is read, suspend reads, and remove the listener from the exchange,<br>
otherwise return<br>
<br>
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).<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> > Thinking about it we probably just need some way to buffer a complete/partial message and then invoke a callback with the data.<br>
<br>
<br>
<br>
><br>
> Yep, I guess this would be easier for the app developer to use.<br>
><br>
><br>
> On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas <<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a>> wrote:<br>
> 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().<br>
><br>
> 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.<br>
><br>
> Stuart<br>
><br>
> Vladimir Tsukur wrote:<br>
> One of the ways to obtain request entity is to call<br>
> HttpServerExchange.startBlocking and then read content from the<br>
> HttpServerExchange.getInputStream.<br>
><br>
> Is there a way to obtain request entity in a non-blocking way?<br>
><br>
> --<br>
> Vladimir Tsukur<br>
> Software Architect, Design Engineer and Scrum Master<br>
><br>
> _______________________________________________<br>
> undertow-dev mailing list<br>
> <a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br>
><br>
><br>
><br>
> --<br>
> Vladimir Tsukur<br>
> Software Architect, Design Engineer and Scrum Master<br>
> _______________________________________________<br>
> undertow-dev mailing list<br>
> <a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br>
<br>
--<br>
</div></div><div class="im HOEnZb">Jason T. Greene<br>
WildFly Lead / JBoss EAP Platform Architect<br>
JBoss, a division of Red Hat<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
undertow-dev mailing list<br>
<a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br>
</div></div></blockquote></div><br></div>