New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 610148 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Introduce delays in between policy fetch, status upload, and system log file upload after machine boots up

Project Member Reported by jinzhang@chromium.org, May 8 2016

Issue description

1. Introduce a 1 minute delay between policy fetch and status upload requests (policy fetch request first, then status upload request). 

Currently, after machine boots up, policy fetch & status upload requests are sent to the server almost at the same time, which results to concurrent DDS writes. Although on the server side, retry and 3-way merge are applied to make sure most of such concurrent DDS updates would succeed eventually, DDS still suffers many errors caused by the concurrent writes. They say 10% of their errors come from us.


2. Introduce a 1 minute delay from the time machine boots up, till the time system logs upload starts.

This is needed because we found out that some system logs upload attempts failed because the network configuration for the device isn't ready yet.

 
Cc: atwilson@chromium.org
Owner: hunyadym@chromium.org
For simplicity, I'd just change StatusUploader::ScheduleNextStatusUpload() to have a minimum 60s delay (so it never immediately schedules the next status upload - it always waits at least 60s). No need to actually wait for the policy fetch to complete, etc - that introduces too much of a dependency between orthogonal systems within Chrome OS, we mostly just want to ensure they don't happen simultaneously.

This also probably addresses some issues with status upload where we fire it off before the kiosk session starts, so we might actually get better status upload data.
Status: Fixed (was: Assigned)

Comment 4 by dkalin@google.com, Sep 12 2016

Do you know which stable release this is in?
Labels: M-52
M52

Sign in to add a comment