[
https://issues.apache.org/jira/browse/HDDS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16617224#comment-16617224
]
Nanda kumar commented on HDDS-475:
----------------------------------
Thanks [~ljain] for finding the root cause.
{quote}Why do we take a read lock in allocateBlock call?
{quote}
Previously there was {{ReentrantLock}} in place of {{ReentrantReadWriteLock}}
which was affecting the performance of {{allocateBlock}}. As part of
performance optimization, this change was done and we started using read lock
for {{allocateBlock}}.
You're right, we don't need any lock in {{BlockManagerImpl}} as all the
underlying code are protected with proper locking mechanism. We will still be
needing synchronized blocks inside allocateBlock to protect the usage of
containers which are in ALLOCATED state.
[~xyao]
{quote}Does this happen in a tight loop?
{quote}
It does look like it's running in a very tight loop. Ideally, we should be
using the containers in OPEN state in a round-robin fashion, which should have
helped us. In this case, it also looks like there is only one container in OPEN
state ( or our performance skyrocketed and we did a full round of OPEN
containers within a millisecond ;) )
> Block Allocation returns same BlockID on different keys creation
> ----------------------------------------------------------------
>
> Key: HDDS-475
> URL: https://issues.apache.org/jira/browse/HDDS-475
> Project: Hadoop Distributed Data Store
> Issue Type: Bug
> Reporter: Lokesh Jain
> Assignee: Lokesh Jain
> Priority: Blocker
>
> BlockManagerImpl#allocateBlock returns same BlockID. This leads to different
> key creations getting the same blockId.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
