[Design of Messaging on JBoss (Messaging/JBoss)] - Mina client/server session id's
by ataylor
I 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153748#4153748
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153748
17 years, 10 months
[Design of JBoss Web Services] - Re: [JBWS-2187] javax.xml.ws.Service handlers and thread saf
by alessio.soldano＠jboss.com
I've spent some time on this and I think we should discuss something more before actually modifying the code.
My opinion on JBWS-2187 is the following:
Handlers added multiple times
An easy fix for this could of course be to force the HandlerResolverImpl to clear its handler map when the proxy is being created; this could be done, as suggested, calling initBindingHanlderChain(true) from the ClientImpl. However I think the fact that handlers are added multiple time is just a piece of a more general issue which is that config-file and config-name should not be meant as port configurations (at least imho). As a matter of fact, you end up modifying the metadata when setting those parameters and of course metadata are scoped to the service. It's not only a matter of handlers already set up, the config name too, for example, is already set to "Standard WS Security Client" when the second port is created in the described scenario, before the setConfigName method is invoked.
Btw clients are nevertheless allowed to change handlers for a given port through the binding and that should not affect port being created later, thus this is a config file/name setup issue only.
Thread safety
The concern here is that multiple thread using their own port instances could concurrently access the handler's map in the HandlerResolver, right? We can think about technical means of preventing problems in those scenarios, but AFAIK the handler resolver is meant to be scoped to the Service and we can't change that. And again I can see this threading issue only when changing the config-file/name, changing the handler chain from client side through port.getBinding().setHandlerChain(...) is an harmless operation.
What do you think about this?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153741#4153741
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153741
17 years, 10 months
[Design of JBoss ESB] - Re: ESB vs. SOAP community
by mark.little＠jboss.com
Owing to other work commitments I'm a little late to this, but thought I'd add some comments anyway ...
"thomas.diesler(a)jboss.com" wrote : anonymous wrote :
| | There is no such thing as JBossSOA
| |
|
| Exactly - and my point is that there should be a JBossSOA project that has a binary dependency on JBossESB like on any other project that goes into the SOA-P.
|
So there's a JBossEAP project somewhere that I don't know about ;-) ?
anonymous wrote :
| The benefit is, that JBossESB can have a different lifecycle than JBossSOA,
|
It already does, in the same way all of the projects do. There is no benefit of adding yet another project that simply pulls together what the ESB is already pulling together.
anonymous wrote :
| With the current approach JBossESB determines the release cycle, which may be slower than what our community expects of JBossSOA.
|
Actually the way it is at the moment the SOA-P and ESB are in lock-step precisely because of community and customer requirements! Were that to change then it would be in the same way as we see for all of the other projects.
anonymous wrote :
| For example we cannot update JBossWS before JBossESB is ready for the next release.
|
No, we cannot update JBossWS because we pull it in from EAP. Good project (JBossWS) to mention, but completely wrong target (JBossESB) to fire at!
anonymous wrote :
| Additionally, all folks that are currently involved in the various SOA projects should become members of JBossSOA. This is important to improve project integration.
|
| Thirdly, the JBossESB project should only be concerned with ESB aspects and not try to act as an umbrella project, which it is not.
|
The ESB is being precisely what it is meant to be: a glue (and umbrella to some extent). The ESB is our SOA Infrastructure. It is JBossSOA. You want to have two names for the exact same project?
anonymous wrote :
| Forthly, component updates and SSO should not be a property of the SOA-P they should be available to the community, develeoped and QAed in JBossSOA. Productisaztion should be the only concern of the SOA-P
|
Wrong target again. As Kevin already pointed out, SSO is not happening within SOA-P or ESB! It's a company wide effort.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153731#4153731
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153731
17 years, 10 months