date:20151228

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Rohini Palaniswamy (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073147#comment-15073147
 ] 

Rohini Palaniswamy commented on OOZIE-1922:
---

bq. I don't think we will ever support readlocks. We don't have to convolute 
our logic. I will put TODO in code for readlock support.
  I would prefer that we rather use the correct logic instead instead of TODO 
as it is simple to fix.  It is just couple more conditions which do not cost 
much. Don't like the idea of breaking it considering that the rest of code for 
read locks is good even though not used.

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, 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] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Purshotam Shah (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073149#comment-15073149
 ] 

Purshotam Shah commented on OOZIE-1922:
---

It's not that simple, mainly for ZKlock. We need to use getParticipantNodes() 
in logic. This will call ZK every time, why to make unnecessary calls if we are 
not going to use it.

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, 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] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Rohini Palaniswamy (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073168#comment-15073168
 ] 

Rohini Palaniswamy commented on OOZIE-1922:
---

bq. It's not that simple, mainly for ZKlock. We need to use 
getParticipantNodes() in logic
  Why do you need getParticipantNodes() in logic. You just need to remove from 
local hashmap when no thread in that jvm holds the lock anymore. It should not 
matter if another node has a lock.

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, 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)

Re: Review Request 41623: OOZIE-1922 - MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Purshotam Shah



> On Dec. 22, 2015, 11:04 p.m., Rohini Palaniswamy wrote:
> > core/src/main/java/org/apache/oozie/service/ZKLocksService.java, line 201
> > 
> >
> > readWriteLock != null - Instead of adding this condition in multiple 
> > places, either put the whole logic in 
> > 
> > if (readWriteLock != null) {
> > 
> > }
> > 
> > block or make the InterProcessReadWriteLock also part of ZKLockToken 
> > like MemoryLockToken so that you don't have to retrieve from hashmap.

Not sure if i understand this. After removing 
lock.getParticipantNodes().size(), it should be ok.


> On Dec. 22, 2015, 11:04 p.m., Rohini Palaniswamy wrote:
> > core/src/test/java/org/apache/oozie/service/TestZKLocksService.java, line 
> > 508
> > 
> >
> > Test case is most likely flaky. It needs to be changed to make the 
> > other thread acquire the lock after the thread that acquired the lock first 
> > released it. With current logic mostly only one thread will acquire the 
> > lock and release before the assert statement or if the other thread 
> > acquired the lock during sleep(1000), then test will fail. 
> > 
> > Also need a new testcase testReentrantSameThread() - to test reentrant 
> > behaviour in same thread.

>Also need a new testcase testReentrantSameThread() - to test reentrant 
>behaviour in same thread.

There is already a testcase for that, testReentrantMultipleCall.

The behaviour of testcases is that only one thread should be able to acquire 
the lock. Upon release, entry should be removed from hashmap. This was an 
existing testcase, but testcases was incorrect, so I changed it.


- Purshotam


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41623/#review111682
---


On Dec. 22, 2015, 1:11 a.m., Purshotam Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41623/
> ---
> 
> (Updated Dec. 22, 2015, 1:11 a.m.)
> 
> 
> Review request for oozie.
> 
> 
> Bugs: OOZIE-1922
> https://issues.apache.org/jira/browse/OOZIE-1922
> 
> 
> Repository: oozie-git
> 
> 
> Description
> ---
> 
> OOZIE-1922 - MemoryLocksService fails if lock is acquired multiple times in 
> same thread and released
> 
> 
> Diffs
> -
> 
>   core/src/main/java/org/apache/oozie/lock/MemoryLocks.java 
> ee564b3def2ce42b06f697c3384b1e102ac6a3ba 
>   core/src/main/java/org/apache/oozie/service/MemoryLocksService.java 
> e3eccdb3f95e74198c3d42d19022b4acfc3d18e5 
>   core/src/main/java/org/apache/oozie/service/ZKLocksService.java 
> e3a6bcf04048e140d2ced9d8bdbfe08b01b323e4 
>   core/src/test/java/org/apache/oozie/lock/TestMemoryLocks.java 
> 0efe31033f63055c08e42202c56c336248271afe 
>   core/src/test/java/org/apache/oozie/service/TestZKLocksService.java 
> 02cc1372dc015713f0bb1f6861b7e4b7455c4f13 
> 
> Diff: https://reviews.apache.org/r/41623/diff/
> 
> 
> Testing
> ---
> 
> TestZKLocksService.testReentrantMultipleCall already has reentrant test cases.
> 
> 
> Thanks,
> 
> Purshotam Shah
> 
>

