mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert.j.gr...@jpmorgan.com
Subject Re: Thread Model
Date Tue, 07 Mar 2006 15:21:09 GMT
We have done something similar, where we delegate all relevant events to a
session-aware handler. Our session aware handler implements the state
machine required for our protocol.

This is probably part of the solution required DIRMINA-160 (higher level
state machines) - you could have a "StateAwareIoHandler" that perhaps had
some generic support for state machines.


|         |           Niklas Therning  |
|         |           <niklas@trillian.|
|         |           se>              |
|         |                            |
|         |           07/03/2006 14:59 |
|         |           Please respond to|
|         |           mina-dev         |
|         |                            |
  |       To:       mina-dev@directory.apache.org                                        
  |       cc:                                                                            
  |       Subject:  Re: Thread Model                                                     

peter royal wrote:

>> Yes, I didn't think about that possibility. But why not have
>> something like the following:
>>   IoAcceptor acceptor = ...;
>>   IoHandlerFactory factory = ...;
>>   acceptor.accept(address, factory);
>> where IoHandlerFactory is an interface that has the responsibility  to
>> create IoHandlers. This factory would be used by the acceptor to
>> create an IoHandler whenever a new session is accepted.
>> This way, both the client-side and server-side IoHandler could  safely
>> use state in instance variables. This seems more consistent  to me.
> I guess it just depends on what is the more common case. In my
> experience, I have no problems with everything flowing into a single
> IoHandler on the server side. So I would want an IoHandlerFactory  that
> just returned the same instance each time. Whichever way it is
> implemented, I think it would be a valuable contribution to MINA.
> -pete

If the handler is per session there's no need to pass in the session in
all methods, is it? IMO it would be nicer to have a new interface:

interface SingleSessionIoHandler {
   void sessionOpened();
   void messageReceived(Object message);
   void sessionClosed();

implementation of this interface would typically store the session as an
instance variable.

The factory interface would look like:

interface SingleSessionIoHandlerFactory {
   SingleSessionIoHandler create(IoSession session);

To achieve this in MINA you could implement a special IoHandler which
delegates to a SingleSessionIoHandler which it gets from the session:

public class SingleSessionIoHandlerDelegate implements IoHandler {
   SingleSessionIoHandlerFactory factory;
   SingleSessionIoHandlerDelegate(SingleSessionIoHandlerFactory factory){
     this.factory = factory;
   void sessionCreated(IoSession session) {
     SingleSessionIoHandler handler = factory.create(session);
     session.setAttribute("handler", handler);
   void sessionOpened(IoSession session) {
     SingleSessionIoHandler handler = session.getAttribute("handler");
   void messageReceived(IoSession session, Object message) {
     SingleSessionIoHandler handler = session.getAttribute("handler");

To create an acceptor you would simply do:

IoAcceptor acceptor = ...;
SingleSessionIoHandlerFactory  factory = ...;
acceptor.accept(address, new SingleSessionIoHandlerDelegate(factory));

My point is that there's no need to modify the IoAcceptor interface to
support this kind of behaviour. I see no harm in including something
like this in MINA. Simon, if you have a patch please add it to JIRA and
we'll consider it.


This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein 
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries 
and affiliates.

View raw message