Ok I think I understand the ordering now, we probably don't need an Executor. Our main issue is still how to link the state machine with our IoHandlerAdaptor.
As of right now, after a user is authenticated (by the statemachine), the sessionIdle() event of the statemachine calls sessionOpened of our IoHandlerAdapter; obviously this is a logic error because sessionIdle() will fire frequently. So two things: 1) Is there a way to leave the statemachine after we authenticate someone? 2) If not, how to map the finishing of authentication to our IoHandlerAdapter ,specifically we probably don't want to fire a sessionCreated() event (because a session was already created by the statemachine), we simply want to pass that to our handler. Thanks. Hunter On 8/1/13 9:54 PM, Ashish wrote: > On Fri, Aug 2, 2013 at 7:15 AM, Jon V. <[email protected]> wrote: > >> To my knowledge the executor filter does not guarantee any kind of order. >> This means that you should implement the authentication phase before the >> executor. >> > This is correct, with Executor filter ordering is not guaranteed. Do you > need an executor filter there? > It's usage is recommended if you have some intensive task in chain or in > IoHandler. > > >> Io->prorocol->authentication->executor->handler >> > This sound good. Alternative is to use OrderedThreadPoolExecutor, but go > simple first. > Implement stuff without Executor filter and then push that in if needed. > > >> You cannot lock on out of order messaging without a queue and attempt to >> re-order the messages. >> On Aug 1, 2013 9:33 PM, "Hunter McMillen" <[email protected]> wrote: >> >>> Sorry, the code is probably more useful to see, here is the entry point >>> to our application: >>> >>> acceptor = new NioSocketAcceptor( >>> Runtime.getRuntime().availableProcessors() ); >>> acceptor.getFilterChain().addLast("executor", new >>> ExecutorFilter( Executors.newCachedThreadPool())); >>> acceptor.getFilterChain().addLast("logger", >>> MudConfig.Logging.getFilter()); >>> acceptor.getFilterChain().addLast("codec", >>> new ProtocolCodecFilter( >>> new TextLineEncoder(), new CommandDecoder() >>> ) >>> ); >>> >>> More importantly, my main question is how I can link the DONE state of >>> the state machine (AuthenticationHandler) and the IoHandlerAdapter. I >>> can post the code for these also, I just didn't want to overload the >>> thread. >>> >>> Thanks. >>> Hunter >>> On 8/1/13 5:47 PM, Jon wrote: >>>> You are not using an executor filter right? You have to implement >>> locking during the authentication phase if you are using thread >> scheduling. >>>> Sent from my iPhone >>>> >>>> On Aug 1, 2013, at 5:31 PM, Hunter McMillen <[email protected]> >> wrote: >>>>> Hello, >>>>> >>>>> I recently started working on a project with a friend that is a >>> text-based game. We were having trouble with ReadFuture's when trying to >>> get a username/password combination from the user so we decided to follow >>> the state machine example from Tapedeck TCP server on Mina's homepage: >>> >> http://mina.apache.org/mina-project/xref/org/apache/mina/example/tapedeck/ >>>>> I have gotten the state machine to a point where it seems to be >> working >>> well. It starts, reads a username, then a password, then has some logic >> to >>> restart based on error; or it prints a message 'Authenticated'. >>>>> However our main application logic is going to be (our plan at least) >>> held in an IoHandlerAdapter, my question is what is a good way to >> integrate >>> the two of these: >>>>> 1) The state machine authentication filter from the example above >>>>> 2) An IoHandlerAdapter that will track information about connected >>> users and sessions >>>>> My confusion mainly lies in how to transition between the state >> machine >>> and the IoHandlerAdapter since they both respond to /sessionCreated /and >>> /sessionOpened /events. >>>>> Any help, ideas, or input would be appreciated. >>>>> >>>>> Thanks. >>>>> Hunter >>> > >
