[
https://issues.apache.org/jira/browse/AURORA-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zameer Manji updated AURORA-1890:
---------------------------------
Description:
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 inferring the timestamp of the last pulse by inspecting
the job update events.
was:
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.
> Job Update Pulse History is initialized to no pulses on scheduler recovery
> --------------------------------------------------------------------------
>
> 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 inferring the timestamp of the last pulse by inspecting
> the job update events.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
