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.
With test cases that do not trigger this issue the difference between
the two is marginal. Remy is more familiar with the details than me but
from memory useAsyncIO="true" is a little better on older JREs. On
modern JREs there isn't much in it. It is also likely to depend on
application usage patterns, OS, etc. In short, you'd need to test the
difference on your application with your hardware etc. I'd expect the
difference to be hard to measure.
Mark
Regards,
Kedar
-----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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
