I believe this problem has been reported multiple times. Please open a
JIRA and apply the patch, it makes perfect sense.

/niklas

On Tue, Aug 4, 2009 at 10:02 PM, Sai
Pullabhotla<sai.pullabho...@jmethods.com> wrote:
> I've been noticing that the passive data connections are taking quite
> some time when using SSL. I finally got some time to look into this
> and noticed the following while debugging through the code. This issue
> might have been introduced with the fix we put in for FTPSERVER-241.
>
> The code that wraps the plain socket into an SSL socket uses the
> following line:
>
>                    SSLSocket sslSocket = (SSLSocket) ssocketFactory
>                            .createSocket(serverSocket,
> serverSocket.getInetAddress().getHostName(),
>                                    serverSocket.getPort(), true);
>
> Based on the JavaDocs, the InetAddress.getHostName() performs a
> reverse name look up, which was taking about 1.5 seconds on every
> system on our network. I'm not sure if this is an issue with the way
> our network is setup. Some one please let me know if this in fact an
> issue with our network.
>
> We are not seeing this lag when client and server are running on the
> same system. Things work too fast in this case, probably because the
> system knows very well about itself.
>
> Just to try it out, I changed the code to simply use the IP address
> rather than the host name, and I was able to get rid of the lag and
> things seem to be working much faster. Below is the change to the
> above line:
>
>                    SSLSocket sslSocket = (SSLSocket) ssocketFactory
>                            .createSocket(serverSocket,
> serverSocket.getInetAddress().getHostAddress(),
>                                    serverSocket.getPort(), true);
>
> Could some one test the current code base with client and server
> running on different systems and tell me if they notice the lag when
> creating the passive data connection. If this can be reproduced on one
> of your environments, we should probably put the above fix. I don't
> think this suggested fix should cause any other issues, do you?
>
> Regards,
>
> Sai Pullabhotla
> www.jMethods.com
>

Reply via email to