Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
The Application loads a json config file at start up. This config file will have Kafka config information.
CLUSTERING SUPPORT
...
- We will be using a Distributed Work Queue(DWQ) as the primitive.
...
- There will be Leadership elections for two separate topics – WORK_QUEUE_PUBLISHER, WORK_QUEUE_CONSUMER.
...
- The Leader for WORK_QUEUE_PUBLISHER will publish events to DWQ.
...
- The Leader for WORK_QUEUE_CONSUMER will consume events from DWQ and send it to KafkaServer.
...
- In case of failure of one of the Leaders and the Leader has failed to mark the task consumed from DWQ as complete, the task(in our case event) will be returned to the DWQ. The new Leader will pick this up from DWQ.
...
- There is a rare possibility that the Leader for publisher failed before it can queue the event to DWQ. This will result in a loss of event.
...
- Since there is only one consumer from DWQ FIFO ordering of events is guaranteed.
DESIGN DECISIONS
- There will be one topic per event type. Each external app will be given a unique consumer groupId.
- Event subscription by external apps is a two step process - They must first register and then subscribe to a specific event call.
As a first step we will only export Device Events and Link Events to consumers and worry about Packet Ins and Packet Out later.
- Once the framework is in place it should be relatively easy to add support for other event types.
- In the scenario where the external app loses connectivity with the Kafka server, and does not come back up within the retention period (the time duration for which Kafka will retain messages) the onus is on the non native app to rebuild its current view of the network state via existing ONOS REST APIs.
...