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 >