Build failed in Jenkins: oozie-trunk-precommit-build #2689

2015-12-28 Thread Apache Jenkins Server

See 

--
[...truncated 8427 lines...]
[INFO] Tests are skipped.
[INFO] 
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ oozie-tools ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-site-plugin:2.0-beta-6:attach-descriptor (attach-descriptor) @ 
oozie-tools ---
[INFO] 
[INFO] --- maven-assembly-plugin:2.2.1:single (default-cli) @ oozie-tools ---
[INFO] Reading assembly descriptor: ../src/main/assemblies/tools.xml
[WARNING] The following patterns were never triggered in this artifact 
exclusion filter:
o  '*:*:pom:*'

[INFO] Copying files to 

[WARNING] Assembly file: 

 is not a regular file (it may be a directory). It cannot be attached to the 
project build for installation or deployment.
[INFO] 
[INFO] 
[INFO] Building Apache Oozie MiniOozie 4.3.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ oozie-mini ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
oozie-mini ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ oozie-mini 
---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
oozie-mini ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 
oozie-mini ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.2:test (default-test) @ oozie-mini ---
[INFO] Tests are skipped.
[INFO] 
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ oozie-mini ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-site-plugin:2.0-beta-6:attach-descriptor (attach-descriptor) @ 
oozie-mini ---
[INFO] 
[INFO] --- maven-assembly-plugin:2.2.1:single (default-cli) @ oozie-mini ---
[INFO] Reading assembly descriptor: src/main/assemblies/empty.xml
[INFO] 
[INFO] 
[INFO] Building Apache Oozie Distro 4.3.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ oozie-distro 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
oozie-distro ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ oozie-distro 
---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
oozie-distro ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 
oozie-distro ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.2:test (default-test) @ oozie-distro ---
[INFO] Tests are skipped.
[INFO] 
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ oozie-distro ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-site-plugin:2.0-beta-6:attach-descriptor (attach-descriptor) @ 
oozie-distro ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.6:run (default) @ oozie-distro ---
[INFO] Executing tasks

main:
  [get] Getting: 
http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.44/bin/apache-tomcat-6.0.44.tar.gz
  [get] To:

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073385#comment-15073385
 ] 

Hadoop QA commented on OOZIE-1922:
--

Testing JIRA OOZIE-1922

Cleaning local git workspace



