<HTML>
<HEAD>
<TITLE>Re: [ftputil] How to correctlry close a ftp connection</TITLE>
</HEAD>
<BODY>
<FONT SIZE="4"><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>On 12/15/08 12:28 PM, "Yvan Strahm" <yvan.strahm@gmail.com> wrote:<BR>
<BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>On Sun, Dec 14, 2008 at 10:48 AM, Stefan Schwarzer <sschwarzer@sschwarzer.net> wrote:<BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hello,<BR>
<BR>
On 2008-12-12 14:47, Stefan Schwarzer wrote:<BR>
> Regarding the symmetry of the FTPHost construction and calling<BR>
> the close method, at first sight this looks well. However, if the<BR>
> constructor fails, the close method won't be called, so that may<BR>
> be the reason why you exhaust the possible number of connections.<BR>
<BR>
It seems I was a bit hasty here. If the _constructor_ fails, the<BR>
connection wouldn't have been established in the first place, so<BR>
it's not necessary to close it. "Closing" a connection which<BR>
actually isn't there may rather cause an exception _in the<BR>
"close" call_.<BR>
<BR>
More important, thus, usually are exceptions which happen after<BR>
the construction.<BR>
<BR>
> I think you should use a try ... finally construct:<BR>
><BR>
> try:<BR>
> print "CONNECTING TO "+ ftp + ftp_dir+file+"\n"<BR>
> host=ftputil.FTPHost(ftp,user,password)<BR>
> try:<BR>
<BR>
That's why the "try" comes _after_ calling the constructor. If<BR>
the connection wasn't opened, it doesn't need to be closed.<BR>
<BR>
It's similar in the Python idiom<BR>
<BR>
fobj = open(...)<BR>
try:<BR>
...<BR>
finally:<BR>
fobj.close()<BR>
<BR>
> host.chdir(ftp_dir+file)<BR>
> names=host.listdir(host.curdir)<BR>
> for name in names:<BR>
> if host.path.isfile(name):<BR>
> p="pep"<BR>
> m_pep=re.search(p,name)<BR>
> if m_pep:<BR>
> returned=name<BR>
> host.download_if_newer(name,target,'b')<BR>
<BR>
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'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>
> finally:<BR>
> host.close()<BR>
> except:<BR>
> ...<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>
<BR>
Best regards,<BR>
Stefan<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
Hello Stefan,<BR>
<BR>
Thanks! the nested try:try:finally:except is doing the trick. I didn't count how many time in my original script the first try was " tried " without success 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>
<BR>
<BR>
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE="4"><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I haven’t looked into this yet, but this looks like you could use the with syntax if you’ve got the right version of python, basically it would do most of the work of the try catch blocks and it looks a little cleaner.<BR>
<BR>
-Richard</SPAN></FONT></FONT>
</BODY>
</HTML>