原创 吴就业 128 0 2022-04-18
本文为博主原创文章，未经博主允许不得转载。
本文链接：https://wujiuye.com/article/e6891dbb1caf41d1bc4de9b69e2f67e9
作者：吴就业
链接：https://wujiuye.com/article/e6891dbb1caf41d1bc4de9b69e2f67e9
来源：吴就业的网络日记
本文为博主原创文章，未经博主允许不得转载。
某线上应用rpc接口调用超时导致定时任务执行失败，该任务使用了XxlJobLogger将rpc错误日记输出到xxl-job的job执行日记文件。
这个日记会在sdk调用callback接口时带上，由于输出的错误日记字符串长度过长，导致xxl-job-admin处理callback请求无法将日记入库。sdk会将失败的callback写入一个重试文件（xxl-job-callback.log），sdk有一个后台线程，定时每几秒会全量load重试文件到内存中。
由于重试也是失败，重试失败的记录也会重新写出失败日记文件，导致重试文件随时间的积累，变得越来越大，load到内存中占用的内存就会越来越多，最终导致应用OOM。
声明：公众号、CSDN、掘金的曾用名：“Java艺术”，因此您可能看到一些早期的文章的图片有“Java艺术”的水印。
无损上下线是服务治理不可忽视的问题，在应⽤上下线发布过程中，如果上下线不平滑，就会出现短时间的服务调⽤报错，如连接被拒绝（`Connection refused`）、请求超时或请求异常。
此次性能测试对比的是我们基于Dubbo扩展点自实现的Http rpc协议，与Dubbo原生Dubbo rpc协议的单次请求响应平均耗时、吞吐量。
很多规模稍大点的公司，内部都会有多个业务部门，这些业务部门都有自己的业务产品。每个业务部门开发的产品部署的环境物理上也都是相对隔离的，但这些业务部门之间可能存在合作关系，业务关联，因此就有了跨业务RPC调用的需求。
订阅
订阅新文章发布通知吧，不错过精彩内容！
输入邮箱，提交后我们会给您发送一封邮件，您需点击邮件中的链接完成订阅设置。