searching for reviewer(rnewman)
a803056762bb6ac51a924459a7f1d345703d0826: Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman, a=jcristau
Nick Alexander <nalexander@mozilla.com> - Wed, 25 Apr 2018 12:17:05 -0700 - rev 790452
Push
108516 by bmo:jlorenzo@mozilla.com at Wed, 02 May 2018 09:32:32 +0000
Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman, a=jcristau
The behaviour of Android Firefox Account instances recently changed in
the face of system "Clear data" commands. To align more closely with
common Apps like Dropbox and Whatsapp (which generally don't use
Android Account instances), after a "Clear data" a Firefox Account is
moved to the Separated state, requiring the user to re-connect them
with a password challenge. To achieve this, newly created accounts
include a first run UUID; after a "Clear data", the App is killed and
restarted, Sync sees a different first run UUID, and the Account is
moved to the Separated state. (I honestly don't know what happens if
the Sync code never sees a different first run UUID, but that's for
another day.) If the user then, in the same first run session,
re-connects the Firefox Account... the Sync code will again see the
different first run UUID and move the Account to the Separated state.
This patch updates the first run UUID when the Account is
re-connected, breaking that cycle.
MozReview-Commit-ID: 9jcO9Ym54an
df36fee2b3acada69d9bd43b4febc48707adc801: Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman
Nick Alexander <nalexander@mozilla.com> - Wed, 25 Apr 2018 12:17:05 -0700 - rev 788216
Push
107916 by bmo:jaws@mozilla.com at Thu, 26 Apr 2018 00:14:29 +0000
Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman
The behaviour of Android Firefox Account instances recently changed in
the face of system "Clear data" commands. To align more closely with
common Apps like Dropbox and Whatsapp (which generally don't use
Android Account instances), after a "Clear data" a Firefox Account is
moved to the Separated state, requiring the user to re-connect them
with a password challenge. To achieve this, newly created accounts
include a first run UUID; after a "Clear data", the App is killed and
restarted, Sync sees a different first run UUID, and the Account is
moved to the Separated state. (I honestly don't know what happens if
the Sync code never sees a different first run UUID, but that's for
another day.) If the user then, in the same first run session,
re-connects the Firefox Account... the Sync code will again see the
different first run UUID and move the Account to the Separated state.
This patch updates the first run UUID when the Account is
re-connected, breaking that cycle.
MozReview-Commit-ID: 9jcO9Ym54an
be92a7ab0f36563e7b3af69f42095dc2b244bdd2: Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman
draft
Nick Alexander <nalexander@mozilla.com> - Wed, 25 Apr 2018 12:17:05 -0700 - rev 788074
Push
107891 by nalexander@mozilla.com at Wed, 25 Apr 2018 22:07:06 +0000
Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman
The behaviour of Android Firefox Account instances recently changed in
the face of system "Clear data" commands. To align more closely with
common Apps like Dropbox and Whatsapp (which generally don't use
Android Account instances), after a "Clear data" a Firefox Account is
moved to the Separated state, requiring the user to re-connect them
with a password challenge. To achieve this, newly created accounts
include a first run UUID; after a "Clear data", the App is killed and
restarted, Sync sees a different first run UUID, and the Account is
moved to the Separated state. (I honestly don't know what happens if
the Sync code never sees a different first run UUID, but that's for
another day.) If the user then, in the same first run session,
re-connects the Firefox Account... the Sync code will again see the
different first run UUID and move the Account to the Separated state.
This patch updates the first run UUID when the Account is
re-connected, breaking that cycle.
MozReview-Commit-ID: 9jcO9Ym54an
170735bbe59f488b9c78f57ac11ae12fd2fa430e: Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman
draft
Nick Alexander <nalexander@mozilla.com> - Wed, 25 Apr 2018 12:17:05 -0700 - rev 787985
Push
107864 by nalexander@mozilla.com at Wed, 25 Apr 2018 19:17:46 +0000
Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman
The behaviour of Android Firefox Account instances recently changed in
the face of system "Clear data" commands. To align more closely with
common Apps like Dropbox and Whatsapp (which generally don't use
Android Account instances), after a "Clear data" Firefox Account's are
moved to the Separated state, requiring the user to re-connect them
with a password challenge. To achieve this, newly created accounts
include a first run UUID; after a "Clear data", the App is killed and
restarted, Sync sees a different first run UUID, and the Account is
moved to the Separated state. (I honestly don't know what happens if
the Sync code never sees a different first run UUID, but that's for
another day.) If the user then, in the same first run session,
re-connects the Firefox Account... the Sync code will again see the
different first run UUID and move the Account to the Separated state.
This patch updates the first run UUID when the Account is
re-connected, breaking that cycle.
MozReview-Commit-ID: 9jcO9Ym54an
2d9c633028adf9a9bf47c918314684a79195254e: Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted. r=rnewman, a=jcristau
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:14:23 -0400 - rev 774289
Push
104369 by mixedpuppy@gmail.com at Wed, 28 Mar 2018 19:17:18 +0000
Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted. r=rnewman, a=jcristau
This should have been a part of
Bug 1408710, but alas, here we are.
Patch changes two things:
- serializes process failures in BatchingUploader if record-to-be-uploaded fails sanity checks and server requirements
-- this helps us short-circuit flow in RecordsChannel
- avoids performing any work in ServerSession's storeDone if flow has been aborted
MozReview-Commit-ID: 9qevdzRvHEx
ab70ed8311a24c380d7e5f215444f166b74c7827: Bug 1445462 - Pre: Clean up "ignore records on batch failure" code. r=rnewman, a=jcristau
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:12:48 -0400 - rev 774288
Push
104369 by mixedpuppy@gmail.com at Wed, 28 Mar 2018 19:17:18 +0000
Bug 1445462 - Pre: Clean up "ignore records on batch failure" code. r=rnewman, a=jcristau
No functional change; added tests to cover the decision tree a bit better, renamed stuff.
MozReview-Commit-ID: LwvyBaAg421
30867952db101a3083b61699ddc97a40b804d6ea: Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:14:23 -0400 - rev 767772
Push
102689 by bmo:kit@mozilla.com at Thu, 15 Mar 2018 00:41:35 +0000
Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted r=rnewman
This should have been a part of
Bug 1408710, but alas, here we are.
Patch changes two things:
- serializes process failures in BatchingUploader if record-to-be-uploaded fails sanity checks and server requirements
-- this helps us short-circuit flow in RecordsChannel
- avoids performing any work in ServerSession's storeDone if flow has been aborted
MozReview-Commit-ID: 9qevdzRvHEx
53395fa976d3643bbf79a58b172732c27a1306c9: Bug 1445462 - Pre: Clean up "ignore records on batch failure" code r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:12:48 -0400 - rev 767771
Push
102689 by bmo:kit@mozilla.com at Thu, 15 Mar 2018 00:41:35 +0000
Bug 1445462 - Pre: Clean up "ignore records on batch failure" code r=rnewman
No functional change; added tests to cover the decision tree a bit better, renamed stuff.
MozReview-Commit-ID: LwvyBaAg421
2e30aa7e222916acb791a9803bab0d4d95e5e491: Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:14:23 -0400 - rev 767485
Push
102617 by bmo:gkruglov@mozilla.com at Wed, 14 Mar 2018 18:17:37 +0000
Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted r=rnewman
This should have been a part of
Bug 1408710, but alas, here we are.
Patch changes two things:
- serializes process failures in BatchingUploader if record-to-be-uploaded fails sanity checks and server requirements
-- this helps us short-circuit flow in RecordsChannel
- avoids performing any work in ServerSession's storeDone if flow has been aborted
MozReview-Commit-ID: 9qevdzRvHEx
4e46be5f67317f6bd5ea0c4701587908a3628634: Bug 1445462 - Pre: Clean up "ignore records on batch failure" code r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:12:48 -0400 - rev 767484
Push
102617 by bmo:gkruglov@mozilla.com at Wed, 14 Mar 2018 18:17:37 +0000
Bug 1445462 - Pre: Clean up "ignore records on batch failure" code r=rnewman
No functional change; added tests to cover the decision tree a bit better, renamed stuff.
MozReview-Commit-ID: LwvyBaAg421
f53ab4fbab7347ac9f34a965867a8bfbbd7f0892: Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 13 Mar 2018 17:40:48 -0400 - rev 767068
Push
102506 by bmo:gkruglov@mozilla.com at Tue, 13 Mar 2018 21:41:24 +0000
Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted r=rnewman
This should have been a part of
Bug 1408710, but alas, here we are.
Patch changes two things:
- serializes process failures in BatchingUploader if record-to-be-uploaded fails sanity checks and server requirements
-- this helps us short-circuit flow in RecordsChannel
- avoids performing any work in ServerSession's storeDone if flow has been aborted
MozReview-Commit-ID: in6GGep14F
ef963ffb6d1b214b9c7f7687012a0698ab018a7b: Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:21 -0500 - rev 760305
Push
100603 by jcristau@mozilla.com at Tue, 27 Feb 2018 11:10:29 +0000
Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
We don't use these GUIDs anywhere, and this change lets us kill off some expensive data structures necessary
to maintain lists of successfully uploaded GUIDs, particularly during an upload.
MozReview-Commit-ID: F0kcY8o8DUw
a2227052b4aa09a3b14aed01ff48f6e525904cb3: Bug 1408710 - Serialize RecordsChannel r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:34 -0500 - rev 760304
Push
100603 by jcristau@mozilla.com at Tue, 27 Feb 2018 11:10:29 +0000
Bug 1408710 - Serialize RecordsChannel r=rnewman
This patch does two things:
- serializes flow of records through the RecordsChannel
- simplifies the batching logic
The two are connected: rather than queuing records in ConcurrentLinkedQueue, we now buffer
downloaded records in an ArrayList, and deliver them to the receiving repository all at once.
Doing this work right at the channel level lets us kill off the buffering middleware.
An addition of a NonBufferingSyncStage lets individual SyncStages use a RecordsChannel which
doesn't perform any kind of buffering. Prior, stages did this by wrapping their receiving repositories
in the buffering middleware.
The main goal is to speed up the flow of records, keep within the same memory footprint
and do some simplification in the process.
This patch explicitly does not address the delegated nature of fetch and store, which is now largely irrelevant.
MozReview-Commit-ID: J2afmgr1Td1
430a0bfcdb9372d4d56845ac5c7e330d96f421ab: Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:54:53 -0500 - rev 760303
Push
100603 by jcristau@mozilla.com at Tue, 27 Feb 2018 11:10:29 +0000
Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
From the point of view of the session itself, this queue is named correctly (e.g. session's abort and finish
methods make sure invoke success and failure delegate methods from this queue).
However, from the point of view of every concrete implementation of the session, the current naming isn't clear.
New name is for symmetry with the store queue, and the above ambiquity is addressed in the comment.
MozReview-Commit-ID: 61j7ZCNdr4x
82986cd4578a8a93010c97ac69ccfd9805fdb930: Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:41:20 -0500 - rev 760302
Push
100603 by jcristau@mozilla.com at Tue, 27 Feb 2018 11:10:29 +0000
Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
This is a clean-up. Everywhere else, we run the fetch tasks and corresponding delegates on the delegateQueue.
MozReview-Commit-ID: Kd8XZAclJIB
42ccbb911db3b7f5393dbf5dae6c31c53d4887df: Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 14 Nov 2017 15:29:57 -0500 - rev 760301
Push
100603 by jcristau@mozilla.com at Tue, 27 Feb 2018 11:10:29 +0000
Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
Theoretical ability to setup synchronizers other than server->local never really
manifested itself in anything actually useful, and I don't foresee that design choice
as currently expressed being useful in the near future. So, let's take a moment to clear
up the layers a little bit.
MozReview-Commit-ID: 5fIZc6zYeit
e7443ffabde02059008e6c833ee52c45e206ec81: Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:21 -0500 - rev 760195
Push
100565 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:36:11 +0000
Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
We don't use these GUIDs anywhere, and this change lets us kill off some expensive data structures necessary
to maintain lists of successfully uploaded GUIDs, particularly during an upload.
MozReview-Commit-ID: F0kcY8o8DUw
62f5f7940bb8db9a18704edfd0b9cb38eb410b71: Bug 1408710 - Serialize RecordsChannel r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:34 -0500 - rev 760194
Push
100565 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:36:11 +0000
Bug 1408710 - Serialize RecordsChannel r=rnewman
This patch does two things:
- serializes flow of records through the RecordsChannel
- simplifies the batching logic
The two are connected: rather than queuing records in ConcurrentLinkedQueue, we now buffer
downloaded records in an ArrayList, and deliver them to the receiving repository all at once.
Doing this work right at the channel level lets us kill off the buffering middleware.
An addition of a NonBufferingSyncStage lets individual SyncStages use a RecordsChannel which
doesn't perform any kind of buffering. Prior, stages did this by wrapping their receiving repositories
in the buffering middleware.
The main goal is to speed up the flow of records, keep within the same memory footprint
and do some simplification in the process.
This patch explicitly does not address the delegated nature of fetch and store, which is now largely irrelevant.
MozReview-Commit-ID: J2afmgr1Td1
5f4092c2629414fc4f9051d8f8f0c113f1d6910d: Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:54:53 -0500 - rev 760193
Push
100565 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:36:11 +0000
Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
From the point of view of the session itself, this queue is named correctly (e.g. session's abort and finish
methods make sure invoke success and failure delegate methods from this queue).
However, from the point of view of every concrete implementation of the session, the current naming isn't clear.
New name is for symmetry with the store queue, and the above ambiquity is addressed in the comment.
MozReview-Commit-ID: 61j7ZCNdr4x
d789ac49c365336c104c4e66c9826bf387d85465: Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:41:20 -0500 - rev 760192
Push
100565 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:36:11 +0000
Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
This is a clean-up. Everywhere else, we run the fetch tasks and corresponding delegates on the delegateQueue.
MozReview-Commit-ID: Kd8XZAclJIB
301a7552fe090e29e013d9e73ca9ca34976ee100: Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 14 Nov 2017 15:29:57 -0500 - rev 760191
Push
100565 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:36:11 +0000
Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
Theoretical ability to setup synchronizers other than server->local never really
manifested itself in anything actually useful, and I don't foresee that design choice
as currently expressed being useful in the near future. So, let's take a moment to clear
up the layers a little bit.
MozReview-Commit-ID: 5fIZc6zYeit
9991bc50a21a7d476b0e460ef7a4d2858e39bc93: Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:21 -0500 - rev 760190
Push
100564 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:17:34 +0000
Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
We don't use these GUIDs anywhere, and this change lets us kill off some expensive data structures necessary
to maintain lists of successfully uploaded GUIDs, particularly during an upload.
MozReview-Commit-ID: F0kcY8o8DUw
c6f578069aafca9a2ed59d454bd11d32f39f51c6: Bug 1408710 - Serialize RecordsChannel r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:34 -0500 - rev 760189
Push
100564 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:17:34 +0000
Bug 1408710 - Serialize RecordsChannel r=rnewman
This patch does two things:
- serializes flow of records through the RecordsChannel
- simplifies the batching logic
The two are connected: rather than queuing records in ConcurrentLinkedQueue, we now buffer
downloaded records in an ArrayList, and deliver them to the receiving repository all at once.
Doing this work right at the channel level lets us kill off the buffering middleware.
An addition of a NonBufferingSyncStage lets individual SyncStages use a RecordsChannel which
doesn't perform any kind of buffering. Prior, stages did this by wrapping their receiving repositories
in the buffering middleware.
The main goal is to speed up the flow of records, keep within the same memory footprint
and do some simplification in the process.
This patch explicitly does not address the delegated nature of fetch and store, which is now largely irrelevant.
MozReview-Commit-ID: J2afmgr1Td1
99e97615b6ca7424b945776354019e508118e707: Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:54:53 -0500 - rev 760188
Push
100564 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:17:34 +0000
Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
From the point of view of the session itself, this queue is named correctly (e.g. session's abort and finish
methods make sure invoke success and failure delegate methods from this queue).
However, from the point of view of every concrete implementation of the session, the current naming isn't clear.
New name is for symmetry with the store queue, and the above ambiquity is addressed in the comment.
MozReview-Commit-ID: 61j7ZCNdr4x
6782fcfdf289ad562dff3b2c460a30cc052f182a: Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:41:20 -0500 - rev 760187
Push
100564 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:17:34 +0000
Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
This is a clean-up. Everywhere else, we run the fetch tasks and corresponding delegates on the delegateQueue.
MozReview-Commit-ID: Kd8XZAclJIB
09a15c9692ad55b07083070a4f083b6de09605f9: Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 14 Nov 2017 15:29:57 -0500 - rev 760186
Push
100564 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 23:17:34 +0000
Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
Theoretical ability to setup synchronizers other than server->local never really
manifested itself in anything actually useful, and I don't foresee that design choice
as currently expressed being useful in the near future. So, let's take a moment to clear
up the layers a little bit.
MozReview-Commit-ID: 5fIZc6zYeit
5fb3e03702ec9b4ad0eab9f030946b13c426ea8d: Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:21 -0500 - rev 759926
Push
100514 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 20:13:52 +0000
Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
We don't use these GUIDs anywhere, and this change lets us kill off some expensive data structures necessary
to maintain lists of successfully uploaded GUIDs, particularly during an upload.
MozReview-Commit-ID: F0kcY8o8DUw
db8582f6e17494fb8c4f90114971bc8c3b2992a4: Bug 1408710 - Serialize RecordsChannel r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:34 -0500 - rev 759925
Push
100514 by bmo:gkruglov@mozilla.com at Mon, 26 Feb 2018 20:13:52 +0000
Bug 1408710 - Serialize RecordsChannel r=rnewman
This patch does two things:
- serializes flow of records through the RecordsChannel
- simplifies the batching logic
The two are connected: rather than queuing records in ConcurrentLinkedQueue, we now buffer
downloaded records in an ArrayList, and deliver them to the receiving repository all at once.
Doing this work right at the channel level lets us kill off the buffering middleware.
An addition of a NonBufferingSyncStage lets individual SyncStages use a RecordsChannel which
doesn't perform any kind of buffering. Prior, stages did this by wrapping their receiving repositories
in the buffering middleware.
The main goal is to speed up the flow of records, keep within the same memory footprint
and do some simplification in the process.
This patch explicitly does not address the delegated nature of fetch and store, which is now largely irrelevant.
MozReview-Commit-ID: J2afmgr1Td1
ffffdb225d2dabfdf1fc1f23ba0e7d94d7f53363: Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 23 Feb 2018 21:57:11 -0500 - rev 759341
Push
100339 by bmo:gkruglov@mozilla.com at Sat, 24 Feb 2018 03:10:29 +0000
Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
We don't use these GUIDs anywhere, and this change lets us kill off some expensive data structures necessary
to maintain lists of successfully uploaded GUIDs, particularly during an upload.
MozReview-Commit-ID: F0kcY8o8DUw
cf979a98590c0651b5f691f103e0c86db616a7e7: Bug 1408710 - Serialize RecordsChannel r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 23 Feb 2018 19:17:01 -0500 - rev 759277
Push
100331 by bmo:gkruglov@mozilla.com at Sat, 24 Feb 2018 00:27:25 +0000
Bug 1408710 - Serialize RecordsChannel r=rnewman
This patch does two things:
- serializes flow of records through the RecordsChannel
- simplifies the batching logic
The two are connected: rather than queuing records in ConcurrentLinkedQueue, we now buffer
downloaded records in an ArrayList, and deliver them to the receiving repository all at once.
Doing this work right at the channel level lets us kill off the buffering middleware.
An addition of a NonBufferingSyncStage lets individual SyncStages use a RecordsChannel which
doesn't perform any kind of buffering. Prior, stages did this by wrapping their receiving repositories
in the buffering middleware.
The main goal is to speed up the flow of records, keep within the same memory footprint
and do some simplification in the process.
This patch explicitly does not address the delegated nature of fetch and store, which is now largely irrelevant.
MozReview-Commit-ID: J2afmgr1Td1
f61359fd4ee126c7e04f4b2bbc6bdee7bb4176f9: Bug 1408710 - Serialize RecordsChannel r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 23 Feb 2018 19:17:01 -0500 - rev 759260
Push
100326 by bmo:gkruglov@mozilla.com at Sat, 24 Feb 2018 00:17:42 +0000
Bug 1408710 - Serialize RecordsChannel r=rnewman
This patch does two things:
- serializes flow of records through the RecordsChannel
- simplifies the batching logic
Main goal is to speed up the flow of records without regressing memory consumption.
This patch explicitly does not address the delegated nature of fetch and store,
although it is not largely irrelevant.
MozReview-Commit-ID: J2afmgr1Td1
5181d4de046b33285f53b44b6e514688dce912b9: Bug 1408710 - Serialize RecordsChannel r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 23 Feb 2018 18:59:33 -0500 - rev 759257
Push
100323 by bmo:gkruglov@mozilla.com at Sat, 24 Feb 2018 00:06:51 +0000
Bug 1408710 - Serialize RecordsChannel r=rnewman
This patch does two things:
- serializes flow of records through the RecordsChannel
- simplifies the batching logic
Main goal is to speed up the flow of records without regressing memory consumption.
This patch explicitly does not address the delegated nature of fetch and store,
although it is not largely irrelevant.
MozReview-Commit-ID: J2afmgr1Td1
d4b8fcbf3b01ac8b4f5af2081bb47ec8d9ddfda8: Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:54:53 -0500 - rev 759256
Push
100323 by bmo:gkruglov@mozilla.com at Sat, 24 Feb 2018 00:06:51 +0000
Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
From the point of view of the session itself, this queue is named correctly (e.g. session's abort and finish
methods make sure invoke success and failure delegate methods from this queue).
However, from the point of view of every concrete implementation of the session, the current naming isn't clear.
New name is for symmetry with the store queue, and the above ambiquity is addressed in the comment.
MozReview-Commit-ID: 61j7ZCNdr4x
5415ed8ad8193640362523a399973825dfab6014: Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:41:20 -0500 - rev 759255
Push
100323 by bmo:gkruglov@mozilla.com at Sat, 24 Feb 2018 00:06:51 +0000
Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
This is a clean-up. Everywhere else, we run the fetch tasks and corresponding delegates on the delegateQueue.
MozReview-Commit-ID: Kd8XZAclJIB
e49e0f9461742880c1af1d9e640ff928c9fdba2e: Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
draft
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 14 Nov 2017 15:29:57 -0500 - rev 759254
Push
100323 by bmo:gkruglov@mozilla.com at Sat, 24 Feb 2018 00:06:51 +0000
Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
Theoretical ability to setup synchronizers other than server->local never really
manifested itself in anything actually useful, and I don't foresee that design choice
as currently expressed being useful in the near future. So, let's take a moment to clear
up the layers a little bit.
MozReview-Commit-ID: 5fIZc6zYeit
d3363d47276bf078c00d6d3bd9d231ebbce4c4b4: Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r=rfkelly,rnewman
Mark Hammond <mhammond@skippinet.com.au> - Thu, 15 Feb 2018 11:55:32 +1100 - rev 759103
Push
100272 by rwood@mozilla.com at Fri, 23 Feb 2018 18:27:33 +0000
Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r=rfkelly,rnewman
MozReview-Commit-ID: GKII0jjVtSf
b330b9ce74213e3dda81e508adc7ce5dfbe43531: Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r?rfkelly,rnewman
draft
Mark Hammond <mhammond@skippinet.com.au> - Thu, 15 Feb 2018 11:55:32 +1100 - rev 758805
Push
100179 by bmo:markh@mozilla.com at Fri, 23 Feb 2018 01:54:41 +0000
Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r?rfkelly,rnewman
MozReview-Commit-ID: GKII0jjVtSf
dc3f1141af957b96076f69640c518ed89e20a3f3: Bug 1431260 - Switch Android code to read multilocale.txt. r=rnewman
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 758344
Push
100035 by kgupta@mozilla.com at Thu, 22 Feb 2018 10:32:06 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r=rnewman
MozReview-Commit-ID: 6S4VaAvDako
390508b64fabfb1f0d5fe4a3350faaccb455b1a2: Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
draft
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 758212
Push
99984 by bmo:gandalf@aviary.pl at Thu, 22 Feb 2018 01:24:42 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
MozReview-Commit-ID: 6S4VaAvDako
9e2c1e805a0a17f14cce5befc42d721320bbe2ea: Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
draft
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 757609
Push
99797 by bmo:gandalf@aviary.pl at Tue, 20 Feb 2018 22:19:29 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
MozReview-Commit-ID: 6S4VaAvDako
10a71ccae7e1f78fefb83d93c44206d3126076a1: Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
draft
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 756633
Push
99508 by bmo:gandalf@aviary.pl at Sat, 17 Feb 2018 03:31:22 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
MozReview-Commit-ID: 6S4VaAvDako
00710bce292106e69e63859a946ed445d85bafc8: Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
draft
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 755973
Push
99346 by bmo:gandalf@aviary.pl at Fri, 16 Feb 2018 06:13:54 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
MozReview-Commit-ID: 6S4VaAvDako
79ed109206e45cfe8d746af04ac04e0fc2c6e51c: Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
draft
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 755970
Push
99345 by bmo:gandalf@aviary.pl at Fri, 16 Feb 2018 05:58:46 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
MozReview-Commit-ID: 6S4VaAvDako
982947fc75c11b3e1df599b6b14b45c0d0f87617: Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
draft
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 755968
Push
99344 by bmo:gandalf@aviary.pl at Fri, 16 Feb 2018 04:29:03 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
MozReview-Commit-ID: 6S4VaAvDako
88ac994b03ffc50c469541717df278ce6ef0513f: Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
draft
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 755945
Push
99337 by bmo:gandalf@aviary.pl at Fri, 16 Feb 2018 02:33:59 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
MozReview-Commit-ID: 6S4VaAvDako
3e1d4584acb20b4b0b201fe0d29363010d0dfa7c: Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
draft
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 755942
Push
99336 by bmo:gandalf@aviary.pl at Fri, 16 Feb 2018 02:24:36 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman
MozReview-Commit-ID: 6S4VaAvDako
613cde6977671daabffb072fd1bed8deb2f9da52: Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r?rfkelly,rnewman
draft
Mark Hammond <mhammond@skippinet.com.au> - Thu, 15 Feb 2018 11:55:32 +1100 - rev 755240
Push
99129 by bmo:markh@mozilla.com at Thu, 15 Feb 2018 00:57:16 +0000
Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r?rfkelly,rnewman
MozReview-Commit-ID: GKII0jjVtSf
19910e66ee8d60661807cbd37a75672993cb493e: Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r?rfkelly,rnewman
draft
Mark Hammond <mhammond@skippinet.com.au> - Thu, 15 Feb 2018 11:55:32 +1100 - rev 755239
Push
99128 by bmo:markh@mozilla.com at Thu, 15 Feb 2018 00:55:54 +0000
Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r?rfkelly,rnewman
MozReview-Commit-ID: GKII0jjVtSf
3b57cf8b376704aeb9591a9e048ce8c9083a6f1f: Bug 1305563 - Add a bookmark mirror and two-way merger for synced bookmarks. r=mak,markh,rnewman,tcsc
Kit Cambridge <kit@yakshaving.ninja> - Sat, 06 Jan 2018 07:44:33 -0800 - rev 748009
Push
97047 by VYV03354@nifty.ne.jp at Sat, 27 Jan 2018 12:00:53 +0000
Bug 1305563 - Add a bookmark mirror and two-way merger for synced bookmarks. r=mak,markh,rnewman,tcsc
The mirror matches the complete bookmark tree stored on the Sync
server, stores new bookmarks changed on the server since the last
sync, merges the local and remote trees, applies the resulting merged
tree back to Places, fires observer notifications for all items changed
in the merge, and stages locally changed bookmarks for upload.
MozReview-Commit-ID: MbeFQUargt
fead51b240528adeb7b9a109a75173fbba3555d4: Bug 1305563 - Add a bookmark mirror and two-way merger for synced bookmarks. r?markh,rnewman,tcsc,mak
draft
Kit Cambridge <kit@yakshaving.ninja> - Sat, 06 Jan 2018 07:44:33 -0800 - rev 747956
Push
97039 by bmo:kit@mozilla.com at Sat, 27 Jan 2018 02:58:34 +0000
Bug 1305563 - Add a bookmark mirror and two-way merger for synced bookmarks. r?markh,rnewman,tcsc,mak
The mirror matches the complete bookmark tree stored on the Sync
server, stores new bookmarks changed on the server since the last
sync, merges the local and remote trees, applies the resulting merged
tree back to Places, fires observer notifications for all items changed
in the merge, and stages locally changed bookmarks for upload.
MozReview-Commit-ID: MbeFQUargt