[CONTROLLER-1265] Clustering: fix time tracking in ShardCommitCoordinator Created: 20/Apr/15 Updated: 31/May/15 Resolved: 31/May/15 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | mdsal |
| Affects Version/s: | Post-Helium |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Robert Varga | Assignee: | Tom Pantelis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 3028 |
| Description |
|
Reviewing of Shard/ShardCommitCoordinator/CohortEntry interactions I found that CohortEntry uses System.currentTimeMilis() to track last access time. System.currentTimeMilis() is based on calender time, so it has things like leap seconds and is affected by NTP. Shard.handleTransactionCommitTimeoutCheck(), which is called periodically can abort a transaction prematurely or fail to take action if the calendar time moves. Use a Guava Stopwatch instead, as that is tied to the platform nanoTime source via a replaceable Ticker (for unit testing). |