Server类是个抽象,只所以抽象,是具有如下抽象方法:
也就是说,服务器端接收到请求后,最后对这个请求的真正处理是通过此方法执行的。又具体的实现类实现这个方法。
回顾前面[url]http://jimmee.iteye.com/blog/1201398[/url]关于nio的reactor模式,hadoop的rpc调用的Server完全按照这个模式来实现
[list]
[*]1. Listener类,启动一个线程使用一个Selector来处理Channel的Accept;
[*]2. Listenter.Reader类,启动多个线程来(当然也可以配置成一个,关键看cpu是怎样的了)处理Channel的读,也就是得到client;
[*]3. Handler类,业务线程处理类,这个类处理真正的调用,线程池配置多大,就启动多少个线程,其实我觉得直接使用java.util.concurrent中的线程池更方便;
[*]4. Responder类,这个类启动一个线程,使用一个Selector来处理写(这里值得注意的是,并不是每个Channel都添加到Selector里来处理写操作,而是有没有写完的数据时候,才添加进去)
[*]5. Call类,可以理解为与Client端的Call对应;
[*]6. Connection,代表与Client端的连接,读取客户端的call并放到一个阻塞队列中,Handler负责从这个队列中读取数据并处理
[/list]
总之按照这个流程去理解server端的代码就ok。
public abstract Writable call(Class<?> protocol, Writable param, long receiveTime)
throws IOException;
也就是说,服务器端接收到请求后,最后对这个请求的真正处理是通过此方法执行的。又具体的实现类实现这个方法。
回顾前面[url]http://jimmee.iteye.com/blog/1201398[/url]关于nio的reactor模式,hadoop的rpc调用的Server完全按照这个模式来实现
[list]
[*]1. Listener类,启动一个线程使用一个Selector来处理Channel的Accept;
[*]2. Listenter.Reader类,启动多个线程来(当然也可以配置成一个,关键看cpu是怎样的了)处理Channel的读,也就是得到client;
[*]3. Handler类,业务线程处理类,这个类处理真正的调用,线程池配置多大,就启动多少个线程,其实我觉得直接使用java.util.concurrent中的线程池更方便;
[*]4. Responder类,这个类启动一个线程,使用一个Selector来处理写(这里值得注意的是,并不是每个Channel都添加到Selector里来处理写操作,而是有没有写完的数据时候,才添加进去)
[*]5. Call类,可以理解为与Client端的Call对应;
[*]6. Connection,代表与Client端的连接,读取客户端的call并放到一个阻塞队列中,Handler负责从这个队列中读取数据并处理
[/list]
总之按照这个流程去理解server端的代码就ok。