The filter approach has several problems.

1) you would be re-registering your IoAcceptor multiple times un-necessarily.
2) If you hadn't received any requests on an IoAcceptor it wouldn't be 
registered for shutdown.

A better approach would be to use an observer pattern.  
http://en.wikipedia.org/wiki/Observer_pattern
Wrap your IoAcceptor and Executor filters in another object that implements a 
simple interface:

public interface Shutdown {

    public void shutdown();

}

Then in your handler you have a register method that accepts shutdown 
implementations:

public void register(Shutdown s);
public void unregister(Shutdown s);

Also, your shutdown executor should use a daemon thread or your JVM will never 
exit.

Rob

----- Original Message ----
From: threadMaven <[EMAIL PROTECTED]>
To: dev@mina.apache.org
Sent: Wednesday, September 5, 2007 1:00:03 PM
Subject: Serverside shutdown


Hey all, 
I thought I would re-post this question again, seeing that I have now gone
deeper into it and can explain myself a little better.^--^
so here we go.....
The code below is an extension of the TimeServer example in the
documentation. I've simply  mashed it with the 
"Configuring Thread Model tutorial" also provided in the documentation. Now,
it simply has a number of threads behind it serving up the original date
string.  The snippet below is the gist of it....
        
        //// create thread pool
        executor =
Executors.newCachedThreadPool(Executors.defaultThreadFactory());
        
        //// create my acceptor and associate the executor with it
        acceptor = new
SocketAcceptor(Runtime.getRuntime().availableProcessors() + 1, executor);
        
        //// as per recommended mode of operation....
        IoServiceConfig acceptorConfig = acceptor.getDefaultConfig();
        acceptorConfig.setThreadModel(ThreadModel.MANUAL); 
        //// let's configure our filter chain
        SocketAcceptorConfig cfg = new SocketAcceptorConfig();
        cfg.getSessionConfig().setReuseAddress( true );
        //// a logging filter
        cfg.getFilterChain().addLast( "logger", new LoggingFilter() );
        //// a simple text codec
        cfg.getFilterChain().addLast( "codec", new ProtocolCodecFilter( new
TextLineCodecFactory( Charset.forName( "UTF-8" ))));
       
///////////////////////////////////////////////////////////////////////////////////////////
        //// lastly I add in my thread pool.
       
///////////////////////////////////////////////////////////////////////////////////////////
        cfg.getFilterChain().addLast("threadPool", new
ExecutorFilter(executor));
        
        try {
        //// create the socket object
        iSA = new InetSocketAddress(InetAddress.getByName("localhost"), 9110);
       
////////////////////////////////////////////////////////////////////////////////////////
        //// create my handler which casts each msg in 
        ////             messageReceived(IoSession session, Object msg)
        //// to a String then looks for "quit", if so it
        //// closes the "session".... exactly as the example does. 
       
////////////////////////////////////////////////////////////////////////////////////////
        TimeIOHandler tioh = new TimeIOHandler();
            ////  turn over the server.
        System.out.println("Server is binding, waiting for connections");
        acceptor.bind(iSA, tioh, cfg);
    } catch (UnknownHostException e) {
            .
            .etc
            .etc
            .etc
            
            
            
Now let's suppose that my TimeIOHandler class can detect the presence of a
command whose intent is to
effectively shutdown my server process, i.e. culminating with
anacceptor.unbind() and executor.shutdown().

So after much ado, my question: how can that detecting session thread get a
handle back to the acceptor and 
executor object to call the unbind() and shutdown() methods respectively.

A credible approach, IMHO:), would be creating a filter, executed before the
"threadPool" task, and using that to detect the "quitServer" command but
even then I don't know how to "get back to" the acceptor and/or executor
objects????

help?!

Tm
            
-- 
View this message in context: 
http://www.nabble.com/Serverside-shutdown-tf4386708s16868.html#a12506470
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.






       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. 
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

Reply via email to