FTPClient Pool - Java

Question

I am writing a Rest service that connects to an FTP server to read some files, and then perform some operations on the read data to serve a service request. I use the generic Apache FTPClient domains.

As a workaround, I create an FTPClient object and then connect it and then log in with the credentials - inside the method (the client is local to this method - doing it like FTPClient not a thread safe) at my data access level, and then disable it before exiting the methods (i.e. after reading the file). The problem is that FTPClient takes about 3-7 seconds to log into the system, which is very much. Therefore, I am thinking of introducing FTPClientPool , which an already prepared client can provide in the data access method.

Already have these ClientPools?

If so, which one should I choose?

If not, complexity in implementation is once created and connected. How long does apache FTPClient expire? for infinite time ??? (I mean, by default, it saves time for FTPClient - idle time after which the client disconnects), because I see different times in java-documents. :() And the following questions: How do you always save it ?? (can it send NOOPS at regular intervals in a separate thread?) Any help on how I can move forward is really helpful.

Thanks and Regards

Answer 1

Client timeouts are typically server-side.

Here are some of the most obvious client options:

• soTimeout - Determines how long the client blocks waiting for a message. As a rule, you often poll the socket, and this determines how long you will wait during the polling.
• soLinger - determines how long the connection will be maintained after calling the close () function.

From my experience using FTP, they usually just reconnect if the connection closes - it’s usually not necessary to have a permanent continuous connection, unlike other applications.

What you use FTP for is usually not what is critical to the service ...

Answer 2

As for ClientPools , I had to write a demo project. commons-pool-ftp

I’m a little annoyed with the ftp protocol, in our experience, it will meet a broken pipe when testing on a client that simply receives from the pool.

testOnBorrow=true