{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than 
132
.{color:green}+1{color} the patch does adds/modifies 2 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT 
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc 
warnings
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac 
warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA 
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
.Tests run: 1706
.Tests failed: 7
.Tests errors: 0

.The patch failed the following testcases:

.  testForNoDuplicates(org.apache.oozie.event.TestEventGeneration)
.  testPurgeXCommandFailed(org.apache.oozie.command.TestPurgeXCommand)
.  testPurgeWFWithSubWF1(org.apache.oozie.command.TestPurgeXCommand)
.  testSamplers(org.apache.oozie.util.TestMetricsInstrumentation)
.  
testCoord_throwException(org.apache.oozie.command.coord.TestCoordChangeXCommand)
.  testRecovery(org.apache.oozie.action.hadoop.TestJavaActionExecutor)
.  testUpdateSLA(org.apache.oozie.sla.TestSLAService)

{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch 


{color:red}*-1 Overall result, please check the reported -1(s)*{color}


The full output of the test-patch run is available at

.   https://builds.apache.org/job/oozie-trunk-precommit-build/2689/

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, OOZIE-1922-V2.patch, 
> 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)

Reviewing patches and clearing backlog

2015-12-28 Thread Rohini Palaniswamy

Committers,
I see that patches submitted by users have been piling up and we are at
57 now. It would be good to get that down to 20 and avoid patches going too
stale and contributors disappearing due to lack of response on our end. If
everyone can pick up 3-5 jiras for reviewing and commiting it can be
cleared up quickly. If the patches are not relevant, clear the Patch
available or close them so that it gets removed from this report.

   If there are contributors interested in reviewing, please go ahead and
pick some patches for reviewing. It would make it easy for the committers
and also help one move towards committership.

Thanks,
Rohini


-- Forwarded message --
From: 
Date: Sun, Dec 27, 2015 at 11:00 PM
Subject: [jira] Subscription: Oozie Patch Available
To: dev@oozie.apache.org


Issue Subscription
Filter: Oozie Patch Available (57 issues)

Subscriber: ooziedaily

Key Summary
OOZIE-2419  HBase credentials are not correctly proxied
https://issues.apache.org/jira/browse/OOZIE-2419
OOZIE-2409  hive2 action with hive 1.2.1 failed
https://issues.apache.org/jira/browse/OOZIE-2409
OOZIE-2400  Workflow xml configuration parser cannot deal with namespace
prefix
https://issues.apache.org/jira/browse/OOZIE-2400
OOZIE-2396  oozie compile with hadoop 2.7.1 failed
https://issues.apache.org/jira/browse/OOZIE-2396
OOZIE-2394  Oozie can execute command without holding lock
https://issues.apache.org/jira/browse/OOZIE-2394
OOZIE-2390  Rerun with failed option removing completed output data
https://issues.apache.org/jira/browse/OOZIE-2390
OOZIE-2362  SQL injection in BulkJPAExecutor
https://issues.apache.org/jira/browse/OOZIE-2362
OOZIE-2357  CoordRerun should queue CoordPushDependencyCheckXCommand if
there is push dependencies
https://issues.apache.org/jira/browse/OOZIE-2357
OOZIE-2349  Method getCoordJobInfo(String jobId, String filter, int offset,
int length, boolean desc) is not present in LocalOozieClientCoord
https://issues.apache.org/jira/browse/OOZIE-2349
OOZIE-2338  Invalid configuration defined reported for some valid configs
https://issues.apache.org/jira/browse/OOZIE-2338
OOZIE-2312  oozie doesn't purge audit and error log
https://issues.apache.org/jira/browse/OOZIE-2312
OOZIE-2273  MiniOozie does not work outside of Oozie
https://issues.apache.org/jira/browse/OOZIE-2273
OOZIE-2259  Create a callback action
https://issues.apache.org/jira/browse/OOZIE-2259
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-2253  Spark Job is failing when it is running in standalone server
https://issues.apache.org/jira/browse/OOZIE-2253
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-2172  ZooKeeper Security Tests failed with JVM IBM JAVA
https://issues.apache.org/jira/browse/OOZIE-2172
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

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Purshotam Shah (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073111#comment-15073111
 ] 

Purshotam Shah commented on OOZIE-1922:
---

{quote}
This only checks for if there are no waiting threads and if all locks held by 
this thread are released before removing the lock. It does not take into 
account if any other thread is holding read or write lock. You will also have 
to make use of the following APIs in the logic.
{quote}
Sine we are in release function, which means that lock is acquired by current 
thread. So, we don't have to check if lock is held by other thread or not.


{quote}
Even though acquire() may not cause a ZK call for a reentrant lock, looking at 
the isAcquiredInThisProcess()/getParticipantNodes() APIs used in release() 
call, I am concerned that those will be new calls to ZK and might cause 
performance degradation if synchronous is removed in OOZIE-2394
{quote}

isAcquiredInThisProcess() doesn't make any ZK call.  

{code:title=InterProcessMutex.java}
@Override
public boolean isAcquiredInThisProcess()
{
return (threadData.size() > 0);
}

getParticipantNodes() does.  We may not need getParticipantNodes, since lock is 
acquired by current host, it won't be to acquire by other hosts.

!readWriteLock.readLock().isAcquiredInThisProcess() && 
!readWriteLock.writeLock().isAcquiredInThisProcess() is enough.

I didn't remove getParticipantNodes because it was already part of the 
condition and was not sure if it's break anything.
If you are really concern about performance, we can remove getParticipantNodes 
from condition.

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, 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] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Rohini Palaniswamy (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073124#comment-15073124
 ] 

