The major problem with any kind of ordering is the blocking and major
performance problems relative to the load.
On Aug 1, 2013 9:55 PM, "Ashish" <paliwalash...@gmail.com> 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
> > >
> > >
> >
>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal
>
