[
https://issues.apache.org/jira/browse/OOZIE-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13709907#comment-13709907
]
Robert Kanter commented on OOZIE-1456:
--------------------------------------
We synchronize on {{locks}} while getting the lock, so if two threads try to do
that at the same time, only one can actually do it (the other will block).
Once the first thread acquired the lock, the second thread will see that the
lock was already created and instead of doing {{lockEntry = new
ReentrantReadWriteLock(true);}} it will actually do {{lockEntry =
locks.get(resource);}}. So, yes they will get the same exact lock at the same
time. However, this is okay (and actually expected). After getting the lock,
they then try to actually lock the lock; at which point, only one of them can
actually do this. The second thread will either block until the first thread
releases the lock or will timeout while waiting and give up.
Also, in your log snippet, it's acquired two different locks: one is for
{{0012816-130326154523555-oozie-oozi-C}} and the other is for
{{0055279-130607113249683-oozie-oozi-C}} so I don't see a problem here.
> MemoryLocks.getLock() doesn't work
> ----------------------------------
>
> Key: OOZIE-1456
> URL: https://issues.apache.org/jira/browse/OOZIE-1456
> Project: Oozie
> Issue Type: Bug
> Reporter: Shwetha G S
> Priority: Critical
>
> {code:java}
> private LockToken getLock(String resource, Type type, long wait) throws
> InterruptedException {
> ReentrantReadWriteLock lockEntry;
> synchronized (locks) {
> if (locks.containsKey(resource)) {
> lockEntry = locks.get(resource);
> }
> else {
> lockEntry = new ReentrantReadWriteLock(true);
> locks.put(resource, lockEntry);
> }
> }
> Lock lock = (type.equals(Type.READ)) ? lockEntry.readLock() :
> lockEntry.writeLock();
> if (wait == -1) {
> lock.lock();
> }
> else {
> if (wait > 0) {
> if (!lock.tryLock(wait, TimeUnit.MILLISECONDS)) {
> return null;
> }
> }
> else {
> if (!lock.tryLock()) {
> return null;
> }
> }
> }
> synchronized (locks) {
> if (!locks.containsKey(resource)) {
> locks.put(resource, lockEntry);
> }
> }
> return new LockToken(lockEntry, lock, resource);
> }
> {code}
> If there are 2 concurrent threads trying to acquire lock on same key and lock
> is free, both will get lockEntry = new ReentrantReadWriteLock(true); and both
> will get the same lock!
> Here is the log from oozie:
> 2013-07-12 14:48:32,503 DEBUG CoordActionInputCheckXCommand:545 - USER[-]
> GROUP[-] TOKEN[-] APP[-] JOB[0012816-130326154523555-oozie-oozi-C]
> ACTION[0012816-130326154523555-oozie-oozi-C@154290] Acquired lock for
> [0012816-130326154523555-oozie-oozi-C] in [coord_action_input]
> 2013-07-12 14:48:32,503 DEBUG CoordMaterializeTransitionXCommand:545 -
> USER[fetl] GROUP[-] TOKEN[] APP[<coord name>]
> JOB[0012816-130326154523555-oozie-oozi-C] ACTION[-] Acquired lock for
> [0055279-130607113249683-oozie-oozi-C] in [coord_mater]
> After this the materialization was stuck and we had to bounce oozie. Still
> need to figure out why this paused materialization
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
