[
https://issues.apache.org/jira/browse/NET-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13560544#comment-13560544
]
Thomas Neidhart commented on NET-465:
-------------------------------------
The patch changed the default send/receive buffer size on the socket to 1024
which is pretty low considering the normal default, e.g. on my system
* sendBuffer: 131072
* receiveBuffer: 2097152
I can understand that the slow rates are due to starvation of the higher layers
based on constant buffer overruns of the underlying socket (and the involved
TCP overhead of throttling the datarate). I think the idea outlined by Bogdan,
to supply a custom SocketFactory would be a better solution than actually
adjusting the socket buffer size in a similar way than the internal buffer.
Another quick fix would be to not to adjust the socket buffers by default, only
when the user provides another buffer size. Right now, the socket buffers are
always adjusted (to the default, if there is no user-supplied value).
> FTPClient setSendBufferSize and setReceiveBufferSize on data socket
> -------------------------------------------------------------------
>
> Key: NET-465
> URL: https://issues.apache.org/jira/browse/NET-465
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.1
> Environment: All
> Reporter: Jim Kerwood
> Fix For: 3.2
>
> Attachments: ftp-bufsize.diff
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> When sending large files the need to set the send and receive buffer sizes on
> the data socket is much more important than the command socket. Please
> either give 2 more setters or make the setters set the data socket and leave
> the command socket alone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
