Effective connection type may not be recorded in system profile proto due to thread racing |
||||
Issue descriptionIn certain cases, Effective connection type (ECT) may not be recorded in the system profile proto. This may happen if the metrics service gets initialized before the IO thread is initialized. https://chromium-review.googlesource.com/c/586572 changed the initialization logic which caused this to happen (more frequently). In that case, posting tasks to the IO thread in NetworkMetricsProvider fails. This results in NetworkMetricsProvider not receiving callbacks from NQE (Network Quality Estimator), and the ECT value remains stuck at UNKNOWN. The fix should ensure that NetworkMetricsProvider posts tasks to the IO thread only after the IO thread has been initialized.
,
Aug 15 2017
Few more details: 1. NQE classes in metrics service are initialized on IO thread. Metrics service initialization happens on UI thread. 2. When NQE code was written, merics service initialization happened after IO thread initialization. So, metrics service would simply post a task to IO thread for getting NQE initialized. 3. A recent CL (https://chromium-review.googlesource.com/c/586572) broke that assumption which means the post task to IO thread always failed resulting in failure of NQE initialization. According to the documentation (https://chromium.googlesource.com/chromium/src/+/lkcr/docs/task_scheduler_migration.md): "All BrowserThreads but UI/IO are being migrated ..." So, it seems that unlike other threads, UI/IO threads have to be initialized before they accept post tasks?
,
Aug 16 2017
> According to the documentation (https://chromium.googlesource.com/chromium/src/+/lkcr/docs/task_scheduler_migration.md): "All BrowserThreads but UI/IO are being migrated ..." So, it seems that unlike other threads, UI/IO threads have to be initialized before they accept post tasks? Ugh... yeah... that's always been the case FWIW, BrowserThreads have never accepted tasks prior to CreateThreads(). Now that TaskScheduler does support posting before CreateThreads (results in queuing) and the only BrowserThreads will soon be just UI/IO we could consider queuing for these as well. But you're right that https://chromium-review.googlesource.com/c/586572 broke MetricsService's assumption that the IO thread was up during its initialization... (more replies on CL)
,
Aug 16 2017
,
Aug 16 2017
,
Aug 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7e299f59fcbd38ba654c71b742e4c3616dda7463 commit 7e299f59fcbd38ba654c71b742e4c3616dda7463 Author: Tarun Bansal <tbansal@chromium.org> Date: Wed Aug 16 20:12:28 2017 Fix recording of Effective connection type (ECT) in system profile proto ECT may not be recorded in certain cases where metrics service gets initialized before the IO thread is initialized. In that case, posting tasks to the IO thread fails. This CL fixes the issue by waiting for the IO thread to be initialized before posting tasks to it. Bug: 755314 Change-Id: I37e1c1362bb76e8d2b47ec7bb408d0282287d532 Reviewed-on: https://chromium-review.googlesource.com/614775 Reviewed-by: Alexei Svitkine (very slow) <asvitkine@chromium.org> Commit-Queue: Tarun Bansal <tbansal@chromium.org> Cr-Commit-Position: refs/heads/master@{#494917} [modify] https://crrev.com/7e299f59fcbd38ba654c71b742e4c3616dda7463/chrome/browser/metrics/network_quality_estimator_provider_impl.cc [modify] https://crrev.com/7e299f59fcbd38ba654c71b742e4c3616dda7463/chrome/browser/metrics/network_quality_estimator_provider_impl.h [modify] https://crrev.com/7e299f59fcbd38ba654c71b742e4c3616dda7463/components/metrics/net/network_metrics_provider.cc [modify] https://crrev.com/7e299f59fcbd38ba654c71b742e4c3616dda7463/components/metrics/net/network_metrics_provider.h [modify] https://crrev.com/7e299f59fcbd38ba654c71b742e4c3616dda7463/components/metrics/net/network_metrics_provider_unittest.cc
,
Aug 16 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by tbansal@chromium.org
, Aug 14 2017Labels: M-62