* Add test case for Locking after Merge
* retain lock file after merge
* remove replacing lock file (not needed)
Co-authored-by: James Mills <prologic@shortcircuit.net.au>
Co-authored-by: yash <yash.chandra@grabpay.com>
* add failing test case to highlight the race condition on bug
note : the test "TestLock" is non deterministic, its outcome depends
on the sequence of instructions yielded by the go scheduler on each run.
There are two values, "goroutines" and "succesfulLockCount", which can
be edited to see how the test performs.
With the committed value, resp "20" and "50", I had a 100% failure on
my local machine, running linux (Ubuntu 20.04).
Sample test output :
$ go test . -run TestLock
--- FAIL: TestLock (0.17s)
lock_test.go:91: [runner 14] lockCounter was > 1 on 5 occasions, max seen value was 2
lock_test.go:91: [runner 03] lockCounter was > 1 on 2 occasions, max seen value was 3
lock_test.go:91: [runner 02] lockCounter was > 1 on 3 occasions, max seen value was 3
lock_test.go:91: [runner 00] lockCounter was > 1 on 1 occasions, max seen value was 2
lock_test.go:91: [runner 12] lockCounter was > 1 on 7 occasions, max seen value was 3
lock_test.go:91: [runner 01] lockCounter was > 1 on 8 occasions, max seen value was 2
lock_test.go:91: [runner 04] lockCounter was > 1 on 6 occasions, max seen value was 4
lock_test.go:91: [runner 13] lockCounter was > 1 on 1 occasions, max seen value was 2
lock_test.go:91: [runner 17] lockCounter was > 1 on 4 occasions, max seen value was 2
lock_test.go:91: [runner 10] lockCounter was > 1 on 3 occasions, max seen value was 2
lock_test.go:91: [runner 08] lockCounter was > 1 on 6 occasions, max seen value was 2
lock_test.go:91: [runner 09] lockCounter was > 1 on 4 occasions, max seen value was 2
lock_test.go:91: [runner 05] lockCounter was > 1 on 1 occasions, max seen value was 2
lock_test.go:91: [runner 19] lockCounter was > 1 on 3 occasions, max seen value was 3
lock_test.go:91: [runner 07] lockCounter was > 1 on 4 occasions, max seen value was 3
lock_test.go:91: [runner 11] lockCounter was > 1 on 9 occasions, max seen value was 2
lock_test.go:91: [runner 15] lockCounter was > 1 on 1 occasions, max seen value was 3
lock_test.go:91: [runner 16] lockCounter was > 1 on 1 occasions, max seen value was 3
FAIL
FAIL github.com/prologic/bitcask 0.176s
FAIL
* flock: create a wrapper module, local to bitcask, around gofrs.Flock
the racy TestLock has been moved to bitcask/flock
* flock: add test for expected regular locking behavior
* flock: replace gofrs/flock with local implementation
* update go.sum
* Add build constraint for flock_unix.go
Co-authored-by: James Mills <prologic@shortcircuit.net.au>
* new merge approach
* code refactor
* comment added
* isMerging flag added to allow 1 merge operation at a time
* get api modified. merge updated (no recursive read locks)
Co-authored-by: yash <yash.chandra@grabpay.com>
Co-authored-by: James Mills <prologic@shortcircuit.net.au>
* live backup first commit
* exclude lock file in backup
* create path if not exist for backup
Co-authored-by: yash <yash.chandra@grabpay.com>
Co-authored-by: James Mills <prologic@shortcircuit.net.au>
