-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rop中线程问题 #22
Comments
毕竟线程加入队列以后,执行的线程不一定是马上加入队列的那个线程,而在监控超时用的request却用的是当前的request。 |
ServiceRunnable 内部类 会对每个请求找一个线程来处理业务逻辑,包括后续的返回reponse也是这个线程做的,即使阻塞,也应该不会出现A 请求 返回的是B响应吧? |
kluyuyu说的问题在我这里已经出现,a发的请求超时,b发请求后收到的是a请求的数据。 |
我已经将 rop精简成了 60个java类的框架,彻底解决了那些问题,增加了对,上传流的支持。具体的请加 深圳java群③ 190798044 在 2015-03-16 09:27:55,"laiyuan" [email protected] 写道: kluyuyu说的问题在我这里已经出现,a发的请求超时,b发请求后收到的是a请求的数据。 — |
future.get阻塞的是tomcat i/o线程,持有的是当前request。 |
主要serlve规范中定义生命周期,线程安全的问题 而且tomcat容器会对request 等对象复用 所以异常情况下会对报文混淆的问题 |
程序中用了这个 LinkedBlockingDeque队列
// 设置异步执行器
if (this.threadPoolExecutor == null) {
this.threadPoolExecutor = new ThreadPoolExecutor(200,Integer.MAX_VALUE, 5 * 60, TimeUnit.SECONDS,new LinkedBlockingDeque());
}
然而在Future<?> future = this.threadPoolExecutor.submit(runnable);用了这个,很明显,在多线程环境下,排队多了的情况,会有概率性,出现执行的并不是当前 request的线程。也有可能是 a客户端的request,的结果返回给了b客户端,虽然概率很低很低,但是会有可能发生,建议主机把 LinkedBlockingDeque提出来。
The text was updated successfully, but these errors were encountered: