<div dir="ltr"><div style>Luke,</div><div style><br></div><div style>unfortunately, I cannot reproduce the problem in on my machine - I do not see any open file descriptors left over after I connect to Hunchentoot server with SSL using a non-SSL client, and when I connect to the same server using a browser, I get an "Empty response" error.</div>
<div style><br></div><div style>In order to help you with this, I need you to isolate the problem further. Some ideas for debugging:<br><br>- Can you create a lingering file descriptor when you connect to your server using telnet, then disconnect?</div>
<div style>- Are the CLOSE_WAIT sockets actually connected to your monitoring service?</div><div style>- Do you see the CLOSE_WAIT in lsof or in netstat? I see it in netstat for sockets that have been closed by the application, but for which the FIN TCP packet has not been acknowledged by the client. Note that CLOSE_WAIT sockets are closed in the application and do no longer consume file descriptors. The final TCP handshake is performed by the kernel, and there is nothing that Hunchentoot can do to make these sockets disappear.</div>
<div style><br></div><div style>I'm not saying that Hunchentoot has no bugs, but from your description, it appears to me that your problem is related to your kernel configuration (you're hitting the system-wide limit for sockets, not the process limit for file descriptors).</div>
<div style><br></div><div style>-Hans</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 27, 2013 at 1:12 AM, Lucas Hope <span dir="ltr"><<a href="mailto:lucas.r.hope@gmail.com" target="_blank">lucas.r.hope@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there,<div><br></div><div>This is a bug report. I'm using Hunchentoot 1.2.2 from quicklisp. I encountered a server resource limit due to (I think) http connections on an https port.</div>
<div><br></div><div>Cliffs notes:</div>
<div><br></div><div>https server is not hanging up properly when a connection is attempted using normal http. This eventually causes the process to hit a kernel socket limit.</div><div><br></div><div>Details:</div><div><br>
</div><div>I recently upgraded my hunchentoot webserver from http to full ssl/https. The webservice runs on a dedicated port, and I left the port the same.</div><div><br></div><div>We had a monitoring service running to check the server was alive. However the monitoring service wasn't updated to use https.</div>
<div><br></div><div>So every half an hour or so, we got:</div><div><br></div><div><div>[2013-03-26 06:49:26 [ERROR]] Error while processing connection: A failure in the SSL library occurred on handle #.(SB-SYS:INT-SAP #X04B69660) (return code: 1). SSL error queue: </div>
<div>error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request </div></div><div><br></div><div>Also, if I connect myself using http instead of https, the browser connection times out. The server certainly doesn't hang up instantly like I'd expect.</div>
<div><br></div><div>Last night, my webserver listener threw a bsd socket error - code 24 (too many files). When I ran an lsof of the process, there were a large number of long term CLOSE_WAIT connections, which my internet research tells me is due to the server not closing connections properly. I think the connections piled up, and I thus hit the socket limit for that process.</div>
<div><br></div><div>Anyone else have that issue? Is it an easy fix?</div><div><br></div><div>Cheers,</div><div><br></div><div>-Luke</div>
<br>_______________________________________________<br>
tbnl-devel site list<br>
<a href="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/mailman/listinfo/tbnl-devel" target="_blank">http://common-lisp.net/mailman/listinfo/tbnl-devel</a><br></blockquote></div><br></div>