Re: [OT] Trouble with HTTP/2 during concurrent bulk data transfer (server -> client)

[Christopher Schultz <ch...@christopherschultz.net>]

Mark,

On 6/16/21 17:02, Mark Thomas wrote:
> On 16/06/2021 19:42, Deshmukh, Kedar wrote:
>> Thanks Mark for the quick update.
>>
>> Can you please provide how useAsyncIO="false" makes impact in terms of 
>> performance, scalability (number of connections to the server) and 
>> reliability ?
> 
> Well, if you set useAsyncIO="false" it works. If you set 
> useAsyncIO="true" it fails 90% of the time.
> 
> I'd suggest that, with that failure rate, discussion of performance and 
> scalability are somewhat irrelevant.

Funny, but 100% true.

-chris

>> -----Original Message-----
>> From: Mark Thomas <ma...@apache.org>
>> Sent: Wednesday, June 16, 2021 11:41 PM
>> To: users@tomcat.apache.org
>> Subject: Re: Trouble with HTTP/2 during concurrent bulk data transfer 
>> (server -> client)
>>
>> On 16/06/2021 18:47, Rémy Maucherat wrote:
>>> On Wed, Jun 16, 2021 at 7:36 PM Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 16/06/2021 18:01, Deshmukh, Kedar wrote:
>>>>
>>>>> I have one additional question at this point. How easy is this issue
>>>>> to
>>>> reproduce? Does it happen every time? In 10% of requests? 1% ?
>>>>>
>>>>> [Kedar] It is reproducible 9/10 times in my environment. So 90% time
>>>>> it
>>>> is reproducible when concurrency is 5 or more and file sizes are
>>>> between 1GB-5GB.
>>>>
>>>> Thanks for the confirmation. I have converted your test classes into
>>>> a Tomcat unit test (easy for me to work with) and the issue looks to
>>>> be repeatable on Linux with the latest 10.1.x code.
>>>>
>>>> I'm starting to look at this now. I'll post again when I have more
>>>> information. I'm not expecting this to be quick.
>>
>> Kedar,
>>
>> If you set useAsyncIO="false" on the Connector that should work around 
>> the problem for now. The Servlet Async API will still be available.
>> Tomcat just uses a different code path to write to the network.
>>
>>> I did not expect it would be so easy to reproduce. Can you commit the 
>>> test ?
>>
>> It is a bit of a hack at the moment. The code isn't particularly clean 
>> and I have hard-coded some file paths for my system (I have a bunch of 
>> 5GB Windows MSDN ISOs I am using for the large files. I also don't 
>> think we want test cases that using multi-GB files running on every 
>> test run.
>>
>> If I clean things up a bit, parameterise the hard-coded paths bits and 
>> disable the test by default it should be in a reasonable state to commit.
>>
>> It looks very much like the vectoredOperation and the associated 
>> semaphore is where things are going wrong.
>>
>> I'm aiming to work on this some more tomorrow.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org