Deprecate ask-based protocol messages Since we have removed the ask-based client, we really have no way of testing ask-based messages' interaction with Shard. We keep Shard compatible, but deprecate all ask-based messages and methods/classes dealing with them on the backend. JIRA: CONTROLLER-2054 Change-Id: I5764713b686ae11f8d750e691576b6d20637ab7d Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Clean up modification tests Make sure we close the read transaction and improve assertions with Optional. Change-Id: Ia465f64c5845e3d5e215759cc32048e06478104b Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Bump odlparent/yangtools/mdsal Adopt latest versions, namely; - odlparent-9.0.1 - yangtools-7.0.1 - mdsal-8.0.0-SNAPSHOT There are a few adjustments needed, which mostly deal with the interface to NormalizedNode. Change-Id: I918fb885a6df62e16e17119a7e04ba1672ef7c39 Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Bump odlparent/yangtools/mdsal Update upstream references to: - odlparent-7.0.1 - yangtools-5.0.0-SNAPSHOT - mdsal-6.0.0-SNAPSHOT Also adjust the codebase to match changes in yangtools/mdsal and scala-2.13. Change-Id: Ib082e955b5106fa002522dfe3d7a21fe990006d8 Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Speed up AbstractModificationTest Sharing SchemaContext here shaves off about 2 seconds from test run time. Change-Id: I5e7fa63dd061ee6e1a16831aeae59f61deaccb5f Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Adjust to mdsal DOM read/exists FluentFuture change This patch needs to be coordinated with https://git.opendaylight.org/gerrit/#/c/74127/. Change-Id: Iceeff9f9f75ca40ebc31bd839b5e6a5c8639aa4c Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Switch CDS frontend internals to use MD-SAL APIs This patch wires frontend to use MD-SAL DOM*Transaction and related interfaces instead of the controller-provided ones. Change-Id: I8c9c303ca95a961c8c7f91ba4d438c0739c5cedd Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Fix unit test CS warnings in sal-distributed-datastore Fixed checkstyle warnings in unit tests. 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) - illegal throwing of Throwable (changed to Exception) - variable name too short - indentation, mostly due to nested code inside anonymous JavaTestKit instances - separator wrapping: '.', '+', '&&' should be on a new line - local vars/params hiding a field - putting overloaded methods close to one another - remove unused vars - convert functional interfaces to lambdas (eclipse save action) - adding final for locals declared too far from first usage Also 3 classes are no longer used so I removed them rather than fix warnings. Change-Id: Ie1507e36c67a2b58f7efb62378212976b962f9fe Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Do not use MoreExecutors.sameThreadExecutor() This method is deprecated, replace it with proper service/executor. Change-Id: I7257a28f28784313cafc250f2c2fd1c623332dec Signed-off-by: Robert Varga <rovarga@cisco.com>
BUG-650: remove executor abstraction This patch removes sameThreadExecutor from the commit path, eliminating associated overhead. Relevant benchmarks show improvement pretty much across the board: BEFORE millis error write100KSingleNodeWithOneInnerItemInCommitPerWriteBenchmark 2213.735 77.597 write100KSingleNodeWithOneInnerItemInOneCommitBenchmark 171.524 2.289 write10KSingleNodeWithTenInnerItemsInCommitPerWriteBenchmark 164.282 1.391 write10KSingleNodeWithTenInnerItemsInOneCommitBenchmark 14.161 0.196 write50KSingleNodeWithTwoInnerItemsInCommitPerWriteBenchmark 982.697 29.397 write50KSingleNodeWithTwoInnerItemsInOneCommitBenchmark 93.233 2.174 AFTER millis error delta write100KSingleNodeWithOneInnerItemInCommitPerWriteBenchmark 2138.900 75.844 -3.4% write100KSingleNodeWithOneInnerItemInOneCommitBenchmark 177.839 3.997 +3.5% write10KSingleNodeWithTenInnerItemsInCommitPerWriteBenchmark 158.666 1.090 -3.5% write10KSingleNodeWithTenInnerItemsInOneCommitBenchmark 13.022 0.105 -8.0% write50KSingleNodeWithTwoInnerItemsInCommitPerWriteBenchmark 935.490 30.395 -4.8% write50KSingleNodeWithTwoInnerItemsInOneCommitBenchmark 89.907 1.204 -3.6% Furthermore it cleans up and marks FIXMEs for defunct statistics. These will need to be replaced with implementation which does not assume underlying implementation. Change-Id: I01c51462a8529a2f874ecd2f9af05faba503bc58 Signed-off-by: Robert Varga <rovarga@cisco.com>
Bug 1430: Off-load notifications from single commit thread Modified the InMemoryDOMDataStore to use the new QueuedNotificationManager class added to yangtools common util for DataChangeListener notifications. Modified DOMDataCommitCoordinatorImpl's ListeningExecutorService to one that off-loads ListenableFuture Runnable callbacks on a separate executor. Change-Id: I31f2fb002131c6d91b205d33255dd1bbc6433d9b Signed-off-by: tpantelis <tpanteli@brocade.com>
Serialization/Deserialization and a host of other fixes - Hande Cluster MemberUp and MemberRemoved events in ShardManager - Cohort messages and close listener messages switched to use protobuff - Distributed Datastore switch messages to use protobuff CreateTransaction CreateTransactionReply CreateTransactionChain CreateTransactionChainReply distributed datastore messages switched to protobuff - ShardManager messages switch to protobuff - DataChanged and other messages switch to protobuf in distributed datastore - Fixed few things found during testing 1. ShardStrategy - setting of configuration 2. NodeToNormalizedNodeBuilder - leaf node/leafsetentry node checks 3. DataChanged event - passing of scope instanceidentifier used during deserialization - Introducing JMX MBeans for distributed datastore -Fixed issues which were preventing remote Shards from talking to each other - Fixed a number of issues related to deserialization - Add distributed datastore to the build - Switch from InstanceIdentifier to YangInstanceIdentifier Change-Id: I0d15dc482cb2b0fb2170b1344bad9fa3b421e8e0 Signed-off-by: Moiz Raja <moraja@cisco.com>
Introducing the Modification classses The purpose of these classes is to capture all modifications are done on a transaction. The reason for capturing these modifications is so that we can persist them to the transaction journal When a member is restarted or a shard is restarted the "Modifications" will be read from the log and replayed on the Shard at which point the Shard can create a new transaction and apply it to the current state Change-Id: I4a9b1c3f28eac5c4d360d743efc44286d8a1acca Signed-off-by: Moiz Raja <moraja@cisco.com>