Silvio, This is the second time I've heard about a problem fetching browser resources like CSS or js. Can you attach the stacks you are seeing?
On Mon, 2 Dec 2019, 22:58 Silvio Bierman, <[email protected]> wrote: > Hi Greg, > > The last few days exceptions have started to come up in the logging. We > can quite easily reproduce them by testing common parts of our web > applications using Firefox. Using Chrome the same actions do not produce > exceptions (or warnings). > > Strangely enough this seems to intermittently fail mostly (but not > exclusively) on plain GET requests for CSS resources that are requested by > the browser as a result of an @import from another CSS resource. > > We serve the files ourselves from a servlet. Perhaps we are doing > something that triggers this? GET requests for which we serve the response > content dynamically seem to work fine. The same goes for POSTs. Since it > only happens via one of our code paths I suspect we are causing this in > some way, although the code is extremely simple. > > Kind regards, > > Silvio > > > On 11/29/19 12:27 AM, Greg Wilkins wrote: > > > Silvio, > > I believe it is ignorable and you can turn the HttpChannelState logger > level down to suppress them. > However, if there a stack trace associated with that warning then it is > not what I think it is and you need to provide more information. > > What I believe is happening is that while a request is being processed, > the associated HTTP/2 stream is being reset (probably by the client?) > This asynchronous error is detected but because the request is not async, > it cannot be delivered to the request and instead we warn. This is > probably over verbose as clients can do silly things like close mid request > handling. > > @Simone Bordet <[email protected]> what do you think? > > cheers > > > > > > > > > > > > On Fri, 29 Nov 2019 at 09:03, Silvio Bierman <[email protected]> > wrote: > >> Hello all, >> >> Ever since upgrading to 9.4.24 our stderr-log is filled with these >> messages: >> >> 2019-11-28 22:56:27.469:WARN:oejs.HttpChannelState:qtp1519100796-25: >> org.eclipse.jetty.io.EofException: Reset cancel_stream_error >> >> Can anyone tell me what this means? I take it the situation is not >> critical because the application has worked flawlessly for years with >> earlier Jetty versions without these messages. Can I turn this off? >> >> Kind regards, >> >> Silvio >> >> _______________________________________________ >> 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 >> > > > -- > Greg Wilkins <[email protected]> CTO http://webtide.com > > _______________________________________________ > jetty-users mailing [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://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
