You guys are never stop. I will keep my eye out for it.
Thanks
Kevin
Is there any chance these memory management issues would also affect the original (V20 and below) driver?
I’m experiencing complete loss of all tags for several seconds at a time (“pink-out”) that appears to correlate with ClockDriftDetector events. I’ve already switched to the G1 garbage collector and substantially increased the memory allocated to ignition. These help reduce the frequency but do not eliminate the problem. FWIW, the G1GC is awesome – once started, with a 100ms GC pause target, the worst pause-the-world event that shows in the javagc log tends to be on the order of 40ms. In contrast, the ClockDriftDetector events usually report delays greater the 2500ms.
Hi pturmel,
I've been dealing with this problem for a while and couldn't find the solution. ClockDriftDetector and CIP connection reset. I know your post was 8 years ago, hard for you to remember but you might be the only one who knows the root cause. Can you please see my attached image and advise!
IIRC, it was stalls in the JVM due to memory leakage that caused both the ClockDrift warnings and the loss of communications errors. In other words, the driver's response timeouts were expiring during the stall, causing the reconnect cycle. The memory leak was the root cause. The driver comm loss was an effect of the stalls.
Use java's tools for your JVM version to capture heap dumps. Take one soon after a restart to establish a baseline. Take more when memory consumption is becoming pathological (shallow sawtooth pattern close to max allowed). I recommend VisualVM for reviewing .hprof files.
1 Like