[
https://issues.apache.org/jira/browse/AURORA-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864598#comment-15864598
]
Zameer Manji commented on AURORA-1890:
--------------------------------------
I would be content with initializing the {{PulseState}} timestamp with the
timestamp of the most recent event that transitioned from a
{{BLOCKED_AWAITING_PULSE}}.
I feel this is more correct than what we do now, avoids hashing out some
storage changes, and is suitable for my current usecase.
If you confirm that you agree, I can rephrase this ticket to better capture
what the fix would be.
> Job Update Pulse History is not durably stored
> ----------------------------------------------
>
> Key: AURORA-1890
> URL: https://issues.apache.org/jira/browse/AURORA-1890
> Project: Aurora
> Issue Type: Bug
> Reporter: Zameer Manji
>
> I have experienced the following problem with pulse updates. To reproduce:
> 1. Create an update with a pulse timeout of 1h
> 2. Send a pulse to get the update going.
> 3. Failover the scheduler immediately after.
> 4. Observe that the update is awaiting another pulse right after the failover.
> This is because the {{JobUpdateControllerImpl}} stores pulse history and
> state in memory in {{PulseHandler}}. On scheduler startup, the pulse state is
> reset to no pulse received.
> We can solve this by durably storing the timestamp of the last pulse received
> in storage.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
