[
https://issues.apache.org/jira/browse/OOZIE-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15646152#comment-15646152
]
Hadoop QA commented on OOZIE-2724:
----------------------------------
Testing JIRA OOZIE-2724
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:red}-1{color} FindBugs diff JAR has a weird MD5 sum, rejecting.
{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: 1818
. Tests failed: 6
. Tests errors: 3
. The patch failed the following testcases:
.
testMaterizationLookup(org.apache.oozie.command.coord.TestCoordMaterializeTransitionXCommand)
. testMain(org.apache.oozie.action.hadoop.TestHiveMain)
. testPigScript(org.apache.oozie.action.hadoop.TestPigMain)
. testEmbeddedPigWithinPython(org.apache.oozie.action.hadoop.TestPigMain)
. testPig_withNullExternalID(org.apache.oozie.action.hadoop.TestPigMain)
. testPigScript(org.apache.oozie.action.hadoop.TestPigMainWithOldAPI)
{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/3421/
> coord:current resolves monthly/yearly dependencies incorrectly
> --------------------------------------------------------------
>
> Key: OOZIE-2724
> URL: https://issues.apache.org/jira/browse/OOZIE-2724
> Project: Oozie
> Issue Type: Bug
> Affects Versions: 4.2.0
> Reporter: Satish Subhashrao Saley
> Assignee: Satish Subhashrao Saley
> Priority: Critical
> Fix For: 4.3.0
>
> Attachments: OOZIE-2724-1.patch, OOZIE-2724-2.patch
>
>
> We calculate the difference between two dates to get the instance count.
> Consider a case where, {{initial instance = Thu Dec 31 16:00:00 PST 2009}}
> and {{effective date (nominal time) = Sun Oct 30 17:55:00 PDT 2016}}.
> Frequency is monthly. So the instance count would be simply number of months
> between these two dates. The number of months between are 81 (inclusively).
> But following code returns 83. A later part of code decreases (possibly some
> offset deletion logic) this by 1, making it 82.
> {code}
> Calendar org.apache.oozie.coord.CoordELFunctions.getCurrentInstance(Date
> effectiveTime, int[] instanceCount, ELEvaluator eval)
> ...
> ...
> case END_OF_MONTH:
> instanceCount[0] = (int) ((effectiveTime.getTime() -
> datasetInitialInstance.getTime()) / MONTH_MSEC);
> break;
> ....
> {code}
> later part of code which is reducing the value by 1:
> {code}
> if (instanceCount[0] > 2) {
> instanceCount[0] = (instanceCount[0] / dsFreq);
> current.add(dsTimeUnit.getCalendarUnit(), instanceCount[0] *
> dsFreq);
> } else {
> instanceCount[0] = 0;
> }
> while (!current.getTime().after(effectiveTime)) {
> current.add(dsTimeUnit.getCalendarUnit(), dsFreq);
> instanceCount[0]++;
> }
> current.add(dsTimeUnit.getCalendarUnit(), -dsFreq);
> instanceCount[0]--;
> return current;
> {code}
> This happens because there we consider only 30 number of days in a month
> while calculating the milliseconds in a month. It will also affect yearly
> jobs because leap year has 366 days.
> {code}
> public static final long MONTH_MSEC = 30 * DAY_MSEC;
> public static final long YEAR_MSEC = 365 * DAY_MSEC;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
