Write your state to the IoSession and read it from the handler.
On Aug 1, 2013 10:06 PM, "Hunter McMillen" <mcmil...@gmail.com> wrote:
> 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. <sybersn...@gmail.com> 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" <mcmil...@gmail.com> 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 <mcmil...@gmail.com>
> >> 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
> >>>
> >
> >
>
>