Rohini Palaniswamy commented on OOZIE-1922:
---

bq. Sine we are in release function, which means that lock is acquired by 
current thread. So, we don't have to check if lock is held by other thread or 
not.
   You have to. If it is read locks, more than one thread can hold the lock. 
Currently only write locks are acquired in the code though, but still logic 
needs to be correct as there are APIs to acquire read lock.

bq. I didn't remove getParticipantNodes because it was already part of the 
condition and was not sure if it's break anything.
If you are really concern about performance, we can remove getParticipantNodes 
from condition.
Yes. Performance and load on zookeeper is very important.

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, 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] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Purshotam Shah (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073137#comment-15073137
 ] 

Purshotam Shah commented on OOZIE-1922:
---

{quote}
You have to. If it is read locks, more than one thread can hold the lock. 
Currently only write locks are acquired in the code though, but still logic 
needs to be correct as there are APIs to acquire read lock.
{quote}
I don't think we will ever support readlocks. We don't have to convolute our 
logic. I will put TODO in code for readlock support.

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, 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] [Commented] (OOZIE-2357) CoordRerun should queue CoordPushDependencyCheckXCommand if there is push dependencies

2015-12-28 Thread Rohini Palaniswamy (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073078#comment-15073078
 ] 

Rohini Palaniswamy commented on OOZIE-2357:
---

This issue is already fixed as part of  OOZIE-2358.

> CoordRerun should queue CoordPushDependencyCheckXCommand if there is push 
> dependencies
> --
>
> Key: OOZIE-2357
> URL: https://issues.apache.org/jira/browse/OOZIE-2357
> Project: Oozie
>  Issue Type: Bug
>Reporter: Kailong Sheng
>Assignee: Kailong Sheng
> Fix For: trunk
>
> Attachments: OOZIE-2357.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Purshotam Shah (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073111#comment-15073111
 ] 

Purshotam Shah edited comment on OOZIE-1922 at 12/28/15 8:12 PM:
-

{quote}
This only checks for if there are no waiting threads and if all locks held by 
this thread are released before removing the lock. It does not take into 
account if any other thread is holding read or write lock. You will also have 
to make use of the following APIs in the logic.
{quote}
Sine we are in release function, which means that lock is acquired by current 
thread. So, we don't have to check if lock is held by other thread or not.


{quote}
Even though acquire() may not cause a ZK call for a reentrant lock, looking at 
the isAcquiredInThisProcess()/getParticipantNodes() APIs used in release() 
call, I am concerned that those will be new calls to ZK and might cause 
performance degradation if synchronous is removed in OOZIE-2394
{quote}

isAcquiredInThisProcess() doesn't make any ZK call.  

{code:title=InterProcessMutex.java}
@Override
public boolean isAcquiredInThisProcess()
{
return (threadData.size() > 0);
}
{code}
getParticipantNodes() does.  We may not need getParticipantNodes, since lock is 
acquired by current host, it won't be to acquire by other hosts.

!readWriteLock.readLock().isAcquiredInThisProcess() && 
!readWriteLock.writeLock().isAcquiredInThisProcess() is enough.

I didn't remove getParticipantNodes because it was already part of the 
condition and was not sure if it's break anything.
If you are really concern about performance, we can remove getParticipantNodes 
from condition.


was (Author: puru):
{quote}
This only checks for if there are no waiting threads and if all locks held by 
this thread are released before removing the lock. It does not take into 
account if any other thread is holding read or write lock. You will also have 
to make use of the following APIs in the logic.
{quote}
Sine we are in release function, which means that lock is acquired by current 
thread. So, we don't have to check if lock is held by other thread or not.


