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

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: 1
.    Tests errors: 0

.    The patch failed the following testcases:

.      
testMaterizationLookup(org.apache.oozie.command.coord.TestCoordMaterializeTransitionXCommand)

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

> 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)

Reply via email to