qq_36211262的博客

① 确认服务端的空闲超时时间：案例中服务端指的是kettle的远程carte服务，通过本地模拟Http请求调用carte服务，抓包看出运行服务的web容器是内嵌的Jetty。在我找到原因之后，由于我们公司使用的是kettle开源工具，没有定制它的源码，所以我们在项目中只是将服务端的超时时间适当的配大了一点，尽量减少异常的次数。上述案例，服务端配置的闲置超时时间=3000，所以在某种情况超过这个闲置时间，服务端会主动关闭TCP连接，但是客户端依然在复用这个连接，就会导致这个异常。...

大概意思就是说，JVM花费了98%的时间进行垃圾回收，而只得到2%可用的内存，频繁的进行内存回收(最起码已经进行了5次连续的垃圾回收)，JVM就会曝出java.lang.OutOfMemoryError: GC overhead limit exceeded错误。objectTimeout=1440 默认一天，即将执行完成的Job对象保留一天时间，可以在kettle.properties中自定义该属性的值，这边改的是5分钟，即任务执行完成后5分钟就会被扫描成过期的对象，让它尽量在年轻代就被回收掉。.....

那么我就来测试验证我发现的坑，这个坑就是"如果是ddl就会固定发到0号队列"，这里直接贴出我测试的结果，其中1号队列的2026条消息是增删改，而0号队列的2条消息，分别是我操作的TRUNCATE操作以及修改字段名。如果你有上述的类似问题，看到这里心情一定非常愉悦了，感觉可以直接开干了，但是当我看完 canal完整的源码，发现里面还是有坑的。0号队列"，这里直接贴出我测试的结果，其中1号队列的2026条消息是增删改，而0号队列的2条消息，分别是我操作的TRUNCATE操作以及修改字段名。