{"push_id":2376461947,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"3d76925f31db8747ba6726e1c0d568441479de6e","before":"8459387c93407382b251f01eca24eba5fdcb4d5f","commits":[{"sha":"3d76925f31db8747ba6726e1c0d568441479de6e","author":{"name":"Thomas Kountis","email":"e98e7931dbcd1979685cf69daa8e75cdbed1ca56@gmail.com"},"message":"Increase write-behind delay in test (#12488)\n\nThere was a fix back in the day to fix this https://github.com/hazelcast/hazelcast/pull/8599,\r\nwhich seems to have worked well so far. However, the test is still assuming perfect timing\r\nbetween instructions which in our build environment is unrealistic.\r\nEspecially when we get reported hiccups such as:\r\n\r\n> 17:20:35, accumulated pauses: 3846 ms, max pause: 1791 ms, pauses over 1000 ms: 2\r\n> 17:20:40, accumulated pauses: 1865 ms, max pause: 532 ms, pauses over 1000 ms: 0\r\n> 17:20:45, accumulated pauses: 81 ms, max pause: 62 ms, pauses over 1000 ms: 0\r\n\r\nI can reproduce the failure by putting a sleep before reading the `timeBeforePut` timestamp.\r\nThe reason this fails is that we don't have insight on when the worker thread, responsible\r\nfor processing the write-behind ops, will kick in, at what intervals.\r\nSo if there is a significant delay before getting the `timeBeforePut` timestamp, and the `put`\r\nthen the write-behind worker will kick in sooner than we anticipated.\r\n\r\nI can't think of any trivial way to approach this, other than increasing drastically\r\nthe `writeDelaySeconds` from 2 secs to 10 secs. An alternative approach could be to keep\r\ntrack of all flushes and assert their intervals, but this would also be error prone,\r\ni.e., dealing with times.","distinct":true,"url":"https://api.github.com/repos/hazelcast/hazelcast/commits/3d76925f31db8747ba6726e1c0d568441479de6e"}]}
{"actor":{"display_login":"tkountis"}}