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.
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?
