You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I add logs in function addStreams and removeStreams like below:
and observe that: when a udp packet travels in this path successfully, there is addStreams log, but there is not removeStreams log.
So in EdgemeshB, where should inStream.Close() been executed?
See go-libp2p example as below, inStream.Close() can be executed in streamHandler function.
So in edgemesh, can inStream.Close() be executed in ProxyConnUDP as below?
as soon as I add "defer inConn.Close()" at conn.go:58, this bug seem to be solved.
If this method to fix this bug is right, in addition to udp packet process function, please check is there the same bug in tcp packet process function, and other p2p protocol StreamHandler function.
I'm experiencing a similiar issue related with UDP packets sent by pods of a daemonset to CoreDNS to retrieve the IP of a K8s service. These pods send a request per second and after some time, the connection fails. It can be solved by restarting the EdgeMesh pods, but after running for a while, it fails another time.
Udp package send with long time interval, that can cause udpconn.deadline, and this for loop will break, then this stream cannot be used no longer, but the stream is not be released.
Edgemesh seems to have performance issues; after a period of time, UDP packets can no longer be sent out.
After running for a while, the UDP packets can't be sent out, but restarting the Edgemesh on the node fixes the issue.
The text was updated successfully, but these errors were encountered: