[jira] Subscription: Oozie Patch Available

2015-12-29 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  W

Re: Review Request 38474: OOZIE-1976- Specifying coordinator input datasets in more logical ways

2015-12-29 Thread Rohini Palaniswamy 

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


These are comments for Page 1 and 2. Still I have not fully gone through and 
understood few of the classes. Will comment on those and the testcases/Page 3 
in next review.

At high level,

1) Noticed naming and EL function changed from design doc you had put up 
earlier. Liked those better.
   - Possible to rename  to  as per the design doc
   - Possible to reuse the existing EL also as per design doc? i.e 
coord:dataIn(CorD) instead of coord:inputCheckDataIn(CorD) Keeps it simple for 
user.

2) User documentation missing as mentioned by Robert.
3) Couple of comments are my usual nitpicks on typos and variable naming.


client/src/main/resources/oozie-coordinator-0.5.xsd (line 115)


type="coordinator:IDENTIFIER" . Same for other names.

Shouldn't it be use="required" ?



client/src/main/resources/oozie-coordinator-0.5.xsd (lines 116 - 117)


min and wait seems to be supported only at the data-in level.



client/src/main/resources/oozie-coordinator-0.5.xsd (line 139)


Why does this need a name?



core/src/main/java/org/apache/oozie/CoordinatorActionBean.java (lines 822 - 826)


Declare variables at the top along with other variables



core/src/main/java/org/apache/oozie/command/coord/CoordActionInputCheckXCommand.java
 (line 169)


Nitpick. isPushDependenciesMeet  -> isPushDependenciesMet . 

There are couple of other places as well. Please grep for meet and change 
to met.



core/src/main/java/org/apache/oozie/command/coord/CoordActionInputCheckXCommand.java
 


Can we keep this log statement? Might not be exactly correct anymore if 
input-logic is defined, but still can be helpful to some extent in determining 
what to look for



core/src/main/java/org/apache/oozie/command/coord/CoordActionInputCheckXCommand.java
 (lines 172 - 174)


Seems redundant.



core/src/main/java/org/apache/oozie/command/coord/CoordActionInputCheckXCommand.java
 (line 275)


This is redundant. UPDATE_COORD_ACTION_FOR_INPUTCHECK only serializes pull 
missing dependencies



core/src/main/java/org/apache/oozie/command/coord/CoordActionInputCheckXCommand.java
 (line 436)


Why public? Also method seems to be unused. To be removed?



core/src/main/java/org/apache/oozie/command/coord/CoordActionInputCheckXCommand.java
 (line 494)


Why public? Also method seems to be unused as it is copied to 
CoordOldInputDependency. To be removed?



core/src/main/java/org/apache/oozie/command/coord/CoordActionUpdatePushMissingDependency.java
 (line 43)


Seems wrong. Getter is that of push dependencies instead of pull.



core/src/main/java/org/apache/oozie/command/coord/CoordMaterializeTransitionXCommand.java
 (line 533)


isInputLogicSpecified



core/src/main/java/org/apache/oozie/command/coord/CoordMaterializeTransitionXCommand.java
 (line 534)


validateInputLogic



core/src/main/java/org/apache/oozie/command/coord/CoordPushDependencyCheckXCommand.java
 (line 123)


Keep the info log statement. May not be fully correct when OR is involved, 
but still would be useful.

List availableList - This is not required. It will try to 
unregister already available stuff. Can just do 
unregisterAvailableDependencies(actionDep.getAvailableDependencies()); as before



core/src/main/java/org/apache/oozie/command/coord/CoordPushDependencyCheckXCommand.java
 (line 171)


coordPushInputDependency.isDependencyMet() is redundant. Pushdependency 
cannot be met without changeindependency



core/src/main/java/org/apache/oozie/coord/CoordUtils.java (line 434)


getInputLogic



core/src/main/java/org/apache/oozie/coord/CoordUtils.java (line 439)


Nitpick. getDataInputFromString



core/src/main/java/org/apache/oozie/coord/input/dependency/AbstractCoordInputDependency.java
 (line 64)


Nitpick. Does nothing and can be removed



co

[jira] [Commented] (OOZIE-2409) hive2 action with hive 1.2.1 failed

2015-12-29 Thread Jaydeep Vishwakarma (JIRA) 

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

Jaydeep Vishwakarma commented on OOZIE-2409:


dependency versions have been maintaining in main pom. So it is not right place 
to maintain. 
The way hive.version has been maintaining by properties. I would you suggest 
you to maintain the jline version by property only and lets keep it the default 
version only, You can manipulate version during mkdistro.

