Mina client/server session id's
ataylor May 27, 2008 2:11 PMI have a slight problem with the way we use the mina session id's.
currently when a connection is created in MessagingServerImpl we use the client session id to register it with the ConnectionManager. i.e.
public CreateConnectionResponse createConnection(final String username, final String password, final long remotingClientSessionID, final String clientAddress, final int incrementVersion, final PacketReturner sender) throws Exception { log.trace("creating a new connection for user " + username); if(version.getIncrementingVersion() < incrementVersion) { throw new MessagingException(MessagingException.INCOMPATIBLE_CLIENT_SERVER_VERSIONS, "client not compatible with version: " + version.getFullVersion()); } // Authenticate. Successful autentication will place a new SubjectContext on thread local, // which will be used in the authorization process. However, we need to make sure we clean // up thread local immediately after we used the information, otherwise some other people // security my be screwed up, on account of thread local security stack being corrupted. securityStore.authenticate(username, password); long id = remotingService.getDispatcher().generateID(); final ServerConnection connection = new ServerConnectionImpl(id, username, password, remotingClientSessionID, clientAddress, remotingService.getDispatcher(), resourceManager, storageManager, queueSettingsRepository, postOffice, securityStore, connectionManager); remotingService.getDispatcher().register(new ServerConnectionPacketHandler(connection)); return new CreateConnectionResponse(connection.getID(), version); }
The problem is when we try to clean up connections using the MinaSessionListener the session that is passed to the public void sessionDestroyed(IoSession session) method is the session on the server side.
This can easily be fixed by using the serversession id like this:
final ServerConnection connection = new ServerConnectionImpl(id, username, password, sender.getSessionID(), clientAddress, remotingService.getDispatcher(), resourceManager, storageManager, queueSettingsRepository, postOffice, securityStore, connectionManager);
however this still means that on the client side any connection exceptions thrown will still be using the client session id. At the minute this isn't a problem as it only used by the client side exception listeners but it may further on.