Summary
Describe the tech debt
The mState variable in the MountTable class is guarded by a read lock and write lock, mainly for its internal mMountTable hash map object. However, when the MountTable.State applies journals, it updates the hash map mMountTable directly without the protection of any lock. This creates some potential data race conditions. This isn't a big issue today as we know that journals are only applied on standby masters and on standby there isn't any read. But to improve the code quality and reduce error-prone code, I believe the mState variable should also update the hash map with the write lock.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.
Summary Describe the tech debt The mState variable in the MountTable class is guarded by a read lock and write lock, mainly for its internal mMountTable hash map object. However, when the MountTable.State applies journals, it updates the hash map mMountTable directly without the protection of any lock. This creates some potential data race conditions. This isn't a big issue today as we know that journals are only applied on standby masters and on standby there isn't any read. But to improve the code quality and reduce error-prone code, I believe the mState variable should also update the hash map with the write lock.
https://github.com/Alluxio/alluxio/blob/master/core/server/master/src/main/java/alluxio/master/file/meta/MountTable.java#L646-L655
One way to fix this is to pass the write lock to the mState object when we initialize it so that it can acquire the lock before it applies journals.
Urgency Not urgent but nice to have to improve the code quality