On Sun, Aug 9, 2009 at 8:10 PM, Sai
Pullabhotla wrote:
> I did notice anywhere from 20 to 50 milliseconds improvement for each
> data connection creation. The fix is checked in now to the trunk.
Great work, thanks!
/niklas
I did notice anywhere from 20 to 50 milliseconds improvement for each
data connection creation. The fix is checked in now to the trunk.
Regards,
Sai Pullabhotla
www.jMethods.com
On Wed, Aug 5, 2009 at 3:15 PM, Niklas Gustavsson wrote:
> On Wed, Aug 5, 2009 at 10:01 PM, Sai
> Pullabhotla wrote:
On Wed, Aug 5, 2009 at 10:01 PM, Sai
Pullabhotla wrote:
[snip]
> I know we may not notice much time difference with this change, but
> every little things add up, especially under high loads.
Did you see any performance improvements in your local copy? Anyways,
I think this makes sense, again for
On Wed, Aug 5, 2009 at 5:05 PM, Sai
Pullabhotla wrote:
> I'm not sure, I think it should go to the main trunk as well.
Trunk is 1.1.X so we're saying the same thing :-). I don't think it
should go into 1.0.x.
/niklas
I'm also wondering if we could perform better with SSL, if we cache
the SSLContext and SSLSocketFactory. Currently, every data connection
creates the SSLContext (even though the context parameters are the
same) and gets the SocketFacotry from the context. Instead, we should
create the SSLContext an
I'm not sure, I think it should go to the main trunk as well.
Sai Pullabhotla
www.jMethods.com
On Wed, Aug 5, 2009 at 9:31 AM, Niklas Gustavsson wrote:
> On Wed, Aug 5, 2009 at 2:41 PM, Sai
> Pullabhotla wrote:
>> I also have another question around the same code...Should we be
>> checking the
On Wed, Aug 5, 2009 at 2:41 PM, Sai
Pullabhotla wrote:
> I also have another question around the same code...Should we be
> checking the remote address and make sure it matches with the IP
> address of the remote host on the control connection. If we do not do
> this check, it is possible for a hac
Okay, done!
I also have another question around the same code...Should we be
checking the remote address and make sure it matches with the IP
address of the remote host on the control connection. If we do not do
this check, it is possible for a hacker to connect to this port before
the original cl
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 wrote:
> I've been noticing that the passive data connections are taking quite
> some time when using SSL. I finally go
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
10 matches
Mail list logo
