use of closed network connection

[codislabs]

use of closed network connection

[spinlock]

确定问题已经解决了对么？

[foolish-boy]

嗯 是因为目的端程序关闭导致的

[foolish-boy]

好吧 又出现这个问题了，这次没有关闭目的端程序。。

[spinlock]

redis port 运行的日志保留了么？

2016年1月12日星期二，foolishboy [email protected] 写道：

好吧 又出现这个问题了，这次没有关闭目的端程序。。

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[foolish-boy]

貌似这是一个bug吧， 这个 goroutine无限循环在做，容易进入一个与主进程竞争的时间窗口，即goroutine获取到链接c了 却突然被主进程关闭了。主进程应该在结束之前处理一下这个goroutine吧，就像c语言多线程里面的join 一样。

[foolish-boy]

运行日志？我这就直接输出在终端的，就这几行错误。

[foolish-boy]

我粗略想了一个解决这个bug的方法，比较笨的方法。 不知有没有问题？

474 running := true
475 wait_exit := make(chan int)
476 defer func() { 
477     running = false;
478     <-wait_exit
479     c.Close()
480 }()
481 go func() {
482     p := make([]byte, ReaderBufferSize)
483     for; running == true;  {
484         iocopy(c, ioutil.Discard, p, len(p))
485     }
486     wait_exit<- 0
487 }()

[foolish-boy]

哦，由于我这里修改过工具，会退出这个主进程的，所以会出现这个错误，原版的主进程是一直做下去的，所以不会出现这个问题。但这个bug还是一个隐患吧。。

[spinlock]

先说你改的代码吧。你是改的 sync 对吧。你的修改可能改错了，但是在 redis-port 里，这个不是 BUG。

先说明一下：

1. redis-port 是个 sync 工具，如果 master-port-slave 之间任何一个地方的网络除了问题，我都会直接让其 panic，因为错误恢复的难度太大了。要考虑数据同步问题。
2. master-port 之间的网络问题，我们通过 psync 的支持，可以让他不那么容易 panic，但是 port-slave 之间，没有更好的处理方式。毕竟网络出错了。举个例子：同步 incr key 这种指令，因为不是幂等的，如果网络错了怎么办，不能确定 slave 是否已经 apply 这个指令。所以如果出错了，只能 flushdb、从头再来一遍。
3. port-slave 之间，是指令同步。本质上就是 port 给 slave 一些同步指令，slave 返回一些 response。所以 iocopy 那段函数的作用就是忽略这些 response：如果不忽略，超过 slave 的缓冲区限制，slave 会直接 close connection，如果 slave 没有设置缓冲区 limits 的话，slave 最终也会 OOM 被杀掉。

我理解是因为你修改了代码，所以你认为那段代码是 bug。但是实际上那段代码根本不会 return 的。所以根本不是 bug。

[spinlock]

忽略修改，单说 running 是个非 volatile 的变量，在 2 个 routine 里用来通信就已经不对了

[foolish-boy]

嗯，说的很有道理，对于redis-port 里，这不能算是bug。
但我的代码是要return的，那要怎么修改更好呢？

[spinlock]

既然修改了 redis-port，要看具体做什么了。
至少不要直接用 utils.go 里面的 iocopy，那个会直接 panic 退出的。

剩下的，只能需要根据自己的需求定方案了？

[foolish-boy]

需求就是我上面的那种思路：主进程close之前，通知goroutine, 然后停止iocopy。
这个有没有其他好方法？我也再想想

[spinlock]

有，但是这明显不在 redis-port 的 issue 讨论范围内了，对吧 😄