mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davis Ford <df...@axeda.com>
Subject RE: SFTP/SSHD passwordauthenticator test case
Date Wed, 14 Sep 2011 19:11:01 GMT
Hi Guillaume - indeed that fixes it.  It doesn't completely make sense to me why, since I am
not encountering port conflicts or socket binding errors.  So in a nutshell: if I do the following:

int port = 22;

SshServer ssh = new SshServer();
ssh.setPort(22);
// other setup
ssh.start();

// test cases
ssh.stop();

// new up different instance of server
ssh = new SshServer();
ssh.setPort(22);
// other setup
ssh.start();

// encounter stale object references trying to use the server here

...but if I alternatively do:

// new up different instance of server on different port
ssh = new SshServer();
ssh.setPort(22 + 1);
// other setup
ssh.start();

// tests run ok

I can only assume that some references are not gc'd or they are explicitly held until the
socket is officially closed and gc'd?  


-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com] 
Sent: Wednesday, September 14, 2011 3:01 PM
To: users@mina.apache.org
Subject: Re: SFTP/SSHD passwordauthenticator test case

I think the only reason why the behavior is weird is because you're creating
multiple servers on the same local port.  Would you use different ports, I
think everything would be ok.

On Wed, Sep 14, 2011 at 19:06, Davis Ford <dford@axeda.com> wrote:

> Hi Guillaume,
>
> That will fix it because @BeforeClass is a static method which forces the
> instance to be static which forces the map to be a singleton in the jvm and
> thus resolves the issue.
>
> The problem, though, is that newing up a new SshServer.java instance is not
> safe to do multiple times, which seems like a problem to me because some
> internal state there is either static or is not getting cleaned out and
> containing stale references to objects that should have since been cleaned
> up (i.e. PasswordAuthenticator instances).
>
> I stated in an earlier email that a hack-workaround for me is to make the
> private final ConcurrentMap instance static.  This indeed allows the test
> cases to pass, but it can have unwanted side-effects, and forces me to only
> have a single instance of the SftpServer running in any JVM unless I want to
> deal with this shared static map (which I don't).
>
> Maybe we see things differently, but it seems to me that the SshServer
> ought to be able to be new'd up and gc'd and new'd up again without side
> effects?
>
> Regards,
> Davis
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Wednesday, September 14, 2011 1:00 PM
> To: users@mina.apache.org
> Subject: Re: SFTP/SSHD passwordauthenticator test case
>
> I wonder if the problem is in your test which may create multiple
> SftpServer
> somehow ?
> Could you move the creation in the beforeClass method ?
>
> On Wed, Sep 14, 2011 at 18:29, Davis Ford <dford@axeda.com> wrote:
>
> >  Here's a follow up to my last email with a demo class / test case that
> > illustrates the failure.****
> >
> > ** **
> >
> > Add this code to the apache-sshd/sshd-core project under
> > src/test/java/com/example****
> >
> > ** **
> >
> > When you run the test the first case passes.  It spins up a new Sshd/SFTP
> > server and connects to it with the JSch client, and authenticates just
> fine
> > with the user/pass obtained via the ConcurrentHashMap.****
> >
> > ** **
> >
> > The second test case fails.  It tries to connect multiple sessions with
> > different user/pass combos.  You'll see the following printed on
> > system.err.println =>****
> >
> > ** **
> >
> > First, we create a new session for foo=bar:****
> >
> > CREATE-SESSION: SftpServer identity:1190000432, authMap
> identity:822056113,
> > authMap:{foo=bar}, user:foo, pass:bar****
> >
> > Then we authenticate -- works ok, you'll see foo=bar is in the map****
> >
> > AUTHENTICATE: SftpServer identity:1526115339, authMap identity:
> 2023306452,
> > authMap:{foo=bar}, user:foo, pass:bar****
> >
> > Now, we create a new session for foo2=bar2, note that it prints the
> > contents of the map after this call and it contains foo2=bar2****
> >
> > CREATE-SESSION: SftpServer identity:1190000432, authMap
> identity:822056113,
> > authMap:{foo2=bar2, foo=bar}, user:foo2, pass:bar2****
> >
> > Then we try to authenticate, but it fails.  foo2=bar2 is not in the map,
> > and the identity hashcode is different.****
> >
> > AUTHENTICATE: SftpServer identity:1526115339, authMap identity:
> 2023306452,
> > authMap:{foo=bar}, user:foo2, pass:bar2****
> >
> > ** **
> >
> > Note that the identity hashcodes change between calls to createSession( )
> > in the test, and authenticate( ) coming in from apache-sshd.  If you look
> at
> > the code, you'll see that I don't manipulate the ConcurrentMap anywhere
> in
> > the code or the test case other than adding an entry to it, and it is a
> > private final instance variable.****
> >
> > ** **
> >
> > So, why doesn't this work?  Something in the mina code is using a stale
> > instance of the SftpServer.java class it seems?****
> >
> > ** **
> >
> > Any ideas?****
> >
> > ** **
> >
> > Regards,
> > Davis****
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message