No problem. OOZIE-1811 did fix root cause of non-flaky tests failing randomly but there's one which is timing sensitive and needs to be fixed org.apache.oozie.service.TestCallableQueueService.testConcurrencyReachedAndChooseNextEligible
and OOZIE-1952 will fix TestPurgeXCommand which uses old StoreService code. And then we're done! :) Mona Chitnis Software Engineer, Hadoop Team Yahoo! On Friday, August 1, 2014 4:25 PM, Purshotam Shah <purus...@yahoo-inc.com.INVALID> wrote: Thanks Mona for fixing testcases. It feel so good to see no UTC failure. On 8/1/14, 4:13 PM, "Hadoop QA (JIRA)" <j...@apache.org> wrote: > > [ >https://issues.apache.org/jira/browse/OOZIE-1939?page=com.atlassian.jira.p >lugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083151#com >ment-14083151 ] > >Hadoop QA commented on OOZIE-1939: >---------------------------------- > >Testing JIRA OOZIE-1939 > >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:green}+1 TESTS{color} >. Tests run: 1506 >{color:green}+1 DISTRO{color} >. {color:green}+1{color} distro tarball builds with the patch > >---------------------------- >{color:green}*+1 Overall result, good!, no -1s*{color} > > >The full output of the test-patch run is available at > >. https://builds.apache.org/job/oozie-trunk-precommit-build/1377/ > >> Incorrect job information is set while logging >> ---------------------------------------------- >> >> Key: OOZIE-1939 >> URL: https://issues.apache.org/jira/browse/OOZIE-1939 >> Project: Oozie >> Issue Type: Bug >> Reporter: Purshotam Shah >> Assignee: Azrael >> Attachments: OOZIE-1939.1.patch, OOZIE-1939.2.patch >> >> >> {code} >> 2014-07-16 17:28:06,422 DEBUG CoordChangeXCommand:545 >>[http-0.0.0.0-4443-5] - USER[hadoopqa] GROUP[users] TOKEN[] >>APP[coordB236] JOB[0011514-140716042555-oozie-oozi-C] ACTION[-] Acquired >>lock for [0011385-140716042555-oozie-oozi-C] in [coord_change] >> 2014-07-16 17:28:06,422 TRACE CoordChangeXCommand:548 >>[http-0.0.0.0-4443-5] - USER[hadoopqa] GROUP[users] TOKEN[] >>APP[coordB236] JOB[0011514-140716042555-oozie-oozi-C] ACTION[-] Load >>state for [0011385-140716042555-oozie-oozi-C] >> {code} >> {code} >> protected void loadState() throws CommandException { >> jpaService = Services.get().get(JPAService.class); >> if (jpaService == null) { >> LOG.error(ErrorCode.E0610); >> } >> try { >> coordJob = >>CoordJobQueryExecutor.getInstance().get(CoordJobQuery.GET_COORD_JOB_MATER >>IALIZE, jobId); >> prevStatus = coordJob.getStatus(); >> } >> catch (JPAExecutorException jex) { >> throw new CommandException(jex); >> } >> // calculate start materialize and end materialize time >> calcMatdTime(); >> LogUtils.setLogInfo(coordJob, logInfo); >> } >> {code} >> Most of the commands set jobinfo after loadstate, because of that few >>log statements ( like acquiring lock, load state) logs with previous >>jobinfo. > > > >-- >This message was sent by Atlassian JIRA >(v6.2#6252)
