On 20/01/2025 20:44, Michael wrote:
On Fri, Jan 17, 2025 at 7:45 PM Michael <eftern...@gmail.com> wrote:
On Fri, Jan 17, 2025 at 3:51 PM Chuck Caldarale <n82...@gmail.com> wrote:
In various logs from nightly(?) Tomcat test runs, I've been able to
find a similar problem. See this, for instance:
https://nightlies.apache.org/tomcat/tomcat-10.1.x/logs/1309/TEST-org.apache.coyote.http2.TestAsyncError.NIO.txt
I believe that the test referred to above intentionally causes the error.
Okay, that sounds plausible.
It surprises me, though, that it's okay to provoke a NPE from the
application code, but again, I'm no expert in this :-)
Also, it seems that the error is sporadic in this log and logs from other tests.
I looked up some of the other tests where this happens. A recent
example (from a 10.1.35-dev version) is this one:
07-Jan-2025 12:30:28.836 INFO [testBug54928]
org.apache.catalina.connector.TestCoyoteAdapter$AsyncServlet$1.run
Exception caught java.lang.NullPointerException: Cannot invoke
"org.apache.catalina.connector.OutputBuffer.setErrorException(java.lang.Exception)"
because "this.ob" is null
from
https://nightlies.apache.org/tomcat/tomcat-10.1.x/logs/1564/TEST-org.apache.catalina.connector.TestCoyoteAdapter.NIO.txt
That test seems to run into the problem quite often.
Would it be helpful if I tried to find out how to run those tests so I
could start investigating how this.ob becomes null when inside
this.ob.flush()? Or should I just be prepared for NPEs?
I've modified the logging for that test so we get a little more detail
about why there is an NPE at that point.
This sounds suspiciously like the application is keeping references to requests
or responses that have already been committed and recycled.
If so, I can only imagine that this is in that of our applications
that does async processing. Can I turn on some debugging to see if
this is the case?
I wish it were that easy.
Getting Servlet async right is hard. Both from an implementers point of
view and for the developer.
I wouldn't be surprised if there is Tomcat bug in here somewhere. The
hard part is narrowing down a test to the point where only one thing
goes wrong and it happens often enough you can debug it. Often with
async issues, there are multiple things going wrong in both application
code and Tomcat code.
If it is a viable choice I would strongly recommend switching back to
non-async and use virtual threads. It is a lot easier to reason about
what is happening, what is going wrong and why when you only have a
single, container managed thread to worry about per request.
I am working my way through this thread and if I see something that
looks like a Tomcat bug I'll try and dig deeper.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
