[
https://issues.apache.org/jira/browse/OOZIE-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989300#comment-13989300
]
Shwetha G S commented on OOZIE-1819:
------------------------------------
[~rohini], CoordActionInputCheckXCommand has the check with nominal time and
current time already, which re-queues itself without doing anything if executed
before nominal time. Actually, re-queue already uses (nominal time - current
time) delay. So, we can use the same delay even while enqueueing at
materialisation:
{noformat}
Date nominalTime = coordAction.getNominalTime();
Date currentTime = new Date();
if (nominalTime.compareTo(currentTime) > 0) {
queue(new CoordActionInputCheckXCommand(coordAction.getId(),
coordAction.getJobId()), Math.max((nominalTime.getTime() - currentTime
.getTime()), getCoordInputCheckRequeueInterval()));
updateCoordAction(coordAction, false);
LOG.info("[" + actionId
+ "]::ActionInputCheck:: nominal Time is newer than current
time, so requeue and wait. Current="
+ DateUtils.formatDateOozieTZ(currentTime) + ", nominal=" +
DateUtils.formatDateOozieTZ(nominalTime));
return null;
}
{noformat}
[~puru],
{quote}
But are we not taking away benefit of mat throttle?
{quote}
I didn't understand how it affects materialisation throttle.
CoordActionInputCheckXCommand already does nothing till nominal time. So,
nothing changes with this patch. Instead of executing
CoordActionInputCheckXCommand and re-queueing CoordActionInputCheckXCommand
again(for nominal time), this patch enqueues CoordActionInputCheckXCommand for
nominal time initially itself. So, the status of coordinator action will change
at the same time as before and it will not affect materialisation in any way.
{quote}
We should use this logic for Coord Materialize service.
Now we have different setting for schedulingInterval and lookup interval.
If schedulingInterval > lookupInterval, then we should delay
CoordMaterializeTransitionXCommand for schedulingInterval - lookupInterval.
{quote}
The whole idea of separating out schedulingInterval and lookupInterval was that
the coordinator action is materialised early(before nominal time). By delaying
CoordMaterializeTransitionXCommand, won't it defeat the original purpose? Also
the delay (schedulingInterval - lookupInterval) wouldn't work
> Avoid early queueing of CoordActionInputCheckXCommand
> -----------------------------------------------------
>
> Key: OOZIE-1819
> URL: https://issues.apache.org/jira/browse/OOZIE-1819
> Project: Oozie
> Issue Type: Bug
> Reporter: Shwetha G S
> Assignee: Shwetha G S
> Fix For: trunk
>
> Attachments: OOZIE-1819.patch
>
>
> Currently, when coord action is materialised, CoordActionInputCheckXCommand
> is queued immediately. If the action is materialised long before the nominal
> time, this unnecessarily keeps executing CoordActionInputCheckXCommand and
> re-queues till nominal time. Instead, CoordActionInputCheckXCommand can be
> queued with delay = (nominal time - now)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
