You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current method of creating lock files is mostly good enough, especially with the recent testing by QuickCheck. However, it's probably a good idea to use the rename method used by riak_core_util:replace_file/2. h/t @gburd for reminding me.
The text was updated successfully, but these errors were encountered:
There have been a number of flare-ups on this front, lately, #163, etc. Ideally we'd write a test to exhibit the problem then work on getting it fixed. Relatedly, basho/riak#535 should be worked on to handle the numerous stale lockfile on startup issues that we've been seeing.
My proposal would be to consolidate all bugs into this bug and 535, to make the actual state of things clear.
…le creation
Previous to this change, the OS pid was used to lock the bitcask database
and prevent two bitcask instances performing write operations at the same
time. However, if bitcask is not able to clean up the write locks because
of a hard shutdown and another process takes that the pid in written to
the lock file, bitcask is not able to take the lock even though it is the
only running instance.
This change uses the flock system call to obtain exclusive write access
to the file across OS processes, as long as the other processes use flock
to obtain the lock.
The current method of creating lock files is mostly good enough, especially with the recent testing by QuickCheck. However, it's probably a good idea to use the rename method used by
riak_core_util:replace_file/2
. h/t @gburd for reminding me.The text was updated successfully, but these errors were encountered: