On 16/06/2021 21:52, Christopher Schultz wrote:
Mark,
On 6/16/21 14:10, Mark Thomas wrote:
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.
Is it inadvisable to use a trivial JSP or Servlet that just generates X
bytes? Or does this require the use of the DefaultServlet at the moment?
Right now, I don't know.
Is it still possible to reproduce using smaller window sizes and smaller
total resource sizes? It would be nice if a unit-test didn't have to
transfer 5GiB even through the loopback interface.
I may have a better answer after I do some further investigation tomorrow.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
