Hi Mark,
Thanks for the response and sorry for the delayed answer.
I don't think my use case is special in any way. It's just a normal
web-app exposing a JSON REST API that is being queried from time to
time. I'm hitting the issue with just a normal usage, not by
stress-testing or anything. That's why I was saying that I can't believe
I'm the only one seeing this... but who knows, timing issues are strange.
I'm not really sure how to proceed with providing a test case. As I
said, my use case is trivial so I don't really know what more to try
than a standard request-response program. Anyway, I'll be thinking and
will provide a reproduction if I come up with something. In the meantime
please also try to just go over the commits in 9.0.94 and 9.0.95 that
created and then partially fixed the issue - perhaps you'll figure
something out.
Regards,
Boris
On 12/11/24 10:17 AM, Mark Thomas wrote:
On 10/12/2024 08:28, Boris Petrov wrote:
I've been trying all versions of Tomcat since 9.0.93 (including the
newly released 9.0.98) and all of them have the same issue. I find it
extremely strange that no-one else hits this.
It sounds like the issue is timing related. These can be very
sensitive to different timings to the point that just enabling debug
logging is enough to change behaviour. I suspect that your particular
use case happens to trigger the issue.
Mark, are you still looking into this problem?
It is on my radar but not being actively investigated.
You mentioned that you have some suspicions. I can't give you a
simple test case that triggers the issue but I hit it consistently
when I run my tests (sometimes after 10 minutes, sometimes after much
longer). I'm willing to help with debugging. Please ping me privately
to not spam the mailing list if you think I can help somehow - say
you give me builds to test with and I send you back the results.
No reason to move this off list. Others may find the process of
tracking this down useful.
The first step is we need a test case that reproduces this. The ideal
is test case in the same form as the Tomcat tests that triggers the
issue every time. I recognise that isn't likely here.
What we typically get is a simple web application (with source) and a
command to call wrk (or similar) to generate load that then triggers
the issue. With that we can start investigating. That typically
involves a combination of:
- examining logs
- adding additional debug logging
- adjusting the test to try and trigger the issue more frequently
until, hopefully, we understand what is going on and can create a fix.
If you are able to provide us with a test case that demonstrates the
issue then we can start looking into this.
Mark
Regards, Boris
On 2024/10/09 16:42:08 Mark Thomas wrote:
> On 09/10/2024 03:33, Boris Petrov wrote:
> > I also have been experiencing the same issue (with Tomcat 9).
9.0.93
> > works fine. 9.0.94 is unusable. 9.0.95 and now 9.0.96 almost
work but
> > sometimes I get the same behavior as with 9.0.94. I see it in my
> > integration tests - there are some sporadic failures here and
there when
> > I upgrade from 9.0.93. Not sure how to help more but I just
wanted to
> > chime in and say that Ahmed is not the only one still seeing the
problem
> > even with the newest version.
>
> What we need both to track down the root cause (I have my
suspicions but
> no proof) is a test case that triggers the issue. The simpler the
test
> case the better but at this point I'd settle for anything that
triggered
> the issue in a reasonable time frame.
>
> Mark
>
> >
> > On 2024/10/04 10:00:03 Ahmed Ashour wrote:
> > > > How rare? Once in how many requests? Can you trigger this via
> > automated testing e.g. with wrk?
> > > After working for some time (from 10 minutes to an hour),
making a
> > request to a page (with subsequent JS/images) every one minute, the
> > issue is shown, happens on Chrome and Brave.
> > > The requests with wrk are all successful, tested for one hour,
using
> > the default settings.
> > > Background:- There is a Tomcat server which is restarted
daily, to
> > clean the auto deploy of the applications.- Three members have
seen the
> > issue, in the last 3 days.- The main application is protected by
basic
> > authentication- Once the issue happens, even the sample
non-protected
> > application (html/js) is not accessible.
> > >
> > > > Does setting discardRequestsAndResponses="true" help at all?
> > >
> > > No, it doesn't.
> > > The settings now are:
> > > <UpgradeProtocol discardRequestsAndResponses="true"
> > className="org.apache.coyote.http2.Http2Protocol"
readTimeout="20000"/>
> > >
> > > which still gives the error.
> > > The current workaround is to remove the UpgradeProtocol element.
> > >
> > > I wonder if low-level logs, or network sniffing can help, as
it is a
> > secure connection.
> > > Thanks,Ahmed
> >
> >
---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
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
