cidny SessionDispatcher

 

SessionDispatcher

Jerry来信问了一些有关SessionDispatcher的问题，在征得其同意后，将来信和回信贴在这里，希望能给大家一些帮助。

 

来信

 

你好，看了你的cindy觉得很有意思，看到他一直在进步，也很让人高兴。

看了新出的cindy3.0a2里面的代码，和3.0a1做了一下比较，发现了一些不同，所以想请教一下你的想法

你的SessionDispatcher里面启动的是只有一个线程的线程池，很想了解这里能把线程池中的线程数目调大吗？

从我的理解应该是可以的，这样就形成了处理NIO常用的1-N的线程模型，不知道理解是否有误？
在Cindy3.0a1的HSHAReactor的start方法里面有如下的代码

private synchronized void start() {
        if (selectThread != null)
            return;

        int minPool = CindyConstants.getMinThreadPoolSize();
        int maxPool = CindyConstants.getMaxThreadPoolSize();
        // keep event dispatched in order
        if (minPool == 0 && maxPool == 0)
            dispatcher = new DirectExecutor();
        else
         //Start a seperate dispatcher thread, maybe this will become a
thread pool.
            dispatcher = Executors.newSingleThreadExecutor(threadFactory);
        lastSelectTime = new ElapsedTime();

这个dispatcher处理的都是selector相关的东西。但是在Cindy3.0a2里面这部分代码去掉了，是发现了什么线程问题吗？

3.0a1和a2的start方法上都有个synchronized关键字，里面启动了一个线程。

这样的话，在这个内部线程死掉之前，这个方法是不能被别的线程访问的，对吗？觉得这样的处理方法很tricky，呵呵。

请不吝赐教，谢谢！:)

回信

 

Jerry,

 很高兴你对该项目抱有浓厚的兴趣，这里就你提出的问题做一些交流。

1.SessionDispatcher线程数的调节

SessionDispatcher的存在的目的并不是为了效率以及可扩展性，它存在的目的仅仅是为了保证结果的正确性，所以线程数没有调大的必要。

 

Cindy中同时存在着同步方法和异步方法。异步的比如Listener、Filter一系列机制都是用于处理异步情况的，在相应的事件完成后再通知应用；同步的比如Future.complete()，会在该任务完成后才从该方法中返回。

 

这里就牵涉到的问题就是：因为核心是异步的，如果应用在核心线程中调用了同步方法，则该同步方法将永远无法完成。

 

所以SessionDispatcher的作用就是使得真正的核心线程永远也到达不了应用层，所有应用层的事件都是由 SessionDispatcher中的线程来发送。同时，为了保证同步方法不阻塞SessionDispatcher，一旦应用层调用了同步方 法，SessionDispatcher就会通过内置的线程池来选择另一个线程发送消息。

 

举个例子。比如同时开启了10个Session，其中一个Session在sessionStarted事件中进行数据发送，并调用了Future.complete方法。

 session.addSessionHandler(new SessionHandlerAdapter() {
  public void sessionStarted(...) {
   session.send(someObj).complete();
  }
 });

 

如果是核心线程进行事件的发送。那么调用complete后，这时并没有开始发送，所以线程被阻塞；并且由于核心线程被阻塞，真正的网络操作将永远无法执行，只能被一直阻塞。

 

如果只是单线程进行事件发送。那么调用complete方法后，事件发送线程被阻塞，但核心线程还是可以完成网络操作，并把操作完成的事件添加 到事件发送队列中。但是由于事件发送线程被阻塞，它也无法得到事件完成的消息，它也会一直阻塞在这里。并且，即使有办法恢复事件发送线程，但在它阻塞的过 程中，其他9个Session的消息也没有办法发送，这会极大的降低吞吐量。

 

目前的做法还是单线程分发事件，但一发现应用调用阻塞操作，就通过一个线程池获取另一个线程继续后面的事件分发；等到原线程从阻塞操作中恢复，再把线程放到线程池中。是Lead-Follows模型的应用。

2.Reactor的start方法上使用synchronized关键字

在该方法中使用synchronized关键字，并不会使在该方法中开启的线程也必须要拥有该锁。所以内部线程不死掉，该方法也能被调用。

 

3.Reactor的线程池调节

a2对这个的改动并不是线程问题，而是实际测试中发现这些代码并没有意义，不管在单CPU还是多CPU的情况下，效率只有降低，而没有提高，所以才去掉了这部分的代码。

 
至于1-N的线程模型，由于Filter机制的提供，应用可以根据自己的需要做更细的调节。比如通过自己实现的Executor，再 加上ExecutorFilter做N个分派线程；或者仅仅对messageReceived事件进行池化分派，等等。这些完全取决于应用自身的需要。但 是需要注意的是，一旦通过自己实现的线程池进行分派后，在进行同步方法的调用时就要注意尽量不影响其他异步操作的进行。