Get the Service from which a connection is accepted

• Key: DIRMINA-116
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Trustin Lee
• Reporter: Paolo Perrucci
• Affects Version/s: 0.8.0
• Fix Version/s: 0.9.0

Description

When a new connection is accepted may be usefull to know the related Service.

Comments

[Greg Bodi]

Agreed. For an application I'm prototyping, MINA works very well right up until I have to take action on a received message (ProtocolHandler.messageReceived()). At that point, I have to decide how to process the message, and for that I need access to some configuration (which is available at service creation time). It struck me that if ProtocolHandler had some sort of getService() method, I could subclass Service to insert the required config fields, and do something like this:

Service service = new MyConfigurableService(protocol, TransportType.SOCKET, port, myConfigObject);
registry.bind(service, provider);

[Trustin Lee]

What about this way?

public void sessionOpened( IoSession session ) throws Exception {

    Service service = ( Service ) session.getAttribute( ServiceRegistry.SERVICE );
    ...
}

[Greg Bodi]

Yes, putting it as a session attribute would accomplish the same thing. However, would it then be possible to expose IoProtocolSession.getIoSession() up to the IoSession interface so that I could still access it from a ProtocolHandler? i.e.:

public void messageReceived(ProtocolSession session, Object message) throws Exception
{
  ...
  Service service = (Service)session.getIoSession().getAttribute(ServiceRegistry.SERVICE);
  ...
}

Or, would it safe enough to try to cast down (i.e., make an assumption that's it not a VmPipeSession)?

public void messageReceived(ProtocolSession session, Object message) throws Exception
{
  // not pretty, but fine if it works
  Service service=(Service)((IoProtocolSession)session).getIoSession().getAttribute(ServiceRegistry.SERVICE);
  ...
}

Or maybe is this somehow possible via another mechanism I overlooked? Thanks!

[Trustin Lee]

First, 0.8 is already a stable release, so we cannot add new feature to 0.8 branch. We'll add this feature to 0.9.0.
And the two examples you've mentioned above are identical because attributes are shared. :)

HTH,
Trustin

[Greg Bodi]

Re: 0.8.... of course, my apologies, I assumed it was implied I was referring to the next release.

And yes, I guess I did overlook something... namely, that the getAttribute call is just delegated to to the IoSession anyway. :-)

With that in place though, I think MINA is really going to work for us.

Thanks again,
Greg

[dave irving]

I dont mind taking this one on if its not being done already?
Looks fairly simple - here's roughly what I think we could do:

- Change the IoAcceptor interface such that we bind a Service rather than an address
- In SocketAcceptorDelegate, we add the Service to the RegistrationRequest
- When we create a new Session in SocketAcceptorDelegate.Worker#processSessions, we set the Service attachment to the session.

I'll need to look at the other IoAcceptor implementations as wel.

Should be able to do this today, or early tomorrow.

WDYT?

[dave irving]

I'll also have to see how it fits in with the Spring integration too....

[Trustin Lee]

Actually ServiceRegistry is designed to be a frontend to IoAcceptors. Merging them is an attractive idea, but I don't see much benefit here yet. We could implement this as a filter which is an inner class of SimpleServiceRegistry. The filter could look up the internal registry information and call setAttribute() to set an appropriate service, in sessionCreated().

[Trustin Lee]

It seems like Niklas's patch doesn't include the integration for the 'registry' package.

[dave irving]

> We could implement this as a filter which is an inner class of SimpleServiceRegistry

Cool - sounds good.
I'll take a look in to that approach

If we do this as an IoFilter private to SimpleServiceRegistry, then the only way I can see to tie the created session back to its Service is the local socket address.
However, I dont think this is all that easy: The sessions local socket address is given by the socket itself, but it's most likely that the acceptor bind address is just a wildcard address on some port.
These wont be concidered equal - so a simple map approach wont work. We'd have to do some custom processing - which could lead to a performance hit on connection churn.

Have I missed something maybe?

[Trustin Lee]

I see... so we need to add a different filter per different service. (We could pass a parameter when we create an instance of the filter.) To do this, we need to resolve DIRMINA-121 first unfortunately.

[Trustin Lee]

From MINA 0.9, you can get the Service instance associated with the session like this:

public void messageReceived(IoSession session, Object message) throws Exception
{
  ...
  Service service = (Service) session.getAttribute( ServiceRegistry.SERVICE );
  ...
}

This feature will not be included in 0.8 stream. Please review the fix and close this issue.