1. 15 Jul, 2011 9 commits
  2. 14 Jul, 2011 2 commits
  3. 13 Jul, 2011 2 commits
  4. 07 Jul, 2011 5 commits
  5. 06 Jul, 2011 1 commit
  6. 01 Jul, 2011 1 commit
  7. 29 Jun, 2011 1 commit
    • David Woodhouse's avatar
      Fix synchronisation issues with refresh vs. update of folders. · 07bc7a9f
      David Woodhouse authored
      I've seen it get into a state where the server no longer likes its sync key.
      
      This seemed to happen when two threads in mail client submitted requests
      almost simultaneously. First a sync_folder_info(), then an update_email(),
      both using the same sync_key (309454454).
      
      First the response to the sync comes back, with a *new* sync key (669109276)
      and some notification of new email.
      
      And then the response to the update comes back, with *another* new sync key
      (974600193). I expect that the server, upon seeing our update request with
      the out-of-date sync key, has assumed that we crashed before saving the
      results of our previous sync to storage, so we've taken a step back in time.
      It's perfectly justified in *forgetting* the 669109276 sync key at this point.
      
      All well and good, and all is still working. But then we try to fetch an
      email that we were told about in that sync response that the server thinks
      we've forgotten. And the server thinks we're confused, so it gives us an
      error.
      
      Later, we try another sync, and somehow that 'forgotten' sync_key 669109276
      is the one that got saved; probably just because it took much longer to
      process that response and marshal all the data for the new mails back across
      DBus.
      
      So we try another sync with a sync key that the server thought we'd
      forgotten, and then we get a 'sync key invalid' error.
      
      The simple approach is a per-folder lock around everything that talks to the
      server about this particular folder. We probably don't need it for the email
      fetch, but it's easier to include it than to prove that it's not necessary,
      and the dæmon is only doing one request at a time for now *anyway* so there's
      no benefit to that. Yet.
      
      From the debug log...
       REQUEST:
      1065938:<Sync xmlns="AirSync:" xmlns:airsyncbase="AirSyncBase:">
      1065939:  <Collections>
      1065940:    <Collection>
      1065941:      <SyncKey>309454454</SyncKey>
      1065942:      <CollectionId>12</CollectionId>
      1065943:      <DeletesAsMoves>1</DeletesAsMoves>
      1065944:      <GetChanges>1</GetChanges>
      
       REQUEST:
      1066043:<Sync xmlns="AirSync:" xmlns:airsyncbase="AirSyncBase:" xmlns:email="Email:">
      1066044:  <Collections>
      1066045:    <Collection>
      1066046:      <SyncKey>309454454</SyncKey>
      1066047:      <CollectionId>12</CollectionId>
      1066048:      <DeletesAsMoves>1</DeletesAsMoves>
      1066049:      <GetChanges>0</GetChanges>
      1066050:      <Commands>
      1066051:        <Change>
      1066052:          <ServerId>12:1495</ServerId>
      1066053:          <ApplicationData>
      1066054:            <Read>1</Read>
      1066055:          </ApplicationData>
      1066056:        </Change>
      
       RESPONSE:
      1066093:<Sync xmlns="AirSync:">
      1066094: <Collections>
      1066095:  <Collection>
      1066096:   <SyncKey>669109276</SyncKey>
      1066097:   <CollectionId>12</CollectionId>
      1066098:   <Status>1</Status>
      1066099:   <Commands>
      1066100:    <Add>
      1066101:     <ServerId>12:1496</ServerId>
      		 ...
      
       RESPONSE:
      1066779:<Sync xmlns="AirSync:">
      1066780: <Collections>
      1066781:  <Collection>
      1066782:   <SyncKey>974600193</SyncKey>
      1066783:   <CollectionId>12</CollectionId>
      1066784:   <Status>1</Status>
      
       REQUEST:
      1067067:  <Fetch>
      1067068:    <Store>Mailbox</Store>
      1067069:    <airsync:CollectionId>12</airsync:CollectionId>
      1067070:    <airsync:ServerId>12:1498</airsync:ServerId>
      
       RESPONSE:
      1067104:  <Fetch>
      1067105:   <Status>6</Status>
      1067106:   <CollectionId xmlns="AirSync:">12</CollectionId>
      1067107:   <ServerId xmlns="AirSync:">12:1498</ServerId>
      
       REQUEST:
      1067371:<Sync xmlns="AirSync:" xmlns:airsyncbase="AirSyncBase:">
      1067372:  <Collections>
      1067373:    <Collection>
      1067374:      <SyncKey>669109276</SyncKey>
      1067375:      <CollectionId>12</CollectionId>
      1067376:      <DeletesAsMoves>1</DeletesAsMoves>
      1067377:      <GetChanges>1</GetChanges>
      
       RESPONSE:
      1067415:   <SyncKey>669109276</SyncKey>
      1067416:   <CollectionId>12</CollectionId>
      1067417:   <Status>3</Status>
      07bc7a9f
  8. 24 Jun, 2011 2 commits
  9. 23 Jun, 2011 2 commits
  10. 21 Jun, 2011 1 commit
  11. 20 Jun, 2011 3 commits
  12. 19 Jun, 2011 1 commit
  13. 17 Jun, 2011 10 commits