- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Lisa's fix is a classic antipattern as many have noted. Better to wait for confirmation and have a nightly (or hourly, if security is paramount) cleanup job that removes danglers. Programmers making "on the fly" delay loop decisions is a legendary source of headaches for sysadmins and maintenance programmers.
Lisa, replying here, has noted that it is pragmatically correct to do a "kick the can down the road" solution (i.e. manually sync the clocks on both systems and pop in a guesstimate timeout) as an interim measure while coding up a solution using a common time source (network time or better yet the database host) and maintenance job. The only hazard is if management is told that the problem is "fixed" in which case the interim solution becomes permanent. Management needs to be told that the program is hideously broken and causing hours of work every day, while the real solution is being built and rolled out. Pragmatism doesn't stop at the keyboard. ;)
You don't run NTP on virtual machines (which are now commonplace nearly to the point of ubiquity). You run NTP on the hypervisor and the virtual machine's clock will always be correct instead of being in a constant state of flux due to NTP adjustments competing with VM resource allocation. NTP is for physical servers only.
Buwahaha, Dr. λ got owned - better go back to the kitchen!