> Using Jetty 9.4.20.v20190813 There's been a lot of error handling improvements since 9.4.20 Can you try 9.4.22.v20191022 and see if you have less issues?
For example, Jetty 9.4.21 removed HttpChannel.minimalErrorResponse(). https://github.com/eclipse/jetty.project/commit/bde86467f4e5df595773ab11ed5e80c615b741f3 > We do inject a custom `ErrorHandler` with an empty `writeErrorPage`. It would be better if you just used the existing ErrorPageErrorHandler on your context, and called ... ErrorPageErrorHandler.addErrorPage(ErrorPageErrorHandler.GLOBAL_ERROR_PAGE, "/empty"); And had a file in your base resources called "empty" which is empty. Joakim Erdfelt / [email protected] On Mon, Nov 4, 2019 at 3:25 PM Jason Young <[email protected]> wrote: > 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
_______________________________________________ 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
