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