View Issue Details

IDProjectCategoryView StatusLast Update
0001569SymmetricDSBugpublic2014-02-15 14:20
ReporterazarubkinAssigned Toelong 
Prioritynormal 
Status closedResolutionfixed 
Product Version3.5.16 
Target Version3.5.17Fixed in Version3.5.17 
Summary0001569: System clock goes too fast
DescriptionSystem clock goes too fast on some Windows XP computers when SymmetricDS runs. This is a known bug in Java (http://bugs.java.com/view_bug.do?bug_id=6464007), and there is a workaround, see the end of mentioned Java bug report.
The bug is exhibited on certain Windows XP HAL DLLs (http://support.microsoft.com/kb/821893/en-us). It is hidden on other HALs.
There is a key for Java VM (-XX:+ForceHighTimeResolution), which should, in theory, fix the bug, but the key handling is also broken: it forces low time resolution despite its name. It still should fix the bug, but it seems it didn't work for me.

Please confirm that the bug exists, and whether it is fixed by applying Java VM switch or suggested workaround.

Thanks!
Steps To Reproduce1. Make sure that Windows XP computer uses one of affected HALs.
2. Run SymmetricDS.
3. After an hour, the system clock drifts away as much as 2-5 minutes.
TagsNo tags attached.

Activities

azarubkin

2014-02-10 02:43

reporter   ~0000471

Update: the Java VM switch is named ForceTimeHighResolution. See http://bugs.java.com/view_bug.do?bug_id=6435126

elong

2014-02-10 10:56

developer   ~0000473

Wouldn't every Java application running multiple threads be affected by this bug? I don't see why each Java server application should be required to implement a long running thread to fix the problem. Isn't the correct place for the fix with the JVM itself or even Microsoft's libraries? There don't seem to be many people complaining about it, so is it even a real issue?

azarubkin

2014-02-11 00:29

reporter   ~0000474

Not every multithreaded Java application is affected. The bug exhibits itself if the application calls Sleep often enough. JVM then issues calls to timeBeginPeriod and timeEndPeriod (to make time quants in Windows smaller - 1 ms in comparison to 10-15 ms by default), which in turn lead to known bug in Microsoft Windows XP and makes system clock go too fast. But without these calls Java applications which want to sleep for 1 ms will sleep for undefined period from 0 to 15 ms, which may be unacceptable for some of them.

I agree with you that it is Microsoft who should fix the bug in the first place, but AFAIK they did so in newer Windows versions. Windows XP is nearing the end of support, and it is unlikely they will fix that old OS.

Oracle did try to fix the JVM with its ForceTimeHighResolution command line switch in 2006, but their implementation was broken from the very beginning: it disabled timeBeginPeriod and timeEndPeriod calls completely, i.e. it effectively forced time low resolution. They have discovered it later, and decided they won't fix it since there may be applications depending on current behavior of this command line switch.
It should fix the bug even in its current state, but it didn't work for me on JVM 1.7.0_52. Maybe they have removed it from newer JVM versions?

The bug can be hidden very easily. It is active on certain Windows HALs only (for example, multiprocessor machines with ACPI). If any single thread in OS issues the call to timeBeginPeriod and sets 1 ms time quants for a long period, there will be no frequent switching of time quants length during that period. Hence, no bug. Any application could fix it system-wide if it makes that call for its own purposes. I think that's why there are not many people complaining.

A long running thread in Java application is exactly what Oracle recommends to work around this issue. I agree that it's not beautiful, and it might put heavier load on system by making timer interrupts (and everything what's tied to them, say threads scheduler) come at 10-15 times more frequent rate. But at least it works, and it masks the bug, makes it not so irritating.

Meanwhile, I have implemented that call in my application, which runs in parallel with SymmetricDS, but not every user of SymmetricDS is a software developer. At least this issue should be mentioned in documentation as "known issue", and Windows XP should be declared not officially supported by SymmetricDS.

elong

2014-02-11 17:15

developer   ~0000475

Thanks for the background, the history is interesting and it helps me to understand better. What if we added a command line argument of "--winxp" for SymmetricLauncher that started the long-running thread first before initializing the rest of the server. It would work with "sym --winxp" on the commmand line and also when run as a Windows service when "--winxp" is added to the sym_service.conf file. Or let me know what you recommend.

azarubkin

2014-02-12 07:21

reporter   ~0000477

Yes, I think that your proposed solution will suffice.

Related Changesets

SymmetricDS: master fdfae529

2014-02-12 08:08:02

erilong

Details Diff
0001569: System clock goes too fast
0001569
mod - symmetric-client/src/main/resources/symmetric-messages.properties Diff File
mod - symmetric-server/src/main/java/org/jumpmind/symmetric/SymmetricLauncher.java Diff File

Issue History

Date Modified Username Field Change
2014-02-10 02:41 azarubkin New Issue
2014-02-10 02:43 azarubkin Note Added: 0000471
2014-02-10 10:56 elong Note Added: 0000473
2014-02-11 00:29 azarubkin Note Added: 0000474
2014-02-11 17:15 elong Note Added: 0000475
2014-02-12 07:21 azarubkin Note Added: 0000477
2014-02-12 08:09 Changeset attached => SymmetricDS trunk r7934
2014-02-12 08:10 elong Status new => resolved
2014-02-12 08:10 elong Fixed in Version => 3.5.17
2014-02-12 08:10 elong Resolution open => fixed
2014-02-12 08:10 elong Assigned To => elong
2014-02-12 08:12 admin Target Version => 3.5.17
2014-02-15 14:20 chenson Status resolved => closed
2015-07-30 21:49 Changeset attached => SymmetricDS master fdfae529