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
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(a)gmail.com>
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
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?
undertow-dev mailing list