Race condition happened if one node add event listener after other nodes
send event.
The local route table might not be initialized correctly
Change-Id: Id6ff1344897e36d7d48ccf36b1b0b843ea2e9d09
Now built using a URL, while input streams are generated on-demand.
Before it could happen that the input stream was completelly read by
someone, leaving it unusable by others.
Change-Id: I61a76bf8b8c1d2f6e2d987661025e0323d59e1c7
Required for building P4Runtime stuff.
Also:
- support in grpc_jar for building external protobuf files
- minor code refactoring/cleanups
Change-Id: I50c09f967cc9257366eb028d4ea1502767d8d4a0
The goal is to clean up the interfaces a little bit in preparation for
a major RouteService refactoring that is coming.
Change-Id: Ifbde9a507dd0dc3cddcd7fa1c02c426dad386e5f
At present, we have to use requestPackets to trigger adding packet processor for virtual network and use cancelPackets to trigger removing the packet process for the virtual network.
But if we call cancelPackets more then one time in the deactivate() method when the application is deactivated, if will throw a NullPoint exception.
Furthermore, if a user does not requestPackets() in the application, the packet processor will never be added.
It may be a confusing trouble for a tenant user.
As a result, I think the packet processor should be created when the virtual network is added and be removed when no virtual network exists.
Soultions:
Listen to the network event to add and remove packet processor for virtual network.
Change-Id: I583d453219bef2f271b4a1e96f9869a28b4f0250
- checkstyle buck daemon was not processing a file listed at end of the list.
- fix issues, which hasn't been detected due to above bug
- cosmetic fixes
Change-Id: I15f24311835726757f0974b7e5c12ff1c79a3d4e
The constructor of VirtualPacketContext needs a parameter of DefaultVirtualPacketProvider type.
It is not flexible for us to use another packet provider to replace the default virtual packet provider.
To improve the code flexibility, I think it is better for us to use an interface type parameter in a method.
It alse seems redundant to use emit() method of DefaultVirtualPacketProvider in devirtualizeContext().
Thus, I think it will be more efficient to use core PacketService in VirtualPacketContext
when triger send() method.
Some other bugs are fixed.
Change-Id: I161a8929dc4e5a1d2ad716bc5da8b0b6f84340a9
1. Create new module incubator/bmv2/model
2. Move all bmv2 model files to incubator/bmv2/model
3. Using PI core interfaces for all bmv2 models
4. Refactor original bmv2 config parser (Bmv2PipelineModelParser)
5. Refactor original bmv2 config parser test
Change-Id: I0db07762d76ab6e2f846e9c3c9d5896f0cbea7f2
