[
https://issues.apache.org/jira/browse/OOZIE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059428#comment-14059428
]
Purshotam Shah commented on OOZIE-1923:
---------------------------------------
Yes, most of commands are not reentranted. We noticed this will
Bunndlechangecommand which we recently made synchronous.
Bundle change command acquires lock on bundle job ID and calls up each coord
synchronously for change.
Each coord acquire lock on coord-id, so it good, no issue. They call
BundleStatusUpdateXCommand to update bundle action, which need to acquire lock
on bundle-id.
Which is being held by bundle change command.
And this doesn't throw any exception. Most of our command are requeued, if they
are not able to acquire lock.
In above case BundleStatusUpdateXCommand was requeued multiple times, and it
succeeded finally when bundle change command releases the lock.
This is difficult to notice. We have very strict QE, this is a result of her
effort.
> ZKLocksService locks are not re-entrant like MemoryLocks
> --------------------------------------------------------
>
> Key: OOZIE-1923
> URL: https://issues.apache.org/jira/browse/OOZIE-1923
> Project: Oozie
> Issue Type: Bug
> Components: HA
> Reporter: Purshotam Shah
> Assignee: Purshotam Shah
>
> This is because we are creating InterProcessReadWriteLock instance for every
> path.
> We should store InterProcessReadWriteLock and reuse for same path like
> MemoryLocksService.
> We should also add tests for both ZKLocksService and MemoryLocksService to
> verify.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
