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.


On Wed, Jun 6, 2018 at 12:44 AM, Girish Sharma <scrapmachines@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

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?
Girish Sharma

undertow-dev mailing list