[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 |
||
| Issue Links: |
|
||||||||
| 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:
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 ] |
| Comment by Viera Zelcamova [ 06/Feb/17 ] |
|
re-assignment to the team, to finish the task |