You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However System.currentTimeMillis() should never be used for call timing - as it will not give you correct results. currentTimeMills() will be affected by clock changes (as it represents wall clock) on the OS, this may be NTP adjusting the close (via a skew so timing runs faster than it real time), or a step adjustment in the case of periodic clock resync (without spreading the difference over a period).
So in the case of an abrupt clock jump forward the code could think that there had been a lot longer spent inside the function that actually occurred, causing incorrect interruptions of the deserialization.
The fix would be to switch to System.nanoTime() which is independent of wall clock and hence clock drift
The text was updated successfully, but these errors were encountered:
As I understand the code at e8e8862#diff-ac0a4639bfa0a500bff9ac99c66eaf68c7bcfd92e3b043495844ebe88792024cR38-R55 uses
System.currenttime()
for the timing of the calls.However
System.currentTimeMillis()
should never be used for call timing - as it will not give you correct results.currentTimeMills()
will be affected by clock changes (as it represents wall clock) on the OS, this may be NTP adjusting the close (via a skew so timing runs faster than it real time), or a step adjustment in the case of periodic clock resync (without spreading the difference over a period).So in the case of an abrupt clock jump forward the code could think that there had been a lot longer spent inside the function that actually occurred, causing incorrect interruptions of the deserialization.
The fix would be to switch to
System.nanoTime()
which is independent of wall clock and hence clock driftThe text was updated successfully, but these errors were encountered: