| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change allowed us to handle a missing sync database by creating
a new directory and repopulating it by requesting an initial sync from
the server.
This commit builds on that work by intentionally deleting the sync
database if it is found to be corrupt or unusable. The client will then
recognize that the database is empty and repopulate it, just as it would
had the directory not existed in the first place.
BUG=109668
TEST=Manual. Three cases, see below:
- Delete 'Sync Data/SyncData.sqlite3' from the profile directory. Start
chromium and observe that all data is redownloaded from the server.
- Corrupt an existing sync directory. The SQL command
'DELETE FROM metas WHERE metahandle = 1' should be sufficient. Start
chromium and observe that the directory is deleted then recreated
and all data is redownloaded from the server.
- Ensure that no directory can be created. You could do this by marking
the 'Sync Data' folder as read-only. Start chrome, and observe that
sync is unusable, but the browser still works.
NOTE: This only works in release builds, debug builds will DCHECK.
It's debatable whether or not this scenario is worth testing.
Review URL: https://chromiumcodereview.appspot.com/10554016
TBR=rlarocque@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10578003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142793 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
internal_api/public
TBR=jhawkins@chromium.org
BUG=131130
TEST=
Review URL: https://chromiumcodereview.appspot.com/10534080
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142626 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change allowed us to handle a missing sync database by creating
a new directory and repopulating it by requesting an initial sync from
the server.
This commit builds on that work by intentionally deleting the sync
database if it is found to be corrupt or unusable. The client will then
recognize that the database is empty and repopulate it, just as it would
had the directory not existed in the first place.
BUG=109668
TEST=Manual. Three cases, see below:
- Delete 'Sync Data/SyncData.sqlite3' from the profile directory. Start
chromium and observe that all data is redownloaded from the server.
- Corrupt an existing sync directory. The SQL command
'DELETE FROM metas WHERE metahandle = 1' should be sufficient. Start
chromium and observe that the directory is deleted then recreated
and all data is redownloaded from the server.
- Ensure that no directory can be created. You could do this by marking
the 'Sync Data' folder as read-only. Start chrome, and observe that
sync is unusable, but the browser still works.
NOTE: This only works in release builds, debug builds will DCHECK.
It's debatable whether or not this scenario is worth testing.
Review URL: https://chromiumcodereview.appspot.com/10554016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142563 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old clients would sometimes end up with items that were deleted before
their existence was ever reported to the server. For a while, we let
these entries accumulate in the database, and just filtered them out of
the list of items to commit when we created that list in GetCommitIds.
Then we learned that a subset of these entries could be deleted in such
a manner that they would be detected as database corruption. The client
was udpated so it would delete these entries in a timely manner. The
filter in GetCommitIds was removed. See crbug.com/125381 for details.
It turns out that a lot of clients have some deleted local items in
their sync database created by older clients. When they update to the
new client which doesn't have the GetCommitIds filter, they will try
to commit the local tombstones. This is bad.
This commit addresses the problem in two ways:
1. Drop any server-unknown deleted items when we open the database.
2. As a fallback, put the filter back into GetCommitIds. The filter
should not be required, so it will trigger a NOTREACHED() if it is
executed.
BUG=132905,125381
TEST=SyncableDirectoryTest.OldClientLeftUnsyncedDeletedLocalItem
Review URL: https://chromiumcodereview.appspot.com/10559018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142555 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
chrome/browser/sync.
Note on sync.gyp changes and .cc file moves: most files in /public have .h and their .cc side by side, as they are simple implementations. In some cases like model_type.cc (and others in a follow up patch, like sync_manager.cc) have only their header exposed in /public while the impl stays behind, because it needs to include things from within sync/, and /public has a strict include DEPS policy. This is in accordance with other /public folders (like content/).
Cleans up DEPS files in sync + c/b/sync. Adds sync/{engine, sessions, syncable} to public/. There is more to come (moving things in internal_api/ into public).
Not touching /notifier as that is in flux at the moment.
BUG=131130
TEST=
Review URL: https://chromiumcodereview.appspot.com/10532019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141038 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
SyncSourceInfo out of session_state.
This is in preparation for moving the snapshot et al to internal_api/public.
BUG=131130
TEST=none
Review URL: https://chromiumcodereview.appspot.com/10545010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@140687 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ModelSafeWorkerRegistrar interface was a wrapper around the
SyncBackendRegistrar. When the sync thread wanted to access the
SyncBackendRegistrar's information regarding currently enabled types or
workers, it would use the ModelSafeWorkerRegistrar interface to do it.
This change removes this implicit inter-thread communication. Where
necessary, it modifies the SyncBackendHost, SyncManager, SyncScheduler
and the SyncSessionContext to ensure that these classes have access to a
fresh copy of the SyncBackendRegistrar's data whenever it is required.
The most biggest consequence of this patch is that the
SyncSessionContext now maintains a copy of the list of ModelSafeWorkers
and routing info, rather than a pointer to the ModelSafeWorkerRegistrar.
Various functions along the path to CleanupDisabledTypes, Configure and
StartSyncingNormally have been updated to ensure that the latest routing
info is made available to the session context.
Future patches may refactor this code to reduce the amount of duplicated
state. This work was intentionally left to future patches to reduce the
risk of the current change. The refactoring should be much easier once
we're convinced that the new, explicit inter-thread communication
mechanisms are no more buggy than the existing code.
BUG=103326
TEST=sync_integration_tests
Review URL: https://chromiumcodereview.appspot.com/10388187
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@140122 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since its inception sync has required all commits to be preceded by a
GetUpdates request. This was done to try to ensure we detect and resolve
conflicts on the client, rather than having two conflicting commits
collide at the server. It could never work perfectly, but it was likely
to work in most cases and the server would bounce the commit if it
didn't.
Now we have a new server that doesn't always give us the latest version
of a node when we ask for it, especially when the request was not
solicited by the server (ie. not triggered by notification). The update
before commit is now much less likely to detect conflicts. Even worse,
the useless update requests can be surprisingly expensive in certain
scenarios.
This change allows us to avoid fetching updates between 'batches' of
commits. This should improve performance in the case where we have lots
of items to commit (ie. first time sync) and reduce load on the server.
This CL has some far-reaching effects. This is in part because I decided
to refactor the commit code, but major changes would have been required
with or without the refactor. Highlights include:
- The commit-related SyncerCommands are now paramaterized with local
variables, allowing us to remove many members from the SyncSession
classes.
- Several syncer states have been collapsed into one COMMIT state
which redirects to the new BuildAndPostCommits() function.
- The PostCommitMessageCommand had been reduced to one line, which
has now been inlined into the BuildAndPostCommits() function.
- The unsynced_handles counter has been removed for now. Following this
change, it would have always been zero unless an error was encountered
during the commit. The functions that reference it expect different
behaviour and would have been broken by this change.
- The code to put extensions activity data back into the
ExtensionsActivityMonitor in case of failure has been moved around to
avoid double-counting if we have to post many commit messages.
- A CONFLICT response from the server is now treated as a transient
error. If we had continued to treat it as a success we might risk
going into an infinite loop. See comment in code for details.
- The "purposeless anachronism" conflicting_new_folder_ids_ has been
removed.
Review URL: https://chromiumcodereview.appspot.com/10210009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@139159 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reduce unnecessary fragmentation.
On several of my modestly sized accounts (~7000 items total) this reduced peak sync related memory consumption by an average of 14MB. Anecdotal evidence suggests larger accounts (many have 7000 or more autofill items alone) will see a nominal drop of over 50MB, which starts to become more than a drop in the bucket.
I don't love this solution, because adding any new Put / mutating method on MutableEntry means remembering to add a call to SaveOriginals. This is somewhat mitigated by the fact that MutableEntry is quite stable and virtually never changes, and this change is small, easy to understand, and fully addresses the issue.
BUG=127274
TEST=sync_unit_tests
Review URL: https://chromiumcodereview.appspot.com/10441025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@138991 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Streamline methods of PushClient and its Observer subclass.
Remove sync/protocol/service_constants.h and consolidate use of each
constant in one place. Remove duplicate constant in cloud print code.
BUG=76764
TEST=
TBR=estade@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10398051
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@137615 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, if we were to delete a newly-created item before
informing the sync server of its existence, it would end up in an
unusual state. We do not commit deleted items unless they were known to
sync server. However, these items were still considered to be
'unsynced' (ie. waiting to be committed to the server) and therefore
impossible to entirely remove from the sync directory. They remain
forever both IS_DEL and IS_UNSYNCED.
This had a few side-effects. The most serious is that this behaviour
could cause directory corruption. If we created a folder and a bookmark
within it, then deleted that bookmark before it had a chance to sync,
the bookmark would remain in a zombie state. When we finally got around
to committing its parent folder, the folder's ID will change. The
zombie bookmark's PARENT_ID will not be updated, leaving us with a
dangling reference that will be detected as directory corruption the
next time sync is loaded. See crbug.com/125381 for details.
Another effect is that locally deleted, never synced UNIQUE_CLIENT_TAG
could have strange effects later on. If a foreign client were to create
an item with the same UNIQUE_CLIENT_TAG and sync it, this client would
conflict-resolve the update against the zombie entry. The zombie entry
would win, the newly created item would be deleted, and the deletion
synced back to the server. This may not be an entirely bad thing, but
it is a behaviour that's changed following this patch. From now on, the
deleted item will be overwritten (if it still exists, which it probably
won't).
Finally, we now have a mechanism for permanently deleting these items.
With this patch applied, these items will no longer have the unsynced
bit set, so they will be deleted on restart by DropDeletedEntries().
This patch changes PutIsDel() to clear the IS_UNSYNCED bit of entries
which were never committed to the sync server. The remainder of the
changes either add or update existing tests.
BUG=125381
TEST=SyncerTest.ClientTagUncommittedTagMatchesUpdate,
SyncableDirectoryTest.ChangeEntryIDAndUpdateChildren_DeletedAndUnsyncedChildren
Review URL: https://chromiumcodereview.appspot.com/10389103
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@137476 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
clearing bound variables, so and current row is reset to the beginning.
It is used to support the Andorid' sqlite cursor feature which could move the cursor around the result set.
BUG=
TEST=Added a new test.
TBR=agl,akalin,michaeln
Review URL: http://codereview.chromium.org/10171014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@133985 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it was an immutable struct that was passed around by making
dynamic allocations and passing pointers. We now just have a class with
only getters and no setters, but support for default copy and assign.
This cleans up some code and makes some future work easier to pass snapshots
around.
BUG=none
TEST=sync_unit_tests
Review URL: http://codereview.chromium.org/10197004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@133747 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
| |
original or not.
BUG=121587
TEST=
Review URL: http://codereview.chromium.org/10117011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@132880 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The search tab of chrome://sync would previously perform a string search
of a select set of fields. This change modifies the search behaviour to
instead perform a regex match against a serialized version of the node.
Part of this change is to move the searching function out of C++ and
into JavaScript. When a search is performed, all nodes are loaded from
the database, marshalled, and sent over the fence to the JavaScript side
of things. This comes with a significant performance cost, but it's not
much worse than a search matching all nodes would have been under the
old system.
While there was no such thing as an invalid search string under the
old system, it is possible to enter an invalid regex. This change adds
some logic to alert the user if their search query is not a valid regex
(ie. if it ends with a backslash).
In order to make it easier to formulate queries, the way we display
results has been changed. The right pane will now display the
serialization of the raw node (which exactly reflects the text that was
searched) rather than the "details" used in the old system. This new
format is a subset of the old, and corresponds to the dictionary value
found under "entry" in the old display.
Finally, this change removes support for some JavaScript calls that are
no longer used.
This change fixes JavaScript style-checker issues in the files that it
touches.
BUG=104574, 122021
TEST=
Review URL: http://codereview.chromium.org/9836100
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@132259 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9969114
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130670 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a flag to the SyncManager to allow it to initialize an in-memory
directory. This is to be used only in tests.
This is an ugly change, but there's not much alternative available right
now. We really ought to figure out a better way to test the SyncManager
that doesn't require cluttering the main class with flag variables.
That task is left to another day.
Using an in-memory database results in significant speedups. The time
taken to run sync_unit_tests on my desktop went from 13s to 6s. It
seems to cut 10-20s off the runtime of unit_test
--gtest_filter='*Sync*', too.
BUG=116328, 117836
TEST=
Review URL: http://codereview.chromium.org/9662019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@127255 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
| |
BUG=
TEST=base_unittests
TBR=abodenha@chromium.org,ajwong@chromium.org,chocobo@chromium.org,mnissler@chromium.org,akalin@chromium.org,brettw@chromium.org,arv@chromium.org
Review URL: http://codereview.chromium.org/9590002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@127080 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
Also move related test files.
Move WriteNode::UpdateEntryWithEncryption to nigori_util.h.
Clean up defines and dependencies. In particular, get rid of SYNC_ENGINE_VERSION_STRING and hard-code the string in the single place it's used.
Rename data_encryption.* to data_encryption_win.* and add a pragma for crypt32.lib.
Clean up exit-time constructor warnings in sync{able,er}_unittest.cc.
Remove some unused files.
BUG=117585
TEST=
TBR=jhawkins@chromium.org
Review URL: https://chromiumcodereview.appspot.com/9699057
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@126872 0039d316-1c4b-4281-b951-d872f2087c98
|
