Remove DataChangeListener and friends AsyncDataChangeEvent is being kept for now as ovsdb still independently uses it internally. JIRA: TSC-112 Change-Id: Ia68ac1cdf31dec3645f675442db14b7697d63b64 Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Refactor Register*ListenerReply classes The listener-type specific RegisterDataTreeChangeListenerReply and RegisterChangeListenerReply classes are identical. Simplify by replacing them with a general RegisterDataTreeNotificationListenerReply. This also simplifies AbstractDataListenerSupport by eliminating the abstract newRegistrationReplyMessage method. Change-Id: I97f6cf366ae6ff858ff258ebb8479468b144c193 Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Simplify DelayedListenerRegistration functionality The DelayedListenerRegistration class is abstract with parameterized sub-classes for the 2 listener types which don't provide any additional functionality. Consequently AbstractDataListenerSupport is parameterized with the DelayedListenerRegistration type with an abstract method to instantiate the appropriate type. We can simplify AbstractDataListenerSupport by removing the type parameter and the abstract method and consequently remove the 2 DelayedListenerRegistration sub-classes. Change-Id: I04933753b59748a09c31e0ec5ed4de9666fea364 Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Bug 8231: Fix testChangeListenerRegistration failure As described in Bug 8231, the sharing of the ListenerTree between the ShardDataTree and the ShardDataTreeNotificationPublisherActor is problematic. Therefore the ListenerTree (wrapped by the DefaultShardDataTreeChangeListenerPublisher) is now owned by the ShardDataTreeNotificationPublisherActor. On registration, a RegisterListener messages is sent to the ShardDataTreeNotificationPublisherActor to perform the on-boarding of the new listener, ie it atomically generates and sends the initial notification and then adds the listener to the ListenerTree. This change necessitated some refactoring of the DataChangeListenerSupport class et al wrt to how the ListenerRegistration is handled. Prior the ListenerRegistration was passed on creation of the registration actor. This is now done indirectly by sending a SetRegistration message to the registration actor via a Consumer callback passed in the RegisterListener message. When the ListenerRegistration is obtained by the ShardDataChangePublisherActor, it invokes the Consumer callback. When a registration is initially delayed due to no leader, the DelayedListenerRegistration is sent to the registration actor. When the leader is elected later on, the actual ListenerRegistration is sent and replaces the DelayedListenerRegistration. The DOMDataTreeChangeListener registration classes were changed/refactored similarly. In addition, the 2 specific registration actor classes were replaced by a generic reusable DataTreeNotificationListenerRegistrationActor that handles both listener types. Also the 2 CloseData*ListenerRegistration and CloseData*ListenerRegistrationReply messages were consolidated. Change-Id: I79ac76b8044609351e5dd8367b691b589ea35075 Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Usage of Collections.unmodifiableCollection is unsafe This is a follow-up to https://git.opendaylight.org/gerrit/#/c/51583/ wrt a review comment questioning why I returned a new ArrayList instead of returning the Set directly. One reason was to avoid mutation of the internal set by the caller but also to capture the state of the set at that point in time and avoid concurrent mods which may not be safe. Where a concurrent set is used, it would be thread-safe to return the set directly but the set may by modified as the caller is iterating it which may not be desired. For the other class whose set is a keySet from a non-threadsafe Map, the caller could get a ConcurrentMod exception while iterating. Based on the review, I changed the call sites to return a Collections.unmodifiableCollection but this is also incorrect and is susceptible to the same issues as that impl reads-thru to the underlying collection. Therefore I changed the call sites back to returning a new ArrayList. Change-Id: I504f38c5bfc4c707180ac301eb10acd0ac24f872 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Add OnDemandShardState to report additional Shard state Extended the OnDemandRaftState with OnDemandShardState to include additional Shard state, including DTCL, DCL, and commit cohort actors. This will enable us to report thus info from the JMX bean as it's useful for debugging to have visibility into what listeners and cohorts are registered. The actors now also store the registered path. Both the instance and path will be queried for debugging. Change-Id: Iaa6c27c9aba3b5c0223199e6a3fc21bc54da95ba Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Fix warnings/javadocs in sal-distributed-datastore First off, I apologize for the size of this patch. There's a ton of classes in this project and I didn't even get to all of them (will follow-up). While a lot of files were touched, the changes were mostly small. Fixed a lot of checkstyle warnings and cleaned up javadocs. Most of the warnings/changes were for: - white space before if/for/while/catch - white space before beginning brace - line too long - illegal catching of Exception (suppressed) - variable name too short - indentation - missing period after first sentence in javadoc - missing first sentence in javadoc - missing <p/> in javadoc Change-Id: Id56d874a8fbcbbc9285279a71c0a5aba393653a9 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Bug 4651: Implement handling of ClusteredDOMDataTreeChangeListener in CDS Implemented handling of ClusteredDOMDataTreeChangeListener similar as to what was done previously for ClusteredDOMDataChangeListener. I also refactored the listener support classes used by Shard and extracted generic base classes for the common functionality. Change-Id: I694a6a4ce41284f7ecd3bf73bc6201e9d5555998 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Bug 4094: Fix DCNs on initial registration For DataChangeListener, I modified the code to use a ResolveDataChangeEventsTask to resolve the initial changed event. It was noted in Bug 4094 to read the registration path up to the first wildcard. However this did not work. ResolveDataChangeEventsTask expects the candidate root path and "after" data to be the tree root to match the structure of the ListenerTree. When a transaction is committed, the resulting DataTreeCandidate always points to the root. So I had to read the root path in ShardDataTree. I could've optimized for non-wildcarded path registrations but I think wildcarded path registrations will be the norm anyway. I added a new method, notifyOfInitialData, in ShardDataTree. Because I had to create a new ListenerTree with the single registration, I needed to know the path and scope of the original registration so I changed several method signatures from the general ListenerRegistration to the specific DataChangeListenerRegistration which provides access to the path and scope. However we also have an actor class by that name so to avoid confusion I renamed the actor class to DataChangeListenerRegistrationActor. DataTreeChangeListener was implemented similarly. Change-Id: I0ab88d0991761c058b6af81d6d26402ff370b78e Signed-off-by: Tom Pantelis <tpanteli@brocade.com> (cherry picked from commit 0a7e13a8c7fed697800c792698cfef32b2ef0d11)
Enabling Data Change Notifications for all nodes in cluster. Two new interfaces are introduced ClusteredDataChangeListener and ClusteredDOMDataChangeListener and external applications will have to implement any of that interface, if those applications want to listen to remote data change notifications. Datastore registers listeners, which are instance of that interface, even on followers. Change-Id: I0e29cdf2a08a2051de5fc8ce73b9ec8ac408e45b Signed-off-by: Harman Singh <harmasin@cisco.com>
CDS: use internal DataTree instance Instead of using a captive InMemoryDataStore instance, which is geared toward interaction with a DOMDataBroker, use the baseline DataTree instance and utility classes for implementing the data store behavior. Since most of CDS is geared for interactions with the usual DOMStore interfaces, this patch provides a set of bare-bone workalike classes, but taking advantage of the safeties provided by the AKKA actor system. Immediate benefit should be a speed up in backend processing, as we eliminate intermediate Future instances when accessing and manipulating data. We also gain explicit control over DataTree lifecycle, which enables us switching to DataTreeCandidate as the replication and persistence unit, as opposed to individual modifications. Change-Id: I031d0ed4d82dcc923fd377c13fefba2819923f9b Signed-off-by: Robert Varga <rovarga@cisco.com>
Make LeaderLocalDelegateFactory a bit more useful It seems that the two isntantiations use functionality which can be easily abstracted out, simplifying code. Change-Id: Id5e7cb71055ef14b2139be2ba74e29f9cd10da60 Signed-off-by: Robert Varga <rovarga@cisco.com>
CDS: Move DataChangeListener into a support class This patch follows up the pattern set by DataTreeChangeListener and moves the related code out. Change-Id: Ib945dc308c2264f21c0a7df8152c1f9f8f908a43 Signed-off-by: Robert Varga <rovarga@cisco.com>