I didn't get time to write standalone program to reproduce it but with new
version 3.7.7-Final, i am not able to survive for more than an hour. With
the older default xnio version of Undertow (xnio 3.3.8-Final) i can run
server for few days until it stops working with error i mentioned in first
Just FYI, i am using OpenJDK 11 with OpenJ9 JVM.
On Wed, Mar 4, 2020, 10:54 AM Flavia Rainone <frainone(a)redhat.com> wrote:
Can someone provide a reproducer for this error?
As for the old version of XNIO, it will be upgraded in Undertow
On Mon, Mar 2, 2020 at 8:47 PM Stuart Douglas <sdouglas(a)redhat.com> wrote:
> Hmm, maybe this is a bug in the HTTP/2 close code then, and somehow the
> connection is not being closed if the client hangs up abruptly. I had a
> quick look at the code though and I think it looks ok, but maybe some more
> investigation is needed.
> On Tue, 3 Mar 2020 at 03:41, Nishant Kumar <nishantkumar35(a)gmail.com>
>> Yes, i have no control on client side. I am using HTTP2. I have tried
>> increasing open file limit to 400k but that consumes all memory and system
>> hangs. I will probably try to put a nginx in front of Undertow and test.
>> setServerOption(UndertowOptions.ENABLE_HTTP2, true)
>> On Mon, Mar 2, 2020, 7:48 PM David Lloyd <david.lloyd(a)redhat.com> wrote:
>>> On Mon, Mar 2, 2020 at 7:56 AM Stan Rosenberg <stan.rosenberg(a)acm.org>
>>> > Stuck in CLOSE_WAIT is a symptom of the client-side not properly
>>> shutting down .
>>> I would partially disagree. In the article you linked: "It all starts
>>> with a listening application that leaks sockets and forgets to call
>>> close(). This kind of bug does happen in complex applications." This
>>> seems to be essentially what's happening here: the server isn't
>>> completing the connection (for some reason), stranding the socket in
>>> We can't assume that the client is abandoning the connection after
>>> `FIN_WAIT2` (the titular RFC violation); if the server stays in
>>> `CLOSE_WAIT`, then even if the client dutifully stays in `FIN_WAIT2`
>>> forever, the resolving condition still needs to be that the server
>>> shuts down its side of the connection.
>>> This diagram is a useful visual aid, mapping TCP states to the XNIO
>>> - DML
> undertow-dev mailing list
Principal Software Engineer
Red Hat <https://www.redhat.com>