spring-boot: Actuator: NPE in LongTaskTimingHandlerInterceptor
I encountered the following NPE in Spring Boot Actuator 2.1.3.RELEASE:
java.lang.NullPointerException: null
at org.springframework.boot.actuate.metrics.web.servlet.LongTaskTimingHandlerInterceptor.stopLongTaskTimers(LongTaskTimingHandlerInterceptor.java:123)
at org.springframework.boot.actuate.metrics.web.servlet.LongTaskTimingHandlerInterceptor.afterCompletion(LongTaskTimingHandlerInterceptor.java:78)
at org.springframework.web.servlet.HandlerExecutionChain.triggerAfterCompletion(HandlerExecutionChain.java:174)
at org.springframework.web.servlet.DispatcherServlet.triggerAfterCompletion(DispatcherServlet.java:1424)
…
I believe the assumption is that LongTaskTimingContext#get(HttpServletRequest)
never returns null
. However, it appears that there can be a case where the request does not contain the required attribute.
I think the code should check for null to be safe.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 34 (21 by maintainers)
@wilkinsona I just saw the same stacktrace (from my POV) in an application we are developing (spring-boot 2.3.1). Strangely it occurred multiple times (it’s not when the app shutdowns) and we are using Undertow. Like mentioned in this ticket I think it is related to a new end-point we wrote which is
sync
and should beasync
@urosht As far as we know, the problem only occurs in Tomcat during shutdown with a long-running synchronous response. As explained in this comment we are not planning to make any changes to address things with Tomcat. The problem can and should be avoided by using an async response via
DeferredResult
or similar and tuning the unload delay.The Undertow problem is different as it can occur at any time if a client closes a connection to which the server was still writing data. This will have to be fixed in Undertow.
Hi @wilkinsona , in the related issue #21557, I see you have opened a ticket for Undertow but we are experiencing this issue with Tomcat on 2 different apps (Spring Boot 2.1.6 and 2.2.1). Both started happening after we’ve included micrometer dependency for exporting metrics. 2 questions:
Thanks
It depends how long the request takes to complete before Tomcat shuts down. Once the shutdown sequence starts, Tomcat will reject new requests and give in-flight requests at least Context.unloadDelay (default 2s) to complete (Servlets are stopped serially and each gets up to unloadDelay - in practise it is usually only one Servlet that has all the long running requests so you only see a wait of ~2s). 9.0.15 extended this delay to async requests. Once unloadDelay has expired, Tomcat continues with shut down. Any remaining in-flight requests are almost certain to see exceptions. If you have long running requests and you want a clean shutdown, you need to increase unloadDelay to > longest expected request processing time.