Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-ID: <00e701c0c2a2$05ed6b70$f8f20e0f@c325042a>
From: "Steve Loughran" <steve_l@iseran.com>
To: <ant-dev@jakarta.apache.org>
References: <20010411131408.7364.qmail@web9306.mail.yahoo.com>
Subject: Re: FTP & Directories
Date: Wed, 11 Apr 2001 09:11:07 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Roger Vaughn" <rogervaughn@yahoo.com>
To: <ant-dev@jakarta.apache.org>
Sent: Wednesday, April 11, 2001 6:14 AM
Subject: Re: FTP & Directories


>
> --- Steve Loughran <steve_l@iseran.com> wrote:
> >
> > Incidentally, does anyone know why the ftp task is
> > so slow?
> >
>
> The FTP task relies exclusively on Daniel Savarese's
> NetComponents for actually handling the FTP protocol
> and transfers.  There's not terribly much in the FTP
> task itself except directory handling, so I'd have to
> suspect NetComponents, though it will be hard to say
> what's actually happening until Jakarta gets their
> hands on this code.  (Is this going to happen one of
> these days?)
>
> If anyone knows of a faster open source FTP library,
> I'm sure we switch it in.

I could see the performance issues werent in the task, and not having seen
the library source dont know where to begin there. To speed up bulk IO the
obvious tactic would be to split file IO and net IO into two threads with a
shared memory queue between them, so everything would go in parallel. But I
would have expected the OS to have done lookahead on a sequential read
process and buffering on writes anyway.

Whatever, without the source it remains as it is.

-steve