> On April 10, 2014, 1:50 a.m., Purshotam Shah wrote: > > core/src/main/java/org/apache/oozie/coord/CoordELFunctions.java, line 1367 > > <https://reviews.apache.org/r/18762/diff/4/?file=552672#file552672line1367> > > > > Can you explain, why this is needed. > > > > Can't u get the correct offset by (effectiveTime.getTime() - > > datasetInitialInstance.getTime())/unit?
The code assumes 30 days per month, 365 days a year which is not right. Hence the count is offset by 2 and use for loop to get the correct offset - shwethags ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18762/#review39973 ----------------------------------------------------------- On April 8, 2014, 5:17 p.m., shwethags wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18762/ > ----------------------------------------------------------- > > (Updated April 8, 2014, 5:17 p.m.) > > > Review request for oozie. > > > Bugs: OOZIE-1709 > https://issues.apache.org/jira/browse/OOZIE-1709 > > > Repository: oozie-git > > > Description > ------- > > CoordELFunctions.getCurrentInstance() has this code: > while (current.compareTo(calEffectiveTime) <= 0) { > current = (Calendar) origCurrent.clone(); > instanceCount[0]++; > current.add(dsTimeUnit.getCalendarUnit(), instanceCount[0] * > dsFreq); > } > > For coords with smaller frequency and start time in very past, this is very > expensive. On prod, we have seen materialisation of each instance taking few > mins sometimes for coords with 1 min frequency > > > Diffs > ----- > > core/src/main/java/org/apache/oozie/coord/CoordELFunctions.java d73bc7d > core/src/test/java/org/apache/oozie/coord/TestCoordELFunctions.java be35ce4 > > Diff: https://reviews.apache.org/r/18762/diff/ > > > Testing > ------- > > UT > > > Thanks, > > shwethags > >
