View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001569 | SymmetricDS | Bug | public | 2014-02-10 07:41 | 2014-02-15 19:20 |
| Reporter | azarubkin | Assigned To | elong | ||
| Priority | normal | ||||
| Status | closed | Resolution | fixed | ||
| Product Version | 3.5.16 | ||||
| Target Version | 3.5.17 | Fixed in Version | 3.5.17 | ||
| Summary | 0001569: System clock goes too fast | ||||
| Description | System 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 Reproduce | 1. 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. | ||||
| Tags | No tags attached. | ||||
|
|
Update: the Java VM switch is named ForceTimeHighResolution. See http://bugs.java.com/view_bug.do?bug_id=6435126 |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
Yes, I think that your proposed solution will suffice. |
|
SymmetricDS: master fdfae529 2014-02-12 08:08:02 erilong Details Diff |
0001569: System clock goes too fast |
Affected Issues 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 | ||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-02-10 07:41 | azarubkin | New Issue | |
| 2014-02-10 07:43 | azarubkin | Note Added: 0000471 | |
| 2014-02-10 15:56 | elong | Note Added: 0000473 | |
| 2014-02-11 05:29 | azarubkin | Note Added: 0000474 | |
| 2014-02-11 22:15 | elong | Note Added: 0000475 | |
| 2014-02-12 12:21 | azarubkin | Note Added: 0000477 | |
| 2014-02-12 13:09 | Changeset attached | => SymmetricDS trunk r7934 | |
| 2014-02-12 13:10 | elong | Status | new => resolved |
| 2014-02-12 13:10 | elong | Fixed in Version | => 3.5.17 |
| 2014-02-12 13:10 | elong | Resolution | open => fixed |
| 2014-02-12 13:10 | elong | Assigned To | => elong |
| 2014-02-12 13:12 | admin | Target Version | => 3.5.17 |
| 2014-02-15 19:20 | chenson | Status | resolved => closed |
| 2015-07-31 01:49 | Changeset attached | => SymmetricDS master fdfae529 |