You are right. Actually, my concern is if useAsyncIO="true" gives better results in general then should it be good idea to wait for that as we are still assessing the HTTP/2 behavior in context of our application.
Thanks, Kedar -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Thursday, June 17, 2021 2:32 AM To: users@tomcat.apache.org Subject: Re: Trouble with HTTP/2 during concurrent bulk data transfer (server -> client) 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
