Remove ABIVersion.MAGNESIUM This ABI versions is quite inefficient in its serialization and has been deprecated in the previous release. This patch completes its removal. JIRA: CONTROLLER-2062 Change-Id: I03be0d6561c4db2893e6eb0fd95e3a35e655b76e Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Clean up use of MockitoAnnotations.initMocks Using MockitoAnnotations.initMocks() is deprecated, use JUnitRunner in cds-access-client and sal-clustering-commons. Change-Id: I10b52bfd0a989f722538e3983352c4465f918950 Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Use OptionalLong in AbstractClientConnection This removes the need for boxing longs. Change-Id: I73a6c0be7f9a662f9e1df884f46adbc0fc121fb1 Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Improve error reporting for tell-based reads Added contextual info similar to ask-based, including the yang path of the requested read and the backend shard name. Also wrapped RequestTimeoutException with DataStoreUnavailableException. Change-Id: I5487e5531034cc1abbda27a4953897da7212eba8 Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Remove unused exceptions This drops exception declarations which are never used. Change-Id: Icc8938b9c3b437a0d5961ec1b481fd06c52d47f2 Signed-off-by: Stephen Kitt <skitt@redhat.com>
Slice front-end request messages Added infrastructure to use the MessageSlicer to slice SliceableMessages in the TransmitQueue.Transmitting class on the front-end. A MessageAssembler is used on the Shard side to re-assemble. Currently only the front-end ModifyTransactionRequest is a SliceableMessage as it contains a NormalizedNode which can be arbitrarily large - the others are small and don't require slicing. Change-Id: I7b09e4864e19d3fdb215c2b9dbcb64c14b6a143c Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Bug 8619: Introduce inheritance of progress trackers + Introduce cancelDebt method. + Use the newly introduced functionality in client code. + Delete unused copy constructors (including unit test). Change-Id: Ib976343ed5f50c649ea08206c897cb70dead8b86 Signed-off-by: Vratko Polak <vrpolak@cisco.com> Signed-off-by: Robert Varga <robert.varga@pantheon.tech> (cherry picked from commit 12b4928ef66a82f4a128a11701663ac23143c1d7)
Make AbstractClientConnection timeouts configurable So we can tweak them in production and unit tests. Change-Id: I39ce8cdf3cd5397a71f52c42357943dfe5eccb7c Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
BUG-8422: separate retry and request timeouts This patch corrects a thinko around request timeouts, where we reconnect the connection based on request timeout, not based on the 'try' timeout. The difference between the two is that the 'try' timeout is the period we allow the backend to respond to our request and when it does not, we reconnect the connection. Change-Id: I8c00a80e5c26c5b829056c43fe78a0567041bc5e Signed-off-by: Robert Varga <robert.varga@pantheon.tech> Signed-off-by: Tomas Cere <tcere@cisco.com> (cherry picked from commit f32b44f6e2dac23938a2c01638872c65ba1237f5)
Use guava-testlib's FakeTicker Rather than rolling our own, use the Ticker class available in guava-testlib. Change-Id: If3d1abec6aad20b439e19fbd48d961b7582aa607 Signed-off-by: Robert Varga <rovarga@cisco.com>
BUG-5280: add executionTimeNanos In order to properly measure impact of requests on the backend we nead some indication of the complexity involved in servicing the request. It is not feasible to estimate this by analyzing the request itself, hence we provide a way for the backend to communicate how complex it found a request to be back to the frontend. Since this measure excludes actor inbox and transport latency, the frontend can use this measure to weigh the relative complexity compared to other requests in has sent. Change-Id: Ia7f435ff8a7fd995a90261b128832c340026de6d Signed-off-by: Robert Varga <rovarga@cisco.com>
BUG-5280: add AbstractClientConnection Introduce a connection concept. This is a replacement for the request queue, as it turns out we do need the concept of a full connection (e.g. generational logic). This comes from the need to sensibly switch behaviors as the locality of the backend leader changes. This patch implements two sets of strategies for dealing with reconnect: The first one assumes long-lived state and is used for proxies dealing with histories. Here we make sure to reinstantiate and replace them in a map, as we want new transactions to follow the new semantic and we do not want to tear histories down or follow inefficient paths. The second one assumes short-lived state and is used for proxies dealing with individual transactions. Transactions are assumed to come and go rapidly and therefore we do not replace the proxies in maps (as they will be short-lived), but rather forwards operations to successors. The first strategy has a higher access cost, but its state is always fully uptodate when reconnect finishes, while the second strategy favor access time, but operations end up "trailing" and will be forwarded (and hence inefficient) until the transaction completes. Change-Id: I7fd9e21c749f55b91229bf0b671c8dcf2e4d5982 Signed-off-by: Robert Varga <rovarga@cisco.com>