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@gmail.com> 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@gmail.com> 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@redhat.com> 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@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@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