记一次线上压测Dubbo线程池队列满的问题

现象：消费端大量超时，服务部分失败请求执行时间特别长（30s左右）

分析：除了客户端超时，服务端没有任何异常日志，由于使用的 dubbox ，怀疑组件bug；

         通过查看监控平台falcon,grafana系统资源及 jvm 压力不大、波动平稳，GC 正常，jvm线程数稳定，

         通过第三方监控平台听云，查看各指标正常，就是请求超时比较多；

         无意间发现听云『异常分析』模块里出现了一个异常：事务-NettyDispatcher/upstreamDispatcher 异常-com.alibaba.dubbo.remoting.ExecutionException，异常信 息-class com.alibaba.dubbo.remoting.transport.dispatcher.all.AllChannelHandler error when process received event ；

         突然感觉像是有线索了，继续追踪在异常栈内发现一段信息『caused by java.util.concurrent.RejectedExecutionException: Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-10.49.7.246:20062, Pool Size: 200 (active: 200, core: 200, max: 200, largest: 200), Task: 53770958 (completed: 53770758), Executor status:(isShutdown:false, 』；

         真相了，原来dubbo 线程池满了；那为什么没有日志和dubbo异常dump（第一时间排查了dubbo异常dump），看源码后原来 dubbox 里的任务拒绝策略类『AbortPolicyWithReport』没有 dump 功能，这个功能应该是后期追加的，dubbox 并不支持；而且应用未指定 dubbo.application.logger,所以 WARN 日志也未输出；到此『客户端大量超时』基本找到原因了；但有一点疑惑『为什么会服务端部分请求会执行这么就呢？』，请看 https://www.cnblogs.com/jice/p/11840990.html