On 16/12/2024 10:28, Boris Petrov wrote:
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.
The only HTTP/2 changes relate to error handling. If the traffic levels are relatively low, you could try enabling debug logging for org.apache.coyote.http2 - that might provide some insights as to what is going on.
Mark
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.MarkRegards, 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
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
