<div dir="auto">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.<div dir="auto"><br></div><div dir="auto"><span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,255,255)">setServerOption(</span><span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,255,255)">UndertowOptions</span><span style="color:rgb(0,92,197);font-family:sfmono-regular,consolas,"liberation mono",menlo,monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,255,255)"><span style="color:rgb(215,58,73)">.</span>ENABLE_HTTP2</span><span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,255,255)">, </span><span style="color:rgb(0,92,197);font-family:sfmono-regular,consolas,"liberation mono",menlo,monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,255,255)">true</span><span style="color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,255,255)">)</span><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 2, 2020, 7:48 PM David Lloyd <<a href="mailto:david.lloyd@redhat.com" rel="noreferrer noreferrer" target="_blank">david.lloyd@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 2, 2020 at 7:56 AM Stan Rosenberg <<a href="mailto:stan.rosenberg@acm.org" rel="noreferrer noreferrer noreferrer" target="_blank">stan.rosenberg@acm.org</a>> wrote:<br>
><br>
> Stuck in CLOSE_WAIT is a symptom of the client-side not properly shutting down [1].<br>
<br>
I would partially disagree. In the article you linked: "It all starts<br>
with a listening application that leaks sockets and forgets to call<br>
close(). This kind of bug does happen in complex applications." This<br>
seems to be essentially what's happening here: the server isn't<br>
completing the connection (for some reason), stranding the socket in<br>
`CLOSE_WAIT`.<br>
<br>
We can't assume that the client is abandoning the connection after<br>
`FIN_WAIT2` (the titular RFC violation); if the server stays in<br>
`CLOSE_WAIT`, then even if the client dutifully stays in `FIN_WAIT2`<br>
forever, the resolving condition still needs to be that the server<br>
shuts down its side of the connection.<br>
<br>
This diagram is a useful visual aid, mapping TCP states to the XNIO<br>
API: <a href="https://www.lucidchart.com/publicSegments/view/524ec20a-5c40-4fd0-8bde-0a1c0a0046e1/image.png" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.lucidchart.com/publicSegments/view/524ec20a-5c40-4fd0-8bde-0a1c0a0046e1/image.png</a><br>
<br>
-- <br>
- DML<br>
<br>
</blockquote></div>