On Sun, Dec 14, 2008 at 10:48 AM, Stefan Schwarzer <span dir="ltr">&lt;<a href="mailto:sschwarzer@sschwarzer.net">sschwarzer@sschwarzer.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<div class="Ih2E3d"><br>
On 2008-12-12 14:47, Stefan Schwarzer wrote:<br>
&gt; Regarding the symmetry of the FTPHost construction and calling<br>
&gt; the close method, at first sight this looks well. However, if the<br>
&gt; constructor fails, the close method won&#39;t be called, so that may<br>
&gt; be the reason why you exhaust the possible number of connections.<br>
<br>
</div>It seems I was a bit hasty here. If the _constructor_ fails, the<br>
connection wouldn&#39;t have been established in the first place, so<br>
it&#39;s not necessary to close it. &quot;Closing&quot; a connection which<br>
actually isn&#39;t there may rather cause an exception _in the<br>
&quot;close&quot; call_.<br>
<br>
More important, thus, usually are exceptions which happen after<br>
the construction.<br>
<div class="Ih2E3d"><br>
&gt; I think you should use a try ... finally construct:<br>
&gt;<br>
&gt; try:<br>
&gt; &nbsp; &nbsp; print &quot;CONNECTING TO &quot;+ ftp + ftp_dir+file+&quot;\n&quot;<br>
&gt; &nbsp; &nbsp; host=ftputil.FTPHost(ftp,user,password)<br>
&gt; &nbsp; &nbsp; try:<br>
<br>
</div>That&#39;s why the &quot;try&quot; comes _after_ calling the constructor. If<br>
the connection wasn&#39;t opened, it doesn&#39;t need to be closed.<br>
<br>
It&#39;s similar in the Python idiom<br>
<br>
fobj = open(...)<br>
try:<br>
 &nbsp; &nbsp;...<br>
finally:<br>
 &nbsp; &nbsp;fobj.close()<br>
<div class="Ih2E3d"><br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; host.chdir(ftp_dir+file)<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; names=host.listdir(host.curdir)<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; for name in names:<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if host.path.isfile(name):<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; p=&quot;pep&quot;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; m_pep=re.search(p,name)<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if m_pep:<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; returned=name<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; host.download_if_newer(name,target,&#39;b&#39;)<br>
<br>
</div>Besides: Behind the scenes download_if_newer opens a new<br>
connection to the FTP server in order to make a file object. So<br>
not only explicit constructor calls generate connections. (There<br>
shouldn&#39;t be connection leaks because of that because unused file<br>
objects are reused, and they are closed when the FTPHost object<br>
is closed.)<br>
<br>
&gt; &nbsp; &nbsp; finally:<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; host.close()<br>
&gt; except:<br>
&gt; &nbsp; &nbsp; ...<br>
<br>
The curious thing is that your problem comes from the code which<br>
is executed _before_ you call the constructor that fails with an<br>
exception. :-)<br>
<div><div></div><div class="Wj3C7c"><br>
Best regards,<br>
Stefan</div></div></blockquote><div><br>Hello Stefan,<br>
<br>
Thanks! the nested try:try:finally:except is doing the trick. I didn&#39;t count how many time in my original script the first try was &quot; tried &quot; without success&nbsp; but I suspect that this was the cause of all these not closed connection, as you pointed out in your first reply.<br>
<br>Thanks a lot for your help<br>Best regards<br>yvan<br>&nbsp;<br></div></div><br>