Re: [jetty-dev] jetty 9.4.4 with http2 enabled produces many "idletimeou

[Michele Rossi <michele.rossi@xxxxxxxxx>]

hi Simone,

> Wait a bit and then assume it sent the whole content ?

Yeah, I was thinking something along those lines - sounds like a hack but coupled with checks on the user agent it could be acceptable :)

> Easier solution would be to use good clients. Can you use Jetty's HttpClient ?

No, unfortunately in our company we have several teams working on different products using different technologies and when they choose to integrate with my system they can do what they want using whatever technology they fancy.

However in this case as well as in the old Timeout case it looks like we are dealing with CURL.

I can try to re-enable low-level HTTP logging to see if we get any evidence of misbehavior again.

thanks,

Michele

On 2 May 2017 at 11:42, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:

Hi,

On Tue, May 2, 2017 at 11:22 AM, Michele Rossi <michele.rossi@xxxxxxxxx> wrote:
> hi,
>
> I have recently re-enabled HTTP/2.0 on my Jetty 9.4.4 system and I am now
> seeing loads of these exceptions:
>
> 11:10:47.745|WARN |        o.e.j.s.HttpInput||
> java.util.concurrent.TimeoutException: Idle timeout expired: 30000/30000 ms

[snip]

> I reported a similar problem in the past - back then however it was always
> in coincidence with large HTTP PUT uploads. Now it does not seem to be the
> case.
>
> However the reason could well be again that some clients connecting to my
> systems are outdated and are not playing by the (strict?) rules of HTTP/2.0.
>
> I remember that Simone Bordet helped narrow down the problem to misbehaving
> clients.

Well, if you can confirm that this is again the case would be great.

> I tried getting in touch with the developers of CURL and libcurl in the past
> but I didn't get very far.
>
>
>
> Since it's likely that those non-compliant clients will stick around out
> there for a while I am wondering whether it would make sense to make Jetty
> more tolerant to them.

I'm not sure there is a simple way.

If the client says it will send more content, but then it does not,
there is not much that the server can do apart timeout.

Even assuming you can identify a misbehaving client, what would you do ?
Discard every request it makes ? Wait a bit and then assume it sent
the whole content ?

In any case perhaps this logic can be implemented in the application.

Easier solution would be to use good clients. Can you use Jetty's HttpClient ?

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev