浏览 3439 次
|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-02-24
工作中使用到apache的ftpserver，一直以为基于mina的它是异步非阻塞IO的，结果看了源码
发现，接收是这么写的
while (true) {
从流中读
写文件
}
}}
真是太失望了，这样一来，ftpserver处理客户请求的数据就取决于那个ExectorFilter中的线程池大小了，ftpserver用的是OrderExectorFilter的无参构造函数，默认池的最大值是16了。要是同时接收16个大文件的话，就没有能力处理新请求了，注意NioListener还是能够处理监听的，因为它跟ioserver用的不是一个线程池（我猜的）。只是socket连上后，就处在持续等待的状态，任你新来的ftp command是啥，都不处理。直到有一个大文件传输完成，腾出一个可用线程。 我觉得要整个基于mina的应用出来，怎么着您也得使用一下这个框架的特性，啥异步io呀，高性能呀，结果搞出这么个东东。当然apache还是NB的，我自己做不出来，只能用人家的，发发牢骚罢了，各位尽量拍，哈哈。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2010-03-03
楼上可以根据自己的服务器性能适当的调整这个值的
|
| 返回顶楼 | |
|
发表时间：2010-03-04
david.org 写道 楼上可以根据自己的服务器性能适当的调整这个值的 也就用OrderedThreadPoolExecutor(int size)这个方法初始化线程池大小 |
| 返回顶楼 | |
|
发表时间：2010-11-15
public synchronized ThreadPoolExecutor getThreadPoolExecutor() {
if(threadPoolExecutor == null) {
int maxThreads = connectionConfig.getMaxThreads();
if(maxThreads < 1) {
int maxLogins = connectionConfig.getMaxLogins();
if(maxLogins > 0) {
maxThreads = maxLogins;
}
else {
maxThreads = 16;
}
}
LOG.debug("Intializing shared thread pool executor with max threads of {}", maxThreads);
threadPoolExecutor = new OrderedThreadPoolExecutor(maxThreads);
}
return threadPoolExecutor;
}
查看1.0.5源代码如上，貌似楼主的问题并不是问题 |
| 返回顶楼 | |
|
发表时间：2010-11-27
simen_net 写道
public synchronized ThreadPoolExecutor getThreadPoolExecutor() {
if(threadPoolExecutor == null) {
int maxThreads = connectionConfig.getMaxThreads();
if(maxThreads < 1) {
int maxLogins = connectionConfig.getMaxLogins();
if(maxLogins > 0) {
maxThreads = maxLogins;
}
else {
maxThreads = 16;
}
}
LOG.debug("Intializing shared thread pool executor with max threads of {}", maxThreads);
threadPoolExecutor = new OrderedThreadPoolExecutor(maxThreads);
}
return threadPoolExecutor;
}
查看1.0.5源代码如上，貌似楼主的问题并不是问题 不好意思，你指我的问题并不是问题，能再细说说不？我之前主要说，接收文件时是同步的，这样线程池一满，就是再小的文件也得等。 |
| 返回顶楼 | |
|
发表时间：2010-11-27
想想单CPU的系统上是如何运行多进程、多线程、处理IO中断的，那是比较彻底的异步化。
NIO的架构通常都是异步监听、同步处理。在java中，这种基于线程池的普遍设计模式在处理长时间服务请求的时候都存在线程调度问题。长时间占用线程池里的共享线程是很要命的，还不如单独启一个线程。 这种框架下也没什么好办法，通常都是加大线程池容量。 比较彻底的方法之一是彻底的异步化，关键技术可能是基于任务分解和消除同步调用（尤其是同步IO）。不过这样的框架可能会比较复杂。（JDK7里好像就有任务框架和AIO）。 还有我认为同步化往往是更简单、容易的解决问题的手段，能用同步就不用异步。至于那些所谓线程资源、线程调度的相关问题，应该留给操作系统或是jvm去解决，而不是去搞什么异步框架。当然，目前来看，这还只是我个人的一个理想。 |
| 返回顶楼 | |
|
发表时间：2010-11-29
taolei0628 写道 想想单CPU的系统上是如何运行多进程、多线程、处理IO中断的，那是比较彻底的异步化。
NIO的架构通常都是异步监听、同步处理。在java中，这种基于线程池的普遍设计模式在处理长时间服务请求的时候都存在线程调度问题。长时间占用线程池里的共享线程是很要命的，还不如单独启一个线程。 这种框架下也没什么好办法，通常都是加大线程池容量。 比较彻底的方法之一是彻底的异步化，关键技术可能是基于任务分解和消除同步调用（尤其是同步IO）。不过这样的框架可能会比较复杂。（JDK7里好像就有任务框架和AIO）。 还有我认为同步化往往是更简单、容易的解决问题的手段，能用同步就不用异步。至于那些所谓线程资源、线程调度的相关问题，应该留给操作系统或是jvm去解决，而不是去搞什么异步框架。当然，目前来看，这还只是我个人的一个理想。 你说的方法一我赞同，当请求数远大于可用线程数时，是有必须要彻底异步。不然，线程池大于为10，正在处理10个大文件，再来一个请求也只能放到队列中了。这还得由实际需求来决定。 |
| 返回顶楼 | |
