> On Jan 20, 2025, at 14:44, Michael <eftern...@gmail.com> 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 :-)
Exceptions are frequently used when an application violates the behavior that the spec requires. >> 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 believe that the output buffer is set to null at some point during response completion processing, not during the flush() call. You might want to look through the BZ report that prompted creation of this particular test: https://bz.apache.org/bugzilla/show_bug.cgi?id=54928 >>> 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. Yes - look for your application’s usage of the AsyncContext.complete() API, since I think somewhere inside that call is where the output buffer will get cleared out. Note that complete() will be called implicitly if the response times out (eg, the client disconnects). If your application is trying to use the response object after that, you’ve got a problem. A common problem is putting a reference to the request, response, or AsyncContext in a class (static) variable, or in a thread local where it can only cause confusion. > Can I turn on some debugging to see if this is the case? Sorry, I can’t help with the additional debugging, but possibly others on the list can. - Chuck
