Could not take ownership of lockfile
torbWaterLinked opened this issue · 1 comments
When benchmarking for a disk storage graph library I got this. The directory is made right before the test. A test graph is made if it does not exist in the storage already. .
panic: Could not take ownership of lockfile unitTestGraph/cagesenseAlarm.nodeidx: Could not write lockfile - read result after writing: 1647273004919593180(expected: 1647273007075243120)
Stacktrace:
goroutine 56 [running]:
devt.de/krotik/eliasdb/storage.initByteDiskStorageManager(0xc0008a9980)
/home/torbjorn/go/pkg/mod/devt.de/krotik/eliasdb@v1.2.0/storage/diskstoragemanager.go:657 +0xca8
devt.de/krotik/eliasdb/storage.NewByteDiskStorageManager({0xc00098f5c0, 0x7819e9}, 0x0, 0x0, 0x0, 0x0)
/home/torbjorn/go/pkg/mod/devt.de/krotik/eliasdb@v1.2.0/storage/diskstoragemanager.go:235 +0x1ef
devt.de/krotik/eliasdb/storage.NewDiskStorageManager(...)
/home/torbjorn/go/pkg/mod/devt.de/krotik/eliasdb@v1.2.0/storage/diskstoragemanager.go:101
devt.de/krotik/eliasdb/graph/graphstorage.(*DiskGraphStorage).StorageManager(0xc000b7a030, {0xc0001b43a8, 0x16}, 0x1)
/home/torbjorn/go/pkg/mod/devt.de/krotik/eliasdb@v1.2.0/graph/graphstorage/diskgraphstorage.go:149 +0x125
devt.de/krotik/eliasdb/graph.(*Manager).getIndexHTree(0xc00087c280, {0x77fff7, 0x9}, {0xc00041a158, 0x5}, 0x0, {0x77e7f4, 0x4}, {0x77f747, 0x8})
/home/torbjorn/go/pkg/mod/devt.de/krotik/eliasdb@v1.2.0/graph/helpers.go:316 +0x18d
devt.de/krotik/eliasdb/graph.(*Manager).getNodeIndexHTree(...)
/home/torbjorn/go/pkg/mod/devt.de/krotik/eliasdb@v1.2.0/graph/helpers.go:283
devt.de/krotik/eliasdb/graph.(*Manager).storeOrUpdateNode(0xc00087c280, {0x77fff7, 0x9}, {0x84d370, 0xc000996590}, 0x2)
/home/torbjorn/go/pkg/mod/devt.de/krotik/eliasdb@v1.2.0/graph/graphmanager_nodes.go:243 +0xe9
devt.de/krotik/eliasdb/graph.(*Manager).StoreNode(0xc00087c280, {0x77fff7, 0x9}, {0x84d370, 0xc000996590})
/home/torbjorn/go/pkg/mod/devt.de/krotik/eliasdb@v1.2.0/graph/graphmanager_nodes.go:200 +0x17f
This panic indicates that two processes are modifying the lockfile. What happens is that the process writes a timestamp into the lockfile and tries to read it back. If the timestamp is different by the time it is read back then this panic is thrown. The code which does this can be found here: https://github.com/krotik/common/blob/master/lockutil/lockfile.go#L73