[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Jetty 9.4.24 prints warning messages to stderr
|
Posted inline...
On 12/3/19 12:26 PM, Simone Bordet wrote:
Silvio,
On Tue, Dec 3, 2019 at 10:15 AM Silvio Bierman
<sbierman@xxxxxxxxxxxxxxxxxx> 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.
The stack trace shows clearly that it's the client sending a reset to
the server, and that is logged at WARN level; we can certainly improve
the logging as EofException should not be logged at WARN level.
One thing that should mitigate the issue for now is to set
HttpConfiguration.notifyRemoteAsyncErrors = false
This can be done either in code or with an XML snippet, depending on
how you start Jetty.
This flag basically says whether async remote errors such as a client
resetting a HTTP/2 stream are reported to the server.
This flag is true by default, and the only thing that happens is the
the failure is logged, so functionality wise it's similar to a
no-operation.
Now, why the client resets the stream is what we should figure out.
Sometimes they do it because they attempt a request, but then they
don't care anymore, and so that is entirely ignorable by the server.
If possible, we would like to have more information.
A) Can you take some information on the client as to what is exactly
the failure for those missing images, missing CSS, etc? What does the
Firefox console say about those requests? They remain pending? You get
back an error? If so, what error?
I added some debugging info to see which requests fail so I could
compare them with the network log in FF. The leads to a very interesting
pattern. For each failed request FF says in the Transfer column: xxxKB
(raced). It shows this for other requests as well but for the failed
requests it lists nothing in the Status column, whereas the rest shows
200 OK (Cached). If I look at the request headers remote address, status
code, version and referrer policy are empty. Nothing else indicates
errors of any sort. In fact on the FF side it looks like the request is
never sent and FF does show a response (mostly images when I just
tested). However, on the server sides the request are received and throw
an exception.
B) Can you enable DEBUG logging on the server for few seconds/minutes
while this is happening? This can be done via JMX if you're using
Jetty logging, or via some other tool/facility depending on the
logging library that you're using.
I have Firefox 70.0.1 on Ubuntu and I don't see any problem with our
own websites that run Jetty (in particular https://webtide.com). Do
you see problems hitting webtide.com?
Well, going to webtide.com does show a number of similar entries in the
network listing (all of them are CSS resources) for which FF shows no
Status value and lists "No response data available for this request"
when I look at the response. I do not know how to interpret that. The
site looks to be OK but that is just my first impression.
Kind regards,
Silvio