{quote}
Even though acquire() may not cause a ZK call for a reentrant lock, looking at 
the isAcquiredInThisProcess()/getParticipantNodes() APIs used in release() 
call, I am concerned that those will be new calls to ZK and might cause 
performance degradation if synchronous is removed in OOZIE-2394
{quote}

isAcquiredInThisProcess() doesn't make any ZK call.  

{code:title=InterProcessMutex.java}
@Override
public boolean isAcquiredInThisProcess()
{
return (threadData.size() > 0);
}

getParticipantNodes() does.  We may not need getParticipantNodes, since lock is 
acquired by current host, it won't be to acquire by other hosts.

!readWriteLock.readLock().isAcquiredInThisProcess() && 
!readWriteLock.writeLock().isAcquiredInThisProcess() is enough.

I didn't remove getParticipantNodes because it was already part of the 
condition and was not sure if it's break anything.
If you are really concern about performance, we can remove getParticipantNodes 
from condition.

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, 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] [Commented] (OOZIE-2394) Oozie can execute command without holding lock

2015-12-28 Thread Rohini Palaniswamy (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073127#comment-15073127
 ] 

Rohini Palaniswamy commented on OOZIE-2394:
---

bq. Sounds good. But I would like to see the stress test run and confirmed that 
there is no performance regression before giving +1 for this patch.
  On second thoughts, I think it would be good to retain the execute 
synchronous code in XCommand. It can be enhanced to avoid loadState() and the 
objects passed in constructor itself further saving time and being more 
performant. So can we just set synchronous to false when requeuing?

> Oozie can execute command without holding lock
> --
>
> Key: OOZIE-2394
> URL: https://issues.apache.org/jira/browse/OOZIE-2394
> Project: Oozie
>  Issue Type: Bug
>Reporter: Purshotam Shah
>Assignee: Purshotam Shah
>Priority: Critical
> Attachments: OOZIE-2394-V1.patch
>
>
> To speedup job submission ( not the the forked actions) we create workflow 
> actions synchronously. We call ActionStartXCommand from SignalXCommand by 
> setting isSynchronous = true. This will bypass lock acquiring, which is Ok, 
> SignalXCommand will have the job lock.
> If there is transient error. Same command is requeued which will have 
> isSynchronous flag set to true.
> Requeued command will wake-up and started executing without acquiring lock. 
> If the job submission takes more than 2 min, then we might have issue.
> Action recovery is set to 2 min ( default), Recovery service will run and 
> submitted new the command. since the first command didn't acquire any lock. 
> Recovery will be able to run the new command.
> We will have two same command running parallely.
> All our commands are reentrant, we don't have to have set synchronized flag 
> to run multiple command from same thread.
> Because of reentrant, command running in same thread should be able to 
> acquire same 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

2015-12-28 Thread Purshotam Shah (JIRA)


 [ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Purshotam Shah updated OOZIE-1922:
--
Attachment: OOZIE-1922-V2.patch

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, OOZIE-1922-V2.patch, 
> 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)

Re: Review Request 41623: OOZIE-1922 - MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Purshotam Shah


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41623/
---

(Updated Dec. 29, 2015, 12:31 a.m.)


Review request for oozie.


Bugs: OOZIE-1922
https://issues.apache.org/jira/browse/OOZIE-1922


Repository: oozie-git


Description
---

OOZIE-1922 - MemoryLocksService fails if lock is acquired multiple times in 
same thread and released


Diffs (updated)
-

  core/src/main/java/org/apache/oozie/lock/MemoryLocks.java 
ee564b3def2ce42b06f697c3384b1e102ac6a3ba 
  core/src/main/java/org/apache/oozie/service/MemoryLocksService.java 
e3eccdb3f95e74198c3d42d19022b4acfc3d18e5 
  core/src/main/java/org/apache/oozie/service/ZKLocksService.java 
e3a6bcf04048e140d2ced9d8bdbfe08b01b323e4 
  core/src/test/java/org/apache/oozie/lock/TestMemoryLocks.java 
