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>
Add new cds-access-api proxies Externalizable serialization format record class hierarchy, which leads to significant overheads. This patch introduces proxies which are are flat, i.e. have java.Object as their superclass, eliminating this overhead. The way we do this is we defined SerialForm interfaces which extend Externalizable and define the serialization protocol in terms of default methods. We then define a bunch of classes which are pure data holders implementing individual SerialForms. Also ensure messages properly implement cloneAsVersion() to propagate the target version, now that it matters for them. Finally audit use of java.io.Serial so that we do not import it -- it is just pure overhead vs. using @java.io.Serial directly. JIRA: CONTROLLER-2051 Change-Id: I01132665027687edc1c6d44dda8a6ab0cab6ad6a Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
More cds-access-api cleanup Fixup previous patch and sprinkle more @Serial annotations. Change-Id: I74414861197bb417dadc445ebc3fc2703a97ea4d Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Promote cds-access-api This API is no longer @Beta. Change-Id: If81e77c8b2c9dc2fcfa6bcd94f58426c75f6cd0a Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Reduce JSR305 proliferation retention=runtime annotations are mixing really badly with Java EE injection and Java 11. Make sure we do not use javax.annotation package in APIs and reduce overall proliferation inside implementations. Change-Id: I569815f0336efdc0de662c3b80f0fa6e5dd47d8a Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Fix CS warnings in cds-access-api and enable enforcement Fixed checkstyle warnings and enabled enforcement. Most of the warnings/changes were for: - variable name too short - correct ordering of @Nonnull annotations - line too long - suppressing CS RedundantModifier warning for ctors where public is needed for packaged-scoped classes that implement Externalizable - adding protected to ctors for packaged-scoped abstract classes that implement Externalizable to avoid CS RedundantModifier warning - local vars/params hiding a field - putting overloaded methods close to one another Change-Id: Ib85e15f21118f3484ccb8e945e8257ae3e3278bc Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
BUG-5280: separate request sequence and transmit sequence Clean up the confusion in sequence numbers. There are actually two sequences: - logical request sequence, which indicates the order of requests in which they should be applied to the target entity. It is assigned by logic emitting the request. - transmit sequence within a connection to the backend, as initiated by ConnectClientRequest. It is assigned by SequencedQueue as it is transmitting requests and reset when a new connection to the backend is made. This requires establishing the concept of a session, which is a single conversation between frontend and backend. It is severed whenever the frontend times out and re-established when the leader is found and it responds with ConnectClientSuccess. The sending of ConnectClientRequest is not done via the queue, as it is part of backend resolution process. Since this is not a performance-critical path, we use simple Patterns.ask() to send the request and get completion notification -- which we then translate to ShardBackendInfo. ConnectClientSuccess gives us backend-preferred version and backend-specified cap on the number of outstanding messages then it can handle concurrently. This maximum is used to limit the transmit path of SequencedQueue, so that it does not attempt to send more requests at any given time. Internal queue for unsent requests is kept unbounded for now, subject to a Semaphore-driven throttle in a follow-up patch. Change-Id: I61663073bf6632c1ed8c036dee37f1ac39cf7794 Signed-off-by: Robert Varga <rovarga@cisco.com>
BUG-5280: add client connect messages When a frontend is attempting to re-establish communication with the backend it sends its coordinates and various other information to a backend. Sending ConnectClientRequest initiates a handshake, to which the backend will respond either with a failure, or with an adjusted ConnectClientSuccess. Change-Id: I58ba9a2103f80e528654222f82f07416f7d7815e Signed-off-by: Robert Varga <rovarga@cisco.com>