<div dir="ltr"><div>Got it, thanks!</div><div><br></div><div>I implemented and tested out all three approaches and found that the RequestBufferingHandler is the most efficient (even if it consumes 2-3% higher CPU usage than the request receiver approach).</div><div><br></div><div>Regards.<br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 4, 2018 at 5:05 AM Stuart Douglas <<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 3, 2018 at 8:15 PM Girish Sharma <<a href="mailto:scrapmachines@gmail.com" target="_blank">scrapmachines@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Stuart,</div><div><br></div><div>Thanks for getting back to me. I have some comments below:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You just read it as normal<br></blockquote><div><div> I am assuming that by normal, you mean the <br></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">exchange.startBlocking() + </span><span style="font-family:monospace,monospace">(InputStream stream = exchange.getInputStream())</span><span style="font-family:monospace,monospace"></span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">approach to read the input stream?</span> But then what benefit we get here as compared to not using the RequestBufferingHandler and directly using this approach? Is the following loop (typically used in reading input stream) going to be much more efficient?:</div></div></div></blockquote><div><br></div><div>Say you have a slow mobile client that takes 2s to upload its request. Without the request buffering handler the worker thread will be blocked for 2s. If you have lots of these slow clients you could exhaust the worker thread pool, causing request to queue and generally decreasing performance. If you use the request buffering handler the worker thread will not start work until after the data has been read, so it does not block on IO.</div><div><br></div><div>Stuart</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div><div><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"Courier New";font-size:9pt"><span style="color:rgb(0,0,128);font-weight:bold">while </span>((line = bufferedReader.readLine()) != <span style="color:rgb(0,0,128);font-weight:bold">null</span>) {<br> stringBuffer.append(line);<br>}</pre>Regards<br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 3, 2018 at 6:34 AM Stuart Douglas <<a href="mailto:sdouglas@redhat.com" target="_blank">sdouglas@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You just read it as normal. The advantage is that if you are going to dispatch to a worker thread then the dispatch does not happen until the request has been read, thus reducing the amount of time a worker spends processing the request. Essentially this allows you to take advantage of non-blocking IO even for applications that use blocking IO, but at the expense of memory for buffering.<div><br></div><div>Stuart</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 2, 2018 at 8:55 PM Girish Sharma <<a href="mailto:scrapmachines@gmail.com" target="_blank">scrapmachines@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>I tried searching around in github/stackexchange but could not find anything related to RequestBufferingHandler.</div><div> <br></div><div>I understand that RequestBufferingHandler would read the request body for me and then call the handler assigned as the next handler. But how does the next handler read the buffered request body?</div><div><br></div><div>Looking around the code of RequestBufferingHandler, I see that it adds an attachment to the exchange, but the key for that attachment is protected to the undertow package.</div><div><br></div><div>How can I read the value of that attachment? Or is there some other way to read the buffered request body?</div><div><br></div><div>PS: I know the alternate approach of reading request body i.e startBlocking + getInputStream and getRequestReceiver().receiveFullString , but I am interested in using the RequestBufferingHandler in particular.<br></div><div><br>-- <br><div dir="ltr" class="m_-2244601539523481682m_-1504351031564393935m_-1725082406311556829m_-2693181955344862684gmail_signature"><span>Girish Sharma</span></div></div></div>
_______________________________________________<br>
undertow-dev mailing list<br>
<a href="mailto:undertow-dev@lists.jboss.org" target="_blank">undertow-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a></blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_-2244601539523481682m_-1504351031564393935gmail_signature" data-smartmail="gmail_signature"><span>Girish Sharma<br>B.Tech(H), </span><span>Civil Engineering</span><span>,</span><div><span>Indian Institute of Technology, Kharagpur</span></div>
</div>
</blockquote></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><span>Girish Sharma<br>B.Tech(H), </span><span>Civil Engineering</span><span>,</span><div><span>Indian Institute of Technology, Kharagpur</span></div>
</div>