[undertow-dev] Too many open files: Exception accepting request, closing server channel TCP server (NIO)

Nishant Kumar nishantkumar35 at gmail.com
Mon Mar 2 11:40:42 EST 2020


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 at redhat.com> wrote:

> On Mon, Mar 2, 2020 at 7:56 AM Stan Rosenberg <stan.rosenberg at acm.org>
> wrote:
> >
> > Stuck in CLOSE_WAIT is a symptom of the client-side not properly
> shutting down [1].
>
> 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
> `CLOSE_WAIT`.
>
> 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
> API:
> https://www.lucidchart.com/publicSegments/view/524ec20a-5c40-4fd0-8bde-0a1c0a0046e1/image.png
>
> --
> - DML
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20200302/2c59821f/attachment.html 


More information about the undertow-dev mailing list