tree 246f57dfee7f541bac6941c2a18d9e57c0ee9c06
parent 6f29f3ecfaf5d0a68bb9a28f5733ef0d48d2c3c5
author Pavlin Radoslavov <pavlin@onlab.us> 1406886467 -0700
committer Gerrit Code Review <gerrit2@localhost> 1407356009 -0700

Work toward ONOS-1451: Separate Event Key space per instance

Final step in the implementation:
Implement the Topology Event filtering and processing logic
inside class TopologyEventPreprocessor:
  - The topology events from each ONOS instance are kept separately
    within class OnosInstanceLastAddEvents
  - We keep only the last copy of the ADD events (not removed yet
    by REMOVE events).
  - If ADD MastershipEvent is received, all previously
    stored ADD Topology events for the corresponding Switch DPID are
    applied to the Topology
  - If there were previously reordered events, we attempt to
    add them again along with the other events.
  - Before adding the events to the Topology, the events are
    aggregated (squashed), and reordered in their natural order to
    build a Topology. E.g., the ADD events order is:
    MastershipEvent, SwitchEvent, PortEvent, LinkEvent, HostEvent.
    The REMOVE events are in the reverse order.
    Also, the REMOVE events are processed before the ADD events.
  - If an event cannot be added to the topology, it is added
    back to the collection of reordered events.

Also, replaced some of the Collection<> with List<> in some of the
event-related API to indicate that there is a semantic ordering
of the events.

NOTE: Some of the internals of TopologyEventPreprocessor should be optimized
for speed. E.g., we should create an additional lookup map:
    Dpid -> Collection<TopologyEvent>
and then method getPostponedEvents() doesn't need to traverse all
topologyEvents entries.

Change-Id: Ic0d9ebf242f015adb60817921b239bb65dd560e2