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. If no callback is supplied then endExchange will be called automatically when sending is complete. Stuart On Wed, 6 Jun. 2018, 9:29 pm Girish Sharma, <scrapmachines(a)gmail.com&gt; wrote: > (Forgot to reply all) > > 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. > > Regards > > On Wed, Jun 6, 2018 at 6:27 PM Girish Sharma <scrapmachines(a)gmail.com&gt; > wrote: > >> 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. >> >> 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): >> >> public void handleRequest(HttpServerExchange exchange) throws Exception { >>> if (exchange.isInIoThread()) { >>> exchange.dispatch(this); >>> return; >>> } >>> >>> // and then later on (with or without calling exchange.startBlocking() ): >>> >>> exchange.getResponseSender().send(response.toString()); >>> >>> >> 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. >> >> >> On Wed, Jun 6, 2018 at 8:26 AM Stuart Douglas <sdouglas(a)redhat.com&gt; >> wrote: >> >>> 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. >>> >>> 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. >>> >>> Stuart >>> >>> >>> On Wed, Jun 6, 2018 at 12:44 AM, Girish Sharma <scrapmachines(a)gmail.com >>> > wrote: >>> >>>> Hi there, >>>> >>>> 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? >>>> >>>> How is the getResponseSender().sen("SOME TEXT") behavior if we call >>>> endExchange() with and without a prior startBlocking() call >>>> >>>> *tldr;* >>>> 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? >>>> >>>> Regards >>>> -- >>>> Girish Sharma >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >>> >>> >> >> -- >> Girish Sharma >> B.Tech(H), Civil Engineering, >> Indian Institute of Technology, Kharagpur >> > > > -- > Girish Sharma > B.Tech(H), Civil Engineering, > Indian Institute of Technology, Kharagpur >