0efe31033f63055c08e42202c56c336248271afe 
  core/src/test/java/org/apache/oozie/service/TestZKLocksService.java 
02cc1372dc015713f0bb1f6861b7e4b7455c4f13 

Diff: https://reviews.apache.org/r/41623/diff/


Testing
---

TestZKLocksService.testReentrantMultipleCall already has reentrant test cases.


Thanks,

Purshotam Shah

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-28 Thread Rohini Palaniswamy (JIRA)


[ 
https://issues.apache.org/jira/browse/OOZIE-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073318#comment-15073318
 ] 

Rohini Palaniswamy commented on OOZIE-1922:
---

Thanks. New logic for memory looks solid now.


{code}
+InterProcessReadWriteLock readWriteLock = zkLocks.get(resource);
// This shouldn't happen, but if it does, then we should remove entry from map
+if (readWriteLock == null) {
+return false;
+}
{code}
Above code means that it is not in the hashmap already, so trying to remove 
from hashmap does not make sense. if (readWriteLock == null) check should be 
before and outside of isLockHeld. 

> 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: Purshotam Shah
> Attachments: OOZIE-1922-V1.patch, OOZIE-1922-V2.patch, 
> 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] Subscription: Oozie Patch Available

2015-12-28 Thread jira

Issue Subscription
Filter: Oozie Patch Available (55 issues)

Subscriber: ooziedaily

Key Summary
OOZIE-2409  hive2 action with hive 1.2.1 failed
https://issues.apache.org/jira/browse/OOZIE-2409
OOZIE-2400  Workflow xml configuration parser cannot deal with namespace prefix
https://issues.apache.org/jira/browse/OOZIE-2400
OOZIE-2396  oozie compile with hadoop 2.7.1 failed
https://issues.apache.org/jira/browse/OOZIE-2396
OOZIE-2394  Oozie can execute command without holding lock
https://issues.apache.org/jira/browse/OOZIE-2394
OOZIE-2390  Rerun with failed option removing completed output data
https://issues.apache.org/jira/browse/OOZIE-2390
OOZIE-2362  SQL injection in BulkJPAExecutor
https://issues.apache.org/jira/browse/OOZIE-2362
OOZIE-2349  Method getCoordJobInfo(String jobId, String filter, int offset, int 
length, boolean desc) is not present in LocalOozieClientCoord
https://issues.apache.org/jira/browse/OOZIE-2349
OOZIE-2338  Invalid configuration defined reported for some valid configs
https://issues.apache.org/jira/browse/OOZIE-2338
OOZIE-2312  oozie doesn't purge audit and error log
https://issues.apache.org/jira/browse/OOZIE-2312
OOZIE-2273  MiniOozie does not work outside of Oozie
https://issues.apache.org/jira/browse/OOZIE-2273
OOZIE-2259  Create a callback action 
https://issues.apache.org/jira/browse/OOZIE-2259
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-2253  Spark Job is failing when it is running in standalone server
https://issues.apache.org/jira/browse/OOZIE-2253
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-2172  ZooKeeper Security Tests failed with JVM IBM JAVA
https://issues.apache.org/jira/browse/OOZIE-2172
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

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

Re: Review Request 41623: OOZIE-1922 - MemoryLocksService fails if lock is acquired multiple times in same thread and released

Build failed in Jenkins: oozie-trunk-precommit-build #2689

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

Reviewing patches and clearing backlog

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

[jira] [Commented] (OOZIE-2357) CoordRerun should queue CoordPushDependencyCheckXCommand if there is push dependencies

[jira] [Comment Edited] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

[jira] [Commented] (OOZIE-2394) Oozie can execute command without holding lock

[jira] [Updated] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

Re: Review Request 41623: OOZIE-1922 - MemoryLocksService fails if lock is acquired multiple times in same thread and released

[jira] [Commented] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

[jira] Subscription: Oozie Patch Available

17 matches

Site Navigation

Mail list logo

Footer information