Bug 31744 - FTP subtasks should all share one connection
FTP subtasks should all share one connection
Status: NEW
Product: Ant
Classification: Unclassified
Component: Optional Tasks
1.1
All All
: P3 enhancement (vote)
: ---
Assigned To: Ant Notifications List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-10-16 12:55 UTC by rhino1
Modified: 2008-02-22 12:18 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rhino1 2004-10-16 12:55:45 UTC
I would like to see the FTP task use the same connection if the user is 
executing several subsequent FTP tasks that use the same server, userid and 
password. 

For example, in my current project, I have one FTP task to delete all existing 
files beneath a given directory, another FTP task to delete the (now empty) 
subdirectories beneath that same directory, five separate FTP tasks to create 
five new subdirectories, and five FTP tasks to populate each of those new 
subdirectories. Each of those tasks needs to connect and disconnect which adds 
substantially to the elapsed time for these tasks yet all of these tasks are 
operating against the exact same server with the same userid and password. If 
these tasks shared the same connection, it would save a lot of time.
Comment 1 Steve Cohen 2005-05-30 18:12:57 UTC
This is a very interesting suggestion and I am considering how best to implement it.

I have an idea.  I'd like some of the other ant developers to chime in on it.

Suppose we had an <ftp-connection> data type, with an id, etc.  Could we wrap
that around a jakarta-commons-net FTPClient object, and keep its connection
live?  Then we could refer to it via refid in subsequent invocations of the
<ftp> task within the same target.  Some care would have to be taken to insure
that the connection is closed within the target.

So ant-dev's please chime in here.  Is there any glaring flaw in this plan that
would cause it not to work?
Comment 2 Antoine Levy-Lambert 2005-05-30 19:34:36 UTC
Should work fine. :-)
Comment 3 J.M. (Martijn) Kruithof 2005-05-30 19:52:47 UTC
I'd in that case propose an ftp open and a close task, with the other ftp tasks
not closing the connection when an id is given.


Comment 4 Steve Cohen 2005-05-30 20:14:33 UTC
A better idea might be something like this:

<ftp user="me"
     password="mypassword"
     server="ftp.big.server"
     port="21"
     systemTypeKey="UNIX"
     serverTimeZone="Asia/Tokyo"

>
     <action name="mkdir" remotedir="public/private"/>
     <action name="put" remotedir="public/private" newer="true">
         <fileset dir="mylocaldir"/>
     </action> 
     <action name="get" .../>
</ftp>

This looks like a better plan.  Question now is how to do it and still preserve
backward compatibility.

Comment 5 Steve Cohen 2005-05-30 20:41:49 UTC
or better yet:

<ftp user="me"
     password="mypassword"
     server="ftp.big.server"
     port="21"
     systemTypeKey="UNIX"
     serverTimeZone="Asia/Tokyo"
>

     <mkdir remotedir="public/private"/>
     <put remotedir="public/private" newer="true">
         <fileset dir="mylocaldir"/>
     </put> 
     <get .../>
</ftp>
Comment 6 Matt Benson 2005-05-31 17:43:27 UTC
This would pretty nearly satisfy bug 33214 as well, wouldn't it?
Comment 7 Matt Benson 2005-05-31 17:49:01 UTC
of course, I didn't see any reason why the connection sharing would have to be 
all in one target.  It seems that you could attempt to close the connection 
during finalization (worst case).  Then the connection could be used across 
targets and the refid approach still has merit, with the nested action approach 
being an also-good-but-separate idea.
Comment 8 Peter Reilly 2005-05-31 17:58:46 UTC
Do not forget that the ant script may
be running in an IDE using one jvm - netbeans for example,
so the connection will need to be closed by hand.
The nested commands to the ftp task look nice.
Comment 9 Matt Benson 2005-05-31 20:14:25 UTC
(In reply to comment #8)
> Do not forget that the ant script may
> be running in an IDE using one jvm - netbeans for example,
> so the connection will need to be closed by hand.

I can't think of any other solution just now, but I still think it would be 
nice to orchestrate auto-closing of the connection per Ant "invocation" using 
task invalidation or some existing mechanism.  :(
Comment 10 Matt Benson 2005-05-31 20:20:56 UTC
Failing that I suppose we could recommend using a final target as in the posted 
solution to bug 17973.
Comment 11 Steve Cohen 2005-06-01 02:08:03 UTC
(In reply to comment #6)
> This would pretty nearly satisfy bug 33214 as well, wouldn't it?

Yes, I kind of had that in the back of my mind, too.