Github user hanm commented on the issue:
https://github.com/apache/zookeeper/pull/333
Committed to master: 0706b40afad079f19fe9f76c99bbb7ec69780dbd
Pending JIRA resolve after fixing merge conflicts and commit into
branch-3.4 and 3.5.
---
If your project is set up for it, you
Github user hanm commented on the issue:
https://github.com/apache/zookeeper/pull/333
>> it seems best to keep snapshot taking a lighter weight operation.
Sounds reasonable.
>> I am unable to reproduce the test failure in Zab1_0Test
I think it's a flaky test.
Github user enixon commented on the issue:
https://github.com/apache/zookeeper/pull/333
I am unable to reproduce the test failure in Zab1_0Test
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user enixon commented on the issue:
https://github.com/apache/zookeeper/pull/333
We contemplated doing an fsync for every snapshot and decided against.
You're taking a guaranteed io spike each time. That's fine when you're just
syncing with the quorum but during normal operatio
Github user hanm commented on the issue:
https://github.com/apache/zookeeper/pull/333
I am now wondering why we should not fsync snapshot taking at all cases. It
seems to be a useful property to have for snapshot serialization, and will make
code simpler. Any performance consideration
Github user enixon commented on the issue:
https://github.com/apache/zookeeper/pull/333
AtomicFileOutputStream performs an fsync when the stream is closed with the
following.
"((FileOutputStream) out).getFD().sync();"
---
If your project is set up for it, you can reply to this e
