主要修复 SocketChannel 默认缓存大小（1MB）不够用时需自动扩充，否则将因缓存空间不足而造成I/O超时假象

[Wu-Jianqiang]

通常复制包含 CLOB/BLOB 字段类型数据时会遭遇这个问题。1.0.24版开始表现为没有任何反应，也没有任何错误日志。升级到1.0.25版之后即报"socket read timeout occured !"错误，给人误以为网络或者数据库问题（复制是在经过公网SSH转发的两个私网之间）。后经调试跟踪发现实质是固定1MB缓存大小问题。实际运行测试发现一次性readSize达到15MB及以上。截止目前的 1.0.26-SNAPSHOT 编译发布，已稳定运行。

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[lcybo]

用change master to语法单位才是秒。canal不是真正的mysql，无法使用change master to语句，所以用set @@MASTER_HEARTBEAT_PERIOD单位是纳秒。

[lcybo]

另外，mysql的maxThreeBytes最大就是将近16MB，没有必要反复改，缓存开始直接设为16M就可以啦。

[Wu-Jianqiang]

lcybo，谢谢你的指正。

根据你提供的线索，我搜索了下 MySQL jdbc 中 com.mysql.jdbc.MysqlIO 源码，部分摘录如下：

if (versionMeetsMinimum(4, 0, 8)) { this.maxThreeBytes = (256 * 256 * 256) - 1; this.useNewLargePackets = true; } else { this.maxThreeBytes = 255 * 255 * 255; this.useNewLargePackets = false; }
看起来确实可以简单的设置为： 16MB = 256 * 256 * 256

不过我还是希望代码中做必要的检查和详细日志，不然太烧脑了。

[lcybo]

嗯，其实个人觉得dump IO这里没有用netty NIO的必要，割裂了读写线程，引入了不必要的复杂度。
用BIO通过设置较小的SO_TIMEOUT进行捕捉可以规避闪断问题和处理线程中断场景，也更加简洁。

[agapple]

tks