New issue
Advanced search Search tips

Issue 764759 link

Starred by 0 users
Status: Fixed
Owner:
vapier@chromium.org
Closed: Sep 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

nassh: restoring large backups runs into quota limits

Project Member Reported by vapier@chromium.org, Sep 13 2017 
create like 30 connections, save the backup, then attempt to restore it.  doing so runs into:

nassh_preferences_editor.html:1
Unchecked runtime.lastError while running storage.set: This request exceeds the MAX_WRITE_OPERATIONS_PER_MINUTE quota.
    at lib.Storage.Chrome.setItem (.../js/nassh_deps.concat.js:3022:17)
    at nassh.PreferenceManager.lib.PreferenceManager.set (.../js/nassh_deps.concat.js:2696:18)
    at nassh.PreferenceManager.lib.PreferenceManager.createChild (.../js/nassh_deps.concat.js:2399:8)
    at nassh.PreferenceManager.lib.PreferenceManager.importFromJson (.../js/nassh_deps.concat.js:2767:35)
    at Object.nassh.importPreferences (.../js/nassh.js:173:14)
    at FileReader.reader.onloadend (.../js/nassh_preferences_editor.js:177:13)
Project Member

Comment 1 by bugdroid1@chromium.org, Sep 21 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/917ce883e6176308a3734431988fd2a69c9f2dba

commit 917ce883e6176308a3734431988fd2a69c9f2dba
Author: Mike Frysinger <vapier@chromium.org>
Date: Thu Sep 21 03:51:28 2017

libdot: retry storage saves when quota is exceeded

When restoring a backup with a lot of entries (>100), we end up
exceeding the Chrome sync storage write quota and all following
writes get rejected.  Handle this by situation by retrying the
write once a second until it passes.

Since we are given callbacks by the higher levels, we can still
properly notify interested parties when it finally succeeds.

In practice, if you were to restore a large backup, you'll have
to wait for a minute for the quota to become available again.
We don't currently have any UI to notify the user, but we'll
wait to do that later.  Lets just make it work now.

BUG= chromium:764759 

Change-Id: I2bd53a52c3aae143504d92dcf159bc04bdce5981
Reviewed-on: https://chromium-review.googlesource.com/665669
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Brandon Gilmore <varz@google.com>

[modify] https://crrev.com/917ce883e6176308a3734431988fd2a69c9f2dba/libdot/js/lib_preference_manager.js
[modify] https://crrev.com/917ce883e6176308a3734431988fd2a69c9f2dba/libdot/js/lib_storage_chrome.js
[modify] https://crrev.com/917ce883e6176308a3734431988fd2a69c9f2dba/nassh/js/nassh.js

Comment 2 by vapier@chromium.org, Sep 21 2017

Owner: vapier@chromium.org
Status: Fixed (was: Available)
should be fixed in libdot-1.19+ and nassh-0.8.38+
Project Member

Comment 3 by bugdroid1@chromium.org, Dec 20 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/c4ec8bd5fbdb5ffc36dfe8303b855ac944d96efb

commit c4ec8bd5fbdb5ffc36dfe8303b855ac944d96efb
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed Dec 20 22:42:38 2017

libdot: fix storage write callbacks with shallow prefs

While extending the storage write API to work with callbacks, importing
shallow backups (no children prefs set) broke.  The set helper function
doesn't have a callback (even though we tried to pass it one), so pull
that back out and make the final call ourselves in this scenario.

BUG= chromium:764759 

Change-Id: Ie6d38668d1f4ad3db0806d2a83742ec28b1cc9a7
Reviewed-on: https://chromium-review.googlesource.com/828396
Reviewed-by: Brandon Gilmore <varz@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/c4ec8bd5fbdb5ffc36dfe8303b855ac944d96efb/libdot/js/lib_preference_manager.js
Project Member

Comment 4 by bugdroid1@chromium.org, Nov 20 

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/6f8bccb14faf428cbb09677f87946937cf264de4

commit 6f8bccb14faf428cbb09677f87946937cf264de4
Author: Mike Frysinger <vapier@chromium.org>
Date: Tue Nov 20 16:48:27 2018

libdot: coalesce writes when importing json files

When importing many children elements, we end up rewriting the array
list many times and committing each update to storage.  This in turn
eats up our quota and cause use to overrun it when there are many
active profiles.

Change the json import logic so that we suppress the intermediate and
do a single flush at the end.

Bug:  chromium:764759 
Change-Id: I8fe0725ccfc006f2d269a88cb9bb4d672c4da929
Reviewed-on: https://chromium-review.googlesource.com/c/665670
Reviewed-by: Vitaliy Shipitsyn <vsh@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/6f8bccb14faf428cbb09677f87946937cf264de4/libdot/js/lib_preference_manager.js
►

Sign in to add a comment