Fix bundle_timeout issue caused by OVS PacketIn channel #951
Conversation
|
Thanks for your PR. The following commands are available:
These commands can only be run by members of the vmware-tanzu organization. |
|
Thanks for your PR. The following commands are available:
These commands can only be run by members of the vmware-tanzu organization. |
gran-vmv
force-pushed
the
tf-bundle
branch
3 times, most recently
from
993fd23
to
e945a50
Compare
| for { | ||
| select { | ||
| case pktIn := <-ch: | ||
| if packetInQueue.Len() < packetInQueueSize { |
There was a problem hiding this comment.
We need a comment here. Especially because if someone refers to the K8s documentation (https://godoc.org/k8s.io/client-go/util/workqueue#Type.Len), they will see this:
Len returns the current queue length, for informational purposes only. You shouldn't e.g. gate a call to Add() or Get() on Len() being a particular value, that can't be synchronized properly.
Now in our case I think it's ok because we just try to ensure that the queue doesn't grow too big, we are not interested in providing an exact guarantee. But a comment would help avoid confusion.
There was a problem hiding this comment.
Sure. Added comment here.
SubscribePacketIn requires a receiver to pop data in ch timely, otherwise it will block all inbound messages from OVS.
|
/test-all |
|
/test-e2e |
|
/test-e2e |
SubscribePacketIn requires a receiver to pop data in ch timely, otherwise it will block all inbound messages from OVS.
SubscribePacketIn requires a receiver to pop data in ch timely, otherwise it will block all inbound messages from OVS.
This PR closes #937