[undertow-dev] When to call HttpServerExchange#endExchange explicitly?

[Girish Sharma]

Cool, thanks! It makes sense.

On Thu, Jun 7, 2018 at 7:20 AM Stuart Douglas <sdouglas at redhat.com> wrote:

> 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 at 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 at 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 at 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 at 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 at 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
>>
>

-- 
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180607/671c6c56/attachment.html