1. 03 Jul, 2016 1 commit
  2. 30 Jun, 2016 1 commit
  3. 26 Jun, 2016 2 commits
  4. 25 Jun, 2016 1 commit
  5. 24 Jun, 2016 2 commits
  6. 21 Jun, 2016 2 commits
    • Daniel Vrátil's avatar
      Merge branch 'Applications/16.04' · 6d069785
      Daniel Vrátil authored
    • Daniel Vrátil's avatar
      Fix read-after-free in CollectionStatistics · 6f32336b
      Daniel Vrátil authored
      CollectionStatistics lives in a separate thread. Returning the Statistics
      structure as a reference to other threads than means that the structure
      can be deleted in the CollectionStatistics thread while other threads
      are still holding a reference. We now return a copy of the Statistics
      struct instead, it's just four ints.
      Thanks to Andreas Schneider for pointing out the issue.
  7. 18 Jun, 2016 6 commits
  8. 16 Jun, 2016 3 commits
  9. 12 Jun, 2016 1 commit
  10. 05 Jun, 2016 3 commits
  11. 04 Jun, 2016 5 commits
  12. 02 Jun, 2016 2 commits
  13. 31 May, 2016 6 commits
  14. 30 May, 2016 5 commits
    • Daniel Vrátil's avatar
      Introduce thread-safe Entity::retrieveByNameOrCreate() · 3b608051
      Daniel Vrátil authored
      During DB initialization when multiple resources try to synchronize
      and insert first item, the mimetypes, parttypes and other similar
      tables are empty and the entries need to be created. This presents
      a race condition when multiple threads try to create the new entry
      at the same time - one of them is succesfull, the others usually
      abort, which leads to the resource failing the synchronization.
      retrieveByNameOrCreate() will try to retrieve the item from cache
      or DB first. If it does not get any result it tries to acquire a
      lock. If the thread gets a lock it inserts the new entry into DB
      and cache. Otherwise the thread just waits for the lock (i.e. until
      the thread that acquired the lock inserts the new entity) and then
      retrieves the entity from the cache.
      This isn't really a common situation, which would happen during normal
      usage of Akonadi. We however see it quite often during unit-test
      initialization when all three Knut resources start pushing their
      data into Akonadi at the same time and trigger this race condition.
    • Daniel Vrátil's avatar
      Merge branch 'Applications/16.04' · 7c044c4b
      Daniel Vrátil authored
    • Daniel Vrátil's avatar
      Jobs: make sure all subjobs are finished before emitting result() · 3d35aaf1
      Daniel Vrátil authored
      This affects mostly CollectionSync, which would emit result() signal
      while a CommitTransaction subjob was still running. This caused the
      response to the CommitTransaction to be delivered to subsequent job
      started after the CollectionSync and was causing all kinds of havoc
      (like CollectionFetchJob emitting result() twice - once because of
      the CommitTransaction response not addressed to it and second time
      once the actual CFJ response arrived) in both clients and resources.
    • Daniel Vrátil's avatar
      Fix CollectionCopyJob expecting wrong type of response · 04a1db61
      Daniel Vrátil authored
      The CollectionCopyJob was expecting CreateCollection response instead
      of CopyCollection, causing it to trigger warning every time. Luckily
      no harm done there, since the job does not expect the Response to
      contain any data and only takes it as an indicator of result.
    • Laurent Montel's avatar