Hi, I don't know how to reproduce this behavior, but I have seen in our logs e.g.:
java.lang.OutOfMemoryError: Java heap space > <redacted - serializing session objects > > at > org.eclipse.jetty.server.session.SessionHandler.complete(SessionHandler.java:420) > at > org.eclipse.jetty.server.session.SessionHandler.ensureCompletion(SessionHandler.java:445) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1563) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221) > at > org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:772) > at > org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:173) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > at org.eclipse.jetty.server.Server.handle(Server.java:494) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) > at org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:314) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) > at java.lang.Thread.run(Thread.java:819) > Suppressed: java.lang.IllegalStateException: Committed > at org.eclipse.jetty.server.HttpChannel.resetBuffer(HttpChannel.java:936) > at > org.eclipse.jetty.server.HttpOutput$Interceptor.resetBuffer(HttpOutput.java:125) > at org.eclipse.jetty.server.HttpOutput.resetBuffer(HttpOutput.java:1081) > at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1108) > at org.eclipse.jetty.server.Response.resetForForward(Response.java:1101) > at org.eclipse.jetty.server.Response.reset(Response.java:1050) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:417) > ... 4 more > Suppressed: java.lang.IllegalStateException: Committed > at org.eclipse.jetty.server.HttpChannel.resetBuffer(HttpChannel.java:936) > at > org.eclipse.jetty.server.HttpOutput$Interceptor.resetBuffer(HttpOutput.java:125) > at org.eclipse.jetty.server.HttpOutput.resetBuffer(HttpOutput.java:1081) > at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1108) > at org.eclipse.jetty.server.Response.resetForForward(Response.java:1101) > at org.eclipse.jetty.server.Response.reset(Response.java:1050) > at > org.eclipse.jetty.server.HttpChannel.minimalErrorResponse(HttpChannel.java:653) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:455) > ... 4 more times 20 of each suppressed exception (some have `EatWhatYouKill` etc.)--over 1300 lines in this stack trace. Every method call in this trace is in a jetty namespace or java.* namespace--none of our code or other third-party libs are in this stack trace. I don't think we're doing anything weird with the config to put Jetty into an infinite loop like this. We do inject a custom `ErrorHandler` with an empty `writeErrorPage`. >From code analysis, I see that `minimalErrorResponse` is attempted after a failed `handle`, and indeed every other suppressed exception attempts a `minimalErrorResponse`, so there's an attempt at a less error-prone error-handling routine, which is good (though it is not helpful in this case, as `HttpChannel.resetBuffer` is attempted either way). The trouble is, it _appears_ that a failure in `minimalErrorResponse` triggers the original error-handling routine. What might cause this behavior? I believe the OOME happened first for causes unrelated to this question or Jetty in general. Using Jetty 9.4.20.v20190813. -- Jason Young
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
