[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] slowness+ ftp timeouts with 0.4.3-rc1

From: Nicolas Aspert
Subject: Re: [Duplicity-talk] slowness+ ftp timeouts with 0.4.3-rc1
Date: Thu, 31 May 2007 13:36:49 +0200
User-agent: Thunderbird (Windows/20070326)

dAniel hAhler wrote:

> Yes, it looks like it from the exception you're getting:
> Catched exception duplicity.ftplib.error_temp: 421 No Transfer Timeout
> Do these exceptions still occur with the patch from Kenneth? But they
> get handled better?

The exceptions still occur but are handled better (and faster FWIW ;)

> AFAICS your problem (and another one I'm experiencing), was caused by
> the following change in my original ftpBackend patch:
>     try:
> -                if self.is_connected:
> +                if not self.is_connected:
>                         self.connect()
>                return ftplib.FTP.__dict__[command](self.ftp, *args)
> The intention had been to re-connect, if we're supposed to be
> connected (e.g. we do not want to re-connect when the CONNECT call
> failed itself).
> The only problem with this seemed to be that previous connections
> where not closed.

Something like this yes... I am still a bit puzzled about *why* do I
even see those timeouts. It means the ftp connection remains inactive
for too long. Is it that performing a daily incremental backup on a
farily large amount (~150GB) of data sends relatively few data, whereas
processing the whole folders takes much longer than data processing itself ?
If yes, it might be interesting to try to have a slightly better
strategy for ftp connection (maybe it doesn't need to stay established
for that long if it is useless...). Just my .02$ as I don't have time to
do this (+ my python is not so good ;)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]