User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
For what it's worth, I also just down-versioned from
9.4.24.v20191120 because my server was using 300% CPU with no
client activity. I can't rule out my own changes, and a couple of
out-of-practice looks at thread dumps didn't give me an answer.
But there's nothing I've added that would keep a thread busy like
that after startup, and it happens after running a while. So far
it hasn't happened on the down rev: 9.4.12.v20180830.
I wonder if there's a thread activity monitor one could add that
would warn if a thread seemed runaway..
Bill
On 12/3/19 1:14 AM, Silvio Bierman
wrote:
Hi Greg,
At this moment we are receiving multiple error reports from users
who suffer from malfunctioning user interfaces. We already had
received some of those before the weekend but I did not link this
to our move to 9.4.24. Now a pattern is emerging.
They are mostly from Firefox users but some come from Safari
users. The symptoms are consistently similar: missing images,
unstyled content, parts of content missing etc.
We will probably have to revert to the previous Jetty version we
where running (9.4.20) to make sure we do not pick one that
behaves the same. In the meantime I would be happy to do any
testing if you would require so.
Kind regards,
Silvio
On 12/2/19 2:42 PM, Greg Wilkins
wrote:
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?
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?