<div dir="ltr">If I recall correctly socket file handles are managed by the weak object logic. <div>In the past I&#39;ve already said: &quot;Finalization will run later and likely kill you in a production environment&quot; </div><div><br></div><div>Given a high attack rate for acquiring sockets do you know when the socket instance goes away, and when the file descriptor is destroyed via cleanup of weak object, or the forced CG cycle?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 5:21 PM, David T. Lewis <span dir="ltr">&lt;<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Fri, Oct 10, 2014 at 02:09:08AM +0200, G?ran Krampe wrote:<br>
&gt;<br>
&gt; Hi guys!<br>
&gt;<br>
&gt; On 10/10/2014 01:28 AM, David T. Lewis wrote:<br>
&gt; &gt;&gt;&gt;Ron and I (3DICC) have a problem with the Unix VM networking and I am<br>
&gt; &gt;&gt;&gt;reaching out before burning too many hours on something one of you<br>
&gt; &gt;&gt;&gt;C-Unix/Socket/VM guys can fix in an afternoon - and earn a buck for your<br>
&gt; &gt;&gt;&gt;trouble.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Cool.  This is likely easy to fix.  Your image is running out of file<br>
&gt; &gt;&gt;descriptors.  Track open and close calls, e.g. add logging around at<br>
&gt; &gt;&gt;least StandardFileStream&gt;&gt;#primOpen:writable:<br>
&gt; &gt;&gt;, AsyncFile&gt;&gt;#primOpen:forWrite:semaIndex:,<br>
&gt; &gt;&gt;Socket&gt;&gt;#primAcceptFrom:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:<br>
&gt; &gt;&gt;and their associated close calls and see what&#39;s being opened without being<br>
&gt; &gt;&gt;closed.  It shoudl be easy to track=down, but may be more difficult to<br>
&gt; &gt;&gt;fix.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Good luck!<br>
&gt;<br>
&gt; Aha. Soo... am I understanding this correctly - we are probably leaking<br>
&gt; fds and when we go above 1024 this makes select() go bonkers and<br>
&gt; eventually leads to the &quot;Bad file descriptor&quot; error?<br>
&gt;<br>
&gt; &gt;I agree with what Eliot is saying and would add a few thoughts:<br>
&gt;<br>
&gt; &gt;- Don&#39;t fix the wrong problem (DFtWP). Unless you have some reason to<br>
&gt; &gt;believe that this server application would realistically have a need to<br>
&gt; &gt;handle anything close to a thousand concurrent TCP sessions, don&#39;t fix<br>
&gt; &gt;it by raising the per-process file handle limit, and don&#39;t fix it by<br>
&gt; &gt;reimplementing the socket listening code.<br>
&gt;<br>
&gt; We haven&#39;t done the exact numbers, but we could probably hit several<br>
&gt; hundreds concurrent at least. 1024 seemed a bit &quot;over the top&quot; though :)<br>
&gt;<br>
&gt; The system in question is meant to serve more than 1000 concurrent<br>
&gt; users, so we are in fact moving into this territory. We have been up to<br>
&gt; around 600 so far.<br>
&gt;<br>
&gt; &gt;- It is entirely possible that no one before you has ever tried to run<br>
&gt; &gt;a server application with the per-process file handle limit bumped up<br>
&gt; &gt;above the default 1024. So if that configuration does not play nicely<br>
&gt; &gt;with the select() mechanism, you may well be the first to have encountered<br>
&gt; &gt;this as an issue. But see above, don&#39;t fix it if it ain&#39;t broke.<br>
&gt;<br>
&gt; Well, it most probably *is* broke - I mean - I haven&#39;t read anywhere<br>
&gt; that our Socket code is limited to 1024 concurrent sockets and that<br>
&gt; going above that limit causes the Socket code to stop working? :)<br>
&gt;<br>
&gt; But I agree - I don&#39;t want to touch that code if we can simply avoid<br>
&gt; this bug by making sure we stay below 1024.<br>
&gt;<br>
&gt; But it sounds broke to me, nevertheless. ;)<br>
<br>
</div></div>Indeed it probably is.<br>
<span class=""><br>
&gt;<br>
&gt; &gt;- Most &quot;out of file descriptor&quot; problems involve resource leaks (as Eliot<br>
&gt; &gt;is suggesting), and in those cases you will see a gradual increase in file<br>
&gt; &gt;descriptors in /proc/&lt;vmpid&gt;/fd/ over time. Eventually you run out of<br>
&gt; &gt;descriptors and something horrible happens.<br>
&gt;<br>
&gt; We will start looking at that and other tools too.<br>
&gt;<br>
&gt;<br>
&gt; &gt;- Sorry to repeat myself but this is by far the most important point:<br>
&gt; &gt;DFtWP.<br>
&gt;<br>
&gt; Sure :). This is why I posted - to get your input. And I have a<br>
&gt; suspicion that the SAML issue I mentioned may be the code leaking, we<br>
&gt; will start looking.<br>
&gt;<br>
</span>&gt; regards, G?ran<br>
<br>
Cool. Please keep us posted on progress. In the unlikely event that free<br>
advice turns out to be worth anything, there is plenty more where that<br>
came from ;-)<br>
<br>
Dave<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">===========================================================================<br>John M. McIntosh &lt;<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>&gt; <a href="https://www.linkedin.com/in/smalltalk" target="_blank">https://www.linkedin.com/in/smalltalk</a><br>===========================================================================<br></div>
</div>