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

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 1 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: 1510
.    Tests failed: 7
.    Tests errors: 2

.    The patch failed the following testcases:

.      testBundleId(org.apache.oozie.servlet.TestBulkMonitorWebServiceAPI)
.      
testMemoryUsageAndSpeed(org.apache.oozie.service.TestPartitionDependencyManagerService)
.      testPigScript(org.apache.oozie.action.hadoop.TestPigMainWithOldAPI)
.      testPigScript(org.apache.oozie.action.hadoop.TestPigMain)
.      testEmbeddedPigWithinPython(org.apache.oozie.action.hadoop.TestPigMain)
.      testPig_withNullExternalID(org.apache.oozie.action.hadoop.TestPigMain)
.      testMain(org.apache.oozie.action.hadoop.TestHiveMain)

{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/1726/

> 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
>         Attachments: OOZIE-1922.1.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.2#6252)

Reply via email to