<div dir="auto">That is expected. For asynchronous io send() is not guaranteed to have finished sending by the time it returns, if you want to do more processing after calling send() you need to provide a callback.<div dir="auto"><br></div><div dir="auto">If no callback is supplied then endExchange will be called automatically when sending is complete.</div><div dir="auto"><br></div><div dir="auto">Stuart</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 6 Jun. 2018, 9:29 pm Girish Sharma, <<a href="mailto:scrapmachines@gmail.com">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>(Forgot to reply all)</div><div><br></div><div>One correction in my previous mail. The issue (connection being closed before response is transferred fully) caused by calling endExchange only happens in non-blocking exchange calls. In case exchange.startBlocking is called, then the issue is not reproducible with or without endExchange call.</div><div><br></div><div>Regards<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 6, 2018 at 6:27 PM Girish Sharma <<a href="mailto:scrapmachines@gmail.com" target="_blank" rel="noreferrer">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>Thanks for the response, Stuart. Based on your reply with respect to endExchange, it looks like it should not be cause of any incomplete response issue.</div><div><br></div><div>With respect to thread safety and exchange, the exchange is always handled in a single thread. The only thing we do to exchange is the following (apart from reading/writing headers):</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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">public void </span>handleRequest(HttpServerExchange exchange) <span style="color:rgb(0,0,128);font-weight:bold">throws </span>Exception {<br> <span style="color:rgb(0,0,128);font-weight:bold">if </span>(exchange.isInIoThread()) {<br> exchange.dispatch(<span style="color:rgb(0,0,128);font-weight:bold">this</span>);<br> <span style="color:rgb(0,0,128);font-weight:bold">return</span>;<br> } </pre></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"Courier New";font-size:9pt">// and then later on (with or without calling exchange.startBlocking() ):</pre></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"Courier New";font-size:9pt">exchange.getResponseSender().send(response.toString());<br></pre></blockquote><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-size:9pt"><pre><span style="font-family:arial,helvetica,sans-serif"><br></span></pre><pre><span style="font-family:arial,helvetica,sans-serif">Also, I have personally verified that without the explicit endExchange call, the full response is rendered with 100% certainty. While using the endExchange, the connection exits early sometimes.<br></span></pre></pre></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 6, 2018 at 8:26 AM Stuart Douglas <<a href="mailto:sdouglas@redhat.com" target="_blank" rel="noreferrer">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">If is basically just an convenience method that will close both the request and the response for you, so you never *have* to call it. It also has nothing to do with blocking exchanges, it will do the same thing either way.<br><div><br></div><div>From your TLDR it sounds like you are doing something wrong thread safety wise. In particular it sounds like you may not be using dispatch() correctly to make sure that only one thread 'owns' the exchange at a time.</div><div><br></div><div>Stuart</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 6, 2018 at 12:44 AM, Girish Sharma <span dir="ltr"><<a href="mailto:scrapmachines@gmail.com" target="_blank" rel="noreferrer">scrapmachines@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi there,</div><div><br></div><div>I was wondering when to call the endExchange method on the exchange manually? Is it required to call it if we have called startBlocking() on the exchange?</div><div><br></div><div>How is the getResponseSender().sen("SOME TEXT") behavior if we call endExchange() with and without a prior startBlocking() call<br></div><div><br></div><div><b>tldr;</b><br></div><div>I have been using Undertow for a while now. We were originally only using request parameters from the incoming request and thus, we never had to start the blocking exchange. Recently we started consuming the payload of a POST call and thus, we started blocking the exchange. Post this we observed memory leaks. While we were trying to figure out the cause of the memory leaks, we made a few changes. While the memory leaks got fixes, we started observing incomplete responses from some of the API. Basically, the exchange was being ended before the async, multi part, response was completely sent off. While trying to fix the issue, should I completely remove the explicit endExchange call or leave it there for the startBlocking() branch of code and only remove for non blocking exchange?</div><div> <br></div><div>Regards<span class="m_9019303941371369113m_-3633705098645808602m_-2297786973010151118m_1788281989196834409HOEnZb"><font color="#888888"><br></font></span></div><span class="m_9019303941371369113m_-3633705098645808602m_-2297786973010151118m_1788281989196834409HOEnZb"><font color="#888888"><div>-- <br><div dir="ltr" class="m_9019303941371369113m_-3633705098645808602m_-2297786973010151118m_1788281989196834409m_3391657181218069699gmail_signature" data-smartmail="gmail_signature"><span>Girish Sharma</span></div></div></font></span></div>
<br>_______________________________________________<br>
undertow-dev mailing list<br>
<a href="mailto:undertow-dev@lists.jboss.org" target="_blank" rel="noreferrer">undertow-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" rel="noreferrer noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br></blockquote></div><br></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_9019303941371369113m_-3633705098645808602m_-2297786973010151118gmail_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><br clear="all"><br>-- <br><div dir="ltr" class="m_9019303941371369113gmail_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>