> hive2 action with hive 1.2.1 failed
> ---
>
> Key: OOZIE-2409
> URL: https://issues.apache.org/jira/browse/OOZIE-2409
> Project: Oozie
>  Issue Type: Bug
>  Components: build
>Affects Versions: 4.2.0
>Reporter: KWON BYUNGCHANG
>Priority: Minor
> Attachments: OOZIE-2409.01.patch, OOZIE-2409.02.patch, 
> OOZIE-2409.patch
>
>
> hive2 action with hive 1.2.1 failed.
> stack trace
> {code}
> 015-11-26 15:47:39,141  WARN Hive2ActionExecutor:523 - SERVER[myhost.com] 
> USER[myuser] GROUP[-] TOKEN[] APP[test] 
> JOB[401-151125114930017-oozie-irte-W] 
> ACTION[401-151125114930017-oozie-irte-W@HIVEJOB] Launcher exception: 
> jline/console/history/History
> java.lang.NoClassDefFoundError: jline/console/history/History
>   at 
> org.apache.oozie.action.hadoop.Hive2Main.runBeeline(Hive2Main.java:240)
>   at org.apache.oozie.action.hadoop.Hive2Main.run(Hive2Main.java:223)
>   at org.apache.oozie.action.hadoop.LauncherMain.run(LauncherMain.java:47)
>   at org.apache.oozie.action.hadoop.Hive2Main.main(Hive2Main.java:56)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> hive 1.2.1 need to jline-2.12.jar.
> But hive2 shareblib has jline-0.9.94.jar.
> jline-0.9.94.jar does not have jline/console/history/History class.
> I have changed {{sharelib/hive2/pom.xml}} temporarily.



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

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

2015-12-29 Thread Apache Jenkins Server 
See 

--
[...truncated 7678 lines...]
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ oozie-tools 
---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
oozie-tools ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 
oozie-tools ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.2:test (default-test) @ oozie-tools ---
[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

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

2015-12-29 Thread Hadoop QA (JIRA) 

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

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} - patch does not compile, cannot run testcases
{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/2690/

> 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-V3.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-29 Thread Rohini Palaniswamy (JIRA) 

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

Rohini Palaniswamy commented on OOZIE-1922:
---

+1

> 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-V3.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-29 Thread Rohini Palaniswamy 

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



core/src/main/java/org/apache/oozie/service/ZKLocksService.java (line 200)


The null check should be here instead of isLockHeld.

InterProcessReadWriteLock readWriteLock = zkLocks.get(resource);
//It should never be null, but just in case
if (readWriteLock != null) { 
  if (!isLockHeld(readWriteLock)) {
  
  }
}


- Rohini Palaniswamy


On Dec. 29, 2015, 12:31 a.m., Purshotam Shah wrote:
> 
> ---
> 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
> -
> 
>   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] [Updated] (OOZIE-1922) MemoryLocksService fails if lock is acquired multiple times in same thread and released

2015-12-29 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-V3.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-V3.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-29 Thread Purshotam Shah (JIRA) 

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

Purshotam Shah commented on OOZIE-1922:
---

I fix that. I  have also optimized the memory lock condition.
getReadLockCount is enough, it will also give the count of readlock held by 
current thread. We don't have to use getReadHoldCount.

> 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 39144: OOZIE-2312 oozie doesn't purge audit and error log

2015-12-29 Thread Purshotam Shah 

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

(Updated Dec. 29, 2015, 5:49 p.m.)


Review request for oozie.


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


Repository: oozie-git


Description
---

oozie doesn't purge audit and error log


Diffs (updated)
-

  core/src/main/conf/oozie-log4j.properties 
2b20ff282477d91549e3f6cdee425674e4cc773b 
  core/src/main/java/org/apache/oozie/service/XLogUtil.java 
59a4d221dd14bfdd58ed797ad18dd51ea77ce8ed 
  core/src/main/java/org/apache/oozie/util/OozieRollingPolicy.java 
19ce7f95d3914d006f257e8ad4cc9b68e1d6488c 
  core/src/test/java/org/apache/oozie/util/TestOozieRollingPolicy.java 
9ae7bec99fa9b47ca05a485c2f47bb3f642a54a2 

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


Testing
---


Thanks,

Purshotam Shah

Re: Review Request 39144: OOZIE-2312 oozie doesn't purge audit and error log

2015-12-29 Thread Purshotam Shah 

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



core/src/main/conf/oozie-log4j.properties (line 90)





- Purshotam Shah


On Oct. 8, 2015, 8:53 p.m., Purshotam Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39144/
> ---
> 
> (Updated Oct. 8, 2015, 8:53 p.m.)
> 
> 
> Review request for oozie.
> 
> 
> Bugs: OOZIE-2312
> https://issues.apache.org/jira/browse/OOZIE-2312
> 
> 
> Repository: oozie-git
> 
> 
> Description
> ---
> 
> oozie doesn't purge audit and error log
> 
> 
> Diffs
> -
> 
>   core/src/main/conf/oozie-log4j.properties 
> 2b20ff282477d91549e3f6cdee425674e4cc773b 
>   core/src/main/java/org/apache/oozie/util/OozieRollingPolicy.java 
> 19ce7f95d3914d006f257e8ad4cc9b68e1d6488c 
>   core/src/test/java/org/apache/oozie/util/TestOozieRollingPolicy.java 
> 9ae7bec99fa9b47ca05a485c2f47bb3f642a54a2 
> 
> Diff: https://reviews.apache.org/r/39144/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Purshotam Shah
> 
>