[CONTROLLER-1580] sal-remoterpc-connector: do not use calendar time for Bucket versions Created: 16/Jan/17  Updated: 25/Jul/23  Resolved: 09/Feb/17

Status: Resolved
Project: controller
Component/s: clustering
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Robert Varga Assignee: Tomas Cere
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Blocks
is blocked by CONTROLLER-1292 Clustering : If only one member have ... Resolved
External issue ID: 7556

 Description   

Current Bucket implementation uses System.currentTimeMillis() for versioning, storing them in a Long.

This is completely wrong, as bucket versions as the assumption being made, that the version are always increasing, when:

  • during DST changes, when calendar time goes back
  • calendar time wraps to negative value

Furthermore it means that we cannot distinguish buckets created in the same millisecond – there is a neat hack to increment the version by one, which is completely useless.

Since we want to maintain binary compatibility, we need to keep on-wire bucket version a Long. Null longs are not allowed, as they cannot be produced by current implementation (and we must never produce them).

To fix versioning here, we will emply a similar strategy to cds-access-api, where we will store versions in akka persistence. Since persisting on each route change would be very slow, we need to split the version space.

Versions are defined to be non-negative longs, i.e. 63 bits. Of these we will steal 31 most significant bits for an 'incarnation number'. The other 32 bits will be used for a 'version number'.

Incarnation Number will be stored in persistence, read/incremented/written every time RpcRegistry starts up.

Version Number is an unsigned 32 bit integer, reset to zero whenever the incarnation number is incremented. Everytime a bucket changes, this version is incremented. Should the version number threaten to overflow, incarnation number is incremented and synchronously persisted before it is sent out.



 Comments   
Comment by Robert Varga [ 16/Jan/17 ]

This is needed for dead peer fail-fast.

Comment by Robert Varga [ 18/Jan/17 ]

master: https://git.opendaylight.org/gerrit/50622

Comment by Viera Zelcamova [ 06/Feb/17 ]

re-assignment to the team, to finish the task

Generated at Wed Feb 07 19:55:54 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.