Thanks, I will try an update. As for `ErrorPageErrorHandler`, does it make a difference that we're not displaying pages to users? Our use of Jetty is mostly AJAX Web services--the client doesn't really have anything to look at in the response body if the status code is 4xx or 5xx.
On Mon, Nov 4, 2019 at 4:29 PM Joakim Erdfelt <[email protected]> wrote: > > 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
_______________________________________________ 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
