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>
Remove commons-lang dependencies Use commons-lang3 instead, as it provides better interface anyway. Change-Id: I8574166cf77f8f40c9a2ada4b06cc0d8b14244a9 Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Align tested boolean/Boolean expectations This patch removes implicit boxing/unboxing by aligning boolean/Boolean expectations. Future<Boolean>.get() will return a Boolean, hence use assertEquals() for these (and Optional<Boolean>). Doing that instead of assertTrue()/assertFalse() eliminates a single Eclipse info-level message about Boolean being unboxes. This also has better behavior: if the tested method returns null, we'll get an assertion failure instead of a NPE. For isPersent() and other methods which return a boolean, use assertTrue() or assertFalse(). Doing that instead of assertEquals() eliminates two Eclipse info-level messages about boxing the two arguments to Boolean, for some reason there is no assertEquals(boolean, boolean). Change-Id: If86ef9fb1ecf4cdceb45bc079bba1a86cff311ac 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>
BUG-5280: switch transaction IDs from String to TransactionIdentifier This patch switches primary frontend messages to use TransactionIdentifier instead of plain Strings. Change-Id: Ib04a2e4882dfcc43eea5369bf162889fd7ef5472 Signed-off-by: Robert Varga <rovarga@cisco.com>
BUG-5280: remove support for talking to pre-Boron clients Both transaction chains and transaction identifiers are being changed to structured data. Unfortunately there is no way to reliably map string identifiers from versions prior to Boron in a consistent manner. Pre-Boron messages do not have a concept of a frontend identifier nor its generation. Implementations are assigning them in a non-deterministic order and rely on timestamps to disambiguate between generations. Since Shard-internal state keeping and replication logic will require these concepts, this patch marks a clean break in compatibility. This compatibility is only needed in mixed-version clusters, which have not been validated to work and even if the data store works, it cannot cope with model mismatches expected from differing versions. Change-Id: I168fa0a98be10aebd680ce3323c458aad7f15865 Signed-off-by: Robert Varga <rovarga@cisco.com>
Deprecate CreateTransaction protobuff message Deprecated the associated CreateTransaction and CreateTransactionReply protobuff messages and changed the message classes to extend VersionedExternalizableMessage. Backwards compatibility with pre-boron is maintained. Related code was modified accordingly. One thing of note is wrt CreateTransactionReply. Previously it had a version field that represented the leader shard's version. This is used by the transaction front-end to send the appropriate version for subsequent messages. However the front-end RemoteTransactionContextSupport already knows the leader shard's version from the PrimaryShardInfo which is used for write-only tx's and now the CreateTransaction message so, to be consistent, it now always uses the PrimaryShardInfo's version when creating the context instance. Also I realized that the message versioning would correctly handle backwards compatibility, ie a newer version sending to an older version, but not the other way around. So for a newer version, 2, sending to an older version, 1, the message version would be 1 and would be serialized in the older format and would be correctly de-serialized on the other end. However, for an older version, 1, sending to a newer version, 2, the message version would be 2 but it would be serialized in the older format and, on the other end, the recipient would see the version as 2 and think it's the newer/current version and it may not de-serialize correctly. What we really want is to use the lower of the recipient's version and the sender's version. So I modified the VersionedExternalizableMessage ctor to do that. I had to make a change to ShardTransactionChain but then realized it's no longer used so I just removed it. Change-Id: I18051c48ec4a8f4251e7acef1e1c24063e53ef24 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>