mina-ftpserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Latorre" <dvl...@gmail.com>
Subject Re: Active vs Passive performance
Date Sat, 08 Nov 2008 16:44:18 GMT
1.5 and 1.6 JREs and Windows Vista have had several issues and I guess there
are more to be fixed. (For instance, just this week I had to update to
1.6.0_7 in order to have Socket.getLocalAddress() return the correct IP
address - it didn't in 1.6.0_6)
I expected that 1.5.0_16 included all the available bugfixes. Otherwise,
they'll have to release  a new version, I hope that will be soon.

Taking this into account, are you using Vista in your "JRE 1.5 system" or
just in your  development machine? A five second delay between the PORT
command and the responde code is something much more people would have
noticed and I think it didn't happen with my Linux  server and JRE 1.5.0_15.
So it is quite possible that it is a Vista-only issue; my advice is (in case
your server is not  a Vista machine)   that you test this behaviour again in
your target OS.

As niklas said, probably there's little we can do here, but waiting for sun
to fix these issues.  Anyway let us know if you find a workaround! For data
connections we are not using MINA but regular synchronous sockets so the
code can be easily read or traced :)


2008/11/7 Niklas Gustavsson <niklas@protocol7.com>

> On Fri, Nov 7, 2008 at 4:16 PM, Steve Luebbe <sluebbe@linoma.com> wrote:
> > Well I have good and bad news to report.  The good news is that we found
> out
> > why the active connection speed is slower.  The bad news is that it
> relates
> > to the version of JRE you are running.
> > With 1.5.0_16 JRE:
> > 1) Active connections are extremely slow
> > 2) If you browse a remote site and keep changing directories over and
> over
> > (ls) it will actually stop responding after  20+ commands or so.
> >
> > With JRE 1.6.0_07 everything seems to be working fine.
> Oh, that likely means that there might be limited ways for us to fix
> this, but we might find a workaround. Let's keep the bug report open
> and we'll see if we can reproduce the problem.
> /niklas

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message