Errors in logs with unknown origin

I try to keep the logs of our installations clean, as this makes it easier to find problems.

But here’s an error we get on regular basis of which we can’t find the origin.

It’s probably related to something we did, as it happends on a certain project, no matter where we install the backup. But I have no idea where to look for the origin of this issue.

INFO   | jvm 1    | 2019/01/07 15:41:59 | E [o.a.w.DefaultExceptionMapper  ] [15:41:59]: unexpected exception when handling another exception: Header was already written to response! 
INFO   | jvm 1    | 2019/01/07 15:41:59 | java.lang.IllegalStateException: Header was already written to response!
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.checkHeader(HeaderBufferingWebResponse.java:64)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.sendError(HeaderBufferingWebResponse.java:105)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.http.handler.ErrorCodeRequestHandler.respond(ErrorCodeRequestHandler.java:77)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:814)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:302)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:311)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:311)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:311)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:225)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:281)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:245)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at com.inductiveautomation.ignition.gateway.bootstrap.SRFilter.doFilter(SRFilter.java:80)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.Server.handle(Server.java:518)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
INFO   | jvm 1    | 2019/01/07 15:41:59 | 	at java.lang.Thread.run(Thread.java:748)

Do you/others in your facility use Firefox as a primary browser?
We’re aware of this issue (the logging is actually from Jetty, our internal webserver) but it’s on a low priority backlog because it doesn’t have any actual effects (besides, obviously, cluttering up log messages). The only common thread in the bug report that I can see has to do with use of Firefox - which is odd, but again, without doing all the research I’m not sure what it actually indicates.

I get these, and I use Firefox. I doubt it’s really Firefox’s problem. You have a web resource stream that isn’t wrapped in a try-catch. Once you commit to a payload by sending the headers, you have to deliver.

<flame>Everyone who cares about privacy and security should be using Firefox, btw. With NoScript and Adblock+, at a minimum.</flame>

Oh, yeah - definitely didn’t mean to imply that it’s anything besides our issue - it’s just that only FF seems to be care about this state/return a condition that causes Jetty to log this error.

Yes, I use Firefox, and that may explain why I see this error so often when working on a project, but it doesn’t appear on older projects.

Can someone explain specifically how Firefox is related? Is it if you check the gateway using firefox, for logs, configuration etc? Is it if a user downloads a project applet using firefox? Should the applets not care about which browser you use? They do not seem to open in the browser, but I’m not strong on networking/java.

The error is thrown in the logs when browsing the gateway webpage itself (ie, status/configure) using Firefox. If we knew exactly why, we would have fixed it already :slight_smile: )