Details
-
Bug
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
1.5.0, 1.5.1, 1.6.0
Description
While looking into slow hsync calls, I noticed an oddity in the way Accumulo processes syncs. Specifically the way closeLock is used in DfsLogger, it seems like the following situation could occur.
- thread B starts executing DfsLogger.LogSyncingTask.run()
- thread 1 enters DfsLogger.logFileData()
- thread 1 writes to walog
- thread 1 locks closeLock
- thread 1 adds sync work to workQueue
- thread 1 unlocks closeLock
- thread B takes sync work off of workQueue
- thread B locks closeLock
- thread B calls sync
- thread 3 enters DfsLogger.logFileData()
- thread 3 writes to walog
- thread 3 blocks locking closeLock
- thread 4 enters DfsLogger.logFileData()
- thread 4 writes to walog
- thread 4 blocks locking closeLock
- thread B unlocks closeLock
- thread 4 locks closeLock
- thread 4 adds sync work to workQueue
- thread B takes sync work off of workQueue
- thread B blocks locking closeLock
- thread 4 unlocks closeLock
- thread B locks closeLock
- thread B calls sync
- thread B unlocks closeLock
- thread 3 locks closeLock
- thread 3 adds sync work to workQueue
- thread 3 unlocks closeLock
In this situation thread 3 unnecessarily has to wait for an extra hsync call. Not sure if this situation actually occurs, or if it occurs very frequently. Looking at the code it seems like it would be nice if sync operations could be queued w/o synchronizing w/ sync operations.
Attachments
Attachments
Issue Links
- is depended upon by
-
ACCUMULO-2632 Research the performance of using compression on the walogs
- Resolved
- links to