[jira] Subscription: Oozie Patch Available
Issue Subscription Filter: Oozie Patch Available (54 issues) Subscriber: ooziedaily Key Summary OOZIE-2272 Use Hadoop's CredentialProvider for passwords in oozie-site https://issues.apache.org/jira/browse/OOZIE-2272 OOZIE-2271 Upgrade Tomcat to 6.0.44 https://issues.apache.org/jira/browse/OOZIE-2271 OOZIE-2266 [core] Fix 'total' actions returned in coordinator job info https://issues.apache.org/jira/browse/OOZIE-2266 OOZIE-2262 Fix log streaming from other server with start/end filter https://issues.apache.org/jira/browse/OOZIE-2262 OOZIE-2258 Introducing a new counter in the instrumentation log to distinguish between the reasons for launcher failure https://issues.apache.org/jira/browse/OOZIE-2258 OOZIE-2251 Expose instrumental matrices in Realtime Graphing tool https://issues.apache.org/jira/browse/OOZIE-2251 OOZIE-2250 Show log for WAITING and TIMEDOUT coord actions https://issues.apache.org/jira/browse/OOZIE-2250 OOZIE-2245 Service to periodically check database schema https://issues.apache.org/jira/browse/OOZIE-2245 OOZIE-2244 Oozie should mask passwords in the logs when logging command arguments https://issues.apache.org/jira/browse/OOZIE-2244 OOZIE-2243 Kill Command does not kill the child job for java action https://issues.apache.org/jira/browse/OOZIE-2243 OOZIE-2203 Fix the login example https://issues.apache.org/jira/browse/OOZIE-2203 OOZIE-2196 Create Local Client for Bundle https://issues.apache.org/jira/browse/OOZIE-2196 OOZIE-2187 Add a way to specify a default JT/RM and NN https://issues.apache.org/jira/browse/OOZIE-2187 OOZIE-2168 Oozie flow and action names have 50 char limit https://issues.apache.org/jira/browse/OOZIE-2168 OOZIE-2159 'oozie validate' command should be moved server-side https://issues.apache.org/jira/browse/OOZIE-2159 OOZIE-2134 Remove references to Services.get().getConf() in code https://issues.apache.org/jira/browse/OOZIE-2134 OOZIE-2106 Make tomcat download url configurable in the pom file https://issues.apache.org/jira/browse/OOZIE-2106 OOZIE-2105 Make version of submodules configurable with parent version https://issues.apache.org/jira/browse/OOZIE-2105 OOZIE-2099 Add test-patch support for patches generated without --no-prefix https://issues.apache.org/jira/browse/OOZIE-2099 OOZIE-2081 WorkflowJob notification to include coordinator action id https://issues.apache.org/jira/browse/OOZIE-2081 OOZIE-2060 Incorrect documentation of Java action config XML filename https://issues.apache.org/jira/browse/OOZIE-2060 OOZIE-2044 ssh action succeed with a not exists command which should be fail. https://issues.apache.org/jira/browse/OOZIE-2044 OOZIE-2030 Configuration properties from global section is not getting set in Hadoop job conf when using sub-workflow action in Oozie workflow.xml https://issues.apache.org/jira/browse/OOZIE-2030 OOZIE-2020 Rerun all Failed/killed/timedout coordinator actions rather than specifying action numbers https://issues.apache.org/jira/browse/OOZIE-2020 OOZIE-1980 Sql error should not fail coord job https://issues.apache.org/jira/browse/OOZIE-1980 OOZIE-1977 Display patch analysis issues https://issues.apache.org/jira/browse/OOZIE-1977 OOZIE-1936 Queuedump command should display queue information for all server. https://issues.apache.org/jira/browse/OOZIE-1936 OOZIE-1931 Admin command to print all locks held by server(s) https://issues.apache.org/jira/browse/OOZIE-1931 OOZIE-1927 Use StoreStatusFilter for WorkflowsJobGetJPAExecutor https://issues.apache.org/jira/browse/OOZIE-1927 OOZIE-1922 MemoryLocksService fails if lock is acquired multiple times in same thread and released https://issues.apache.org/jira/browse/OOZIE-1922 OOZIE-1918 ActionXCommand refactoring for code reuse https://issues.apache.org/jira/browse/OOZIE-1918 OOZIE-1860 Oozie job mapper launch fails due to null value returned from action file https://issues.apache.org/jira/browse/OOZIE-1860 OOZIE-1855 TestPriorityDelayQueue#testPoll failed intermittently in Jenkins https://issues.apache.org/jira/browse/OOZIE-1855 OOZIE-1816 LogInfo uses action name instead of id https://issues.apache.org/jira/browse/OOZIE-1816 OOZIE-1810 Workflow cannot get into Failed state when kill control node cannot resolve variable in message https://issues.apache.org/jira/browse/OOZIE-1810 OOZIE-1802 Support workflow action log https://issues.apache.org/jira/browse/OOZIE-1802 OOZIE-1793 Improve find bugs reporting for Oozie https://issues.apache.org/jira/browse/OOZIE-1793 OOZIE-1782 Workflow path not found is thr
[jira] [Updated] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released
[
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Azrael Seoeun updated OOZIE-1922:
-
Attachment: OOZIE-1922.3.patch
OOZIE-1922.2.patch included wrong file. I upload the fixed one.
> MemoryLocksService fails if lock is acquired multiple times in same thread
> and released
> ---
>
> Key: OOZIE-1922
> URL: https://issues.apache.org/jira/browse/OOZIE-1922
> Project: Oozie
> Issue Type: Bug
>Reporter: Purshotam Shah
>Assignee: Azrael Seoeun
> Attachments: OOZIE-1922.1.patch, OOZIE-1922.2.patch,
> OOZIE-1922.3.patch
>
>
> ReentrantLock can be acquired multiple times in same thread. For multiple
> acquire call, ReentrantLock hold count is incremented by one.
> So if we acquire lock multiple time from same thread, all will be successful
> and hold count is increased for every call.
> But if we release lock, MemoryLocksService ignore the count and deletes the
> lock. Even if it's held by some command.
> Simple step can reproduce it.
> {code}
> service.getWriteLock("test", 5000); //writeHoldCount = 1
> MemoryLockToken lock = (MemoryLockToken)service.getWriteLock("test",
> 5000); //writeHoldCount = 2
> lock.release(); //writeHoldCount = 1
> lock = (MemoryLockToken)service.getWriteLock("test", 5000);
> //writeHoldCount = 1, it should be 2.
> {code}
> {code}
> @Override
> public void release() {
> int val = rwLock.getQueueLength();
> if (val == 0) {
> synchronized (locks) {
> locks.remove(resource);
> }
> }
> lock.unlock();
> }
> }
> {code}
> MemoryLocks should check hold count before removing lock.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released
[
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Azrael Seoeun updated OOZIE-1922:
-
Attachment: OOZIE-1922.2.patch
Upload new patch rebased on the latest branch.
> MemoryLocksService fails if lock is acquired multiple times in same thread
> and released
> ---
>
> Key: OOZIE-1922
> URL: https://issues.apache.org/jira/browse/OOZIE-1922
> Project: Oozie
> Issue Type: Bug
>Reporter: Purshotam Shah
>Assignee: Azrael Seoeun
> Attachments: OOZIE-1922.1.patch, OOZIE-1922.2.patch
>
>
> ReentrantLock can be acquired multiple times in same thread. For multiple
> acquire call, ReentrantLock hold count is incremented by one.
> So if we acquire lock multiple time from same thread, all will be successful
> and hold count is increased for every call.
> But if we release lock, MemoryLocksService ignore the count and deletes the
> lock. Even if it's held by some command.
> Simple step can reproduce it.
> {code}
> service.getWriteLock("test", 5000); //writeHoldCount = 1
> MemoryLockToken lock = (MemoryLockToken)service.getWriteLock("test",
> 5000); //writeHoldCount = 2
> lock.release(); //writeHoldCount = 1
> lock = (MemoryLockToken)service.getWriteLock("test", 5000);
> //writeHoldCount = 1, it should be 2.
> {code}
> {code}
> @Override
> public void release() {
> int val = rwLock.getQueueLength();
> if (val == 0) {
> synchronized (locks) {
> locks.remove(resource);
> }
> }
> lock.unlock();
> }
> }
> {code}
> MemoryLocks should check hold count before removing lock.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
