We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
push_receiver.go 第 102 ~ 112 行,代码如下:
go func() { defer conn.Close() for { select { case <-us.ctx.Done(): return default: us.handleClient(conn) } } }()
这里,会阻塞在 us.handleClient(conn) 里面:
func (us *PushReceiver) handleClient(conn *net.UDPConn) { data := make([]byte, 4024) n, remoteAddr, err := conn.ReadFromUDP(data) if err != nil { logger.Errorf("failed to read UDP msg because of %+v", err) return }
由于 ReadFromUDP 不是一个异步的方法,会阻塞,然后 上面的 go 协程就等于死锁了,除非有推送过来; 可行的修复方案:
go func() { defer conn.Close() tmpChan := make(chan int, 1) tmpChan <- 1 for { select { case <-us.ctx.Done(): conn.Close() return case <-tmpChan: go func() { defer func() { _ = recover() tmpChan <- 1 }() us.handleClient(conn) }() default: time.Sleep(time.Second) } } }()
理论上,并不会存在 client 频繁创建销毁的情况,所以该泄漏似乎也没问题;但我们负责 grpc 的同学反馈,golang grpc 是通过 resolver 来和 nacos 打通的,而 resolver 就是会频繁的创建、销毁,进而导致 nacos 的 naming client 频繁创建、销毁;
The text was updated successfully, but these errors were encountered:
No branches or pull requests
push_receiver.go 第 102 ~ 112 行,代码如下:
这里,会阻塞在 us.handleClient(conn) 里面:
由于 ReadFromUDP 不是一个异步的方法,会阻塞,然后 上面的 go 协程就等于死锁了,除非有推送过来;
可行的修复方案:
理论上,并不会存在 client 频繁创建销毁的情况,所以该泄漏似乎也没问题;但我们负责 grpc 的同学反馈,golang grpc 是通过 resolver 来和 nacos 打通的,而 resolver 就是会频繁的创建、销毁,进而导致 nacos 的 naming client 频繁创建、销毁;
The text was updated successfully, but these errors were encountered: