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 <[email protected]> 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:[email protected]] > Sent: Wednesday, September 14, 2011 1:00 PM > To: [email protected] > 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 <[email protected]> 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
