1. 15 Oct, 2020 1 commit
    • Luca Beltrame's avatar
      Increase timeout for reading data from resources to 30 seconds · 9acda8e4
      Luca Beltrame authored
      The introduction of LZMA compression for payloads can mean that when
      handling already-compressed attachments, especially those in large
      sizes, the default timeout of 10 seconds can be exceeded. This is
      particularly evident for machines with rotational disks or full disk
      This has particularly bad effects on item syncing:
      1. The resource retrieves an item, and starts compressing the payload.
      2. The compression takes more than 10 seconds, so the resource is
         disconnected from Akonadi due to the timeout.
      3. Upon reconnection, there is an attempt to rollback the change, but
         the change did not actually take place, so a bunch of errors
         regarding transactions are logged.
      4. The database for that resource and that collection is left in an
         inconsistent state.
      5. This can cause the resource to ultimately get stuck on its jobs.
      Fixing the actual problem is probably far more convoluted, but a quick
      workaround would be to increase the timeout up to 30 seconds, to stay on
      the safe side.
      This change was tested on a laptop with FDE that could not sync
      attachments larger than 5M: after the change, the syncing was performed
  2. 02 Jul, 2020 1 commit
  3. 10 Jun, 2020 1 commit
  4. 03 May, 2020 1 commit
    • David Faure's avatar
      Implement buffering in the DataStream class, to improve performance on Windows. · 0e085b86
      David Faure authored
      The internal QWindowsPipeWriter in Qt doesn't do any buffering, so the first 8
      bytes (the tag) were sent first, and the rest only later.
      This solution uses an explicit flush() method, while doing the flushing
      in the destructor would have been much more convenient and less
      error-prone, but the flushing can throw an exception, so we need
      to do it inside the try/catch -- and certainly not when the stream
      is deleted because another exception happened. This would all be
      so much simpler without the use of exceptions :-)
      Test Plan: all tests pass (on Linux)
      Reviewers: dvratil, kfunk
      Reviewed By: dvratil
      Subscribers: kde-pim
      Tags: #kde_pim
      Differential Revision: https://phabricator.kde.org/D29265
  5. 10 Apr, 2020 1 commit
  6. 26 Feb, 2020 1 commit
  7. 16 Jan, 2020 1 commit
  8. 06 Jan, 2020 1 commit
  9. 04 Jan, 2020 2 commits
  10. 02 Jan, 2020 2 commits
  11. 09 Dec, 2019 1 commit
  12. 19 Jun, 2019 1 commit
  13. 31 May, 2019 1 commit
    • Daniel Vrátil's avatar
      Fix a crash due to weird refcount messup during stack unwinding · 7f104d75
      Daniel Vrátil authored
      My Akonadi Server has been crashing repeatadly whenever an exception was
      thrown inside a handler. The crash was due to memory corruption when
      stack unwinding caused the refcount of the "cmd" shared pointer to get
      messed up which lead to double-free corruption.
      The problem seems to be in the capture-by-value of the shared pointer in the
      lambda, but I do not exactly understand what causes the problem, neither
      was I able to produce a minimal reproducer case.
      We can safely capture the shared pointer by reference, we don't keep a
      reference to the functor anywhere.
      Reviewers: #kde_pim, vkrause
      Reviewed By: #kde_pim, vkrause
      Subscribers: kde-pim
      Tags: #kde_pim
      Differential Revision: https://phabricator.kde.org/D21456
  14. 13 May, 2019 1 commit
  15. 09 May, 2019 1 commit
  16. 03 May, 2019 1 commit
  17. 28 Apr, 2019 1 commit
  18. 15 Apr, 2019 1 commit
  19. 07 Apr, 2019 1 commit
    • David Faure's avatar
      Akonadiserver: rework handling of database deadlocks. · 5b5b9fad
      David Faure authored
      We can't just replay the SQL commands, that's too low-level: if we do
      INSERT, then use the resulting ID into e.g. another INSERT command, at replay
      time we might get a different ID from the first command, and then insert
      the wrong ID in the second one...
      So instead we want to re-run the entire handler's parseStream(), which we
      do by throwing a DbDeadlockException (from QueryBuilder), and catching that
      in the caller (Connection) using a helper class (DbDeadlockCatcher, unittested)
      which retries up to 5 times.
      For this to work, it means:
      - we must also rollback any chances made to in-memory caches (done by
      clearing those caches, good enough since DB deadlocks are rare)
      - ItemModifyJob which sends parts on demand, shouldn't delete after
      sending (it might be asked again) -- this was hit by GidTest (fetchAndSetGid).
      Still TODO:
      - delaying the updating of intervalChecker and cacheCleaner by NotificationCollector
          until commit time;
      - checking other users of QueryBuilder (who now can get a DbDeadlockException...)
      Test Plan:
      all this was triggered by a unittest that creates 10 sessions
      and adds 10 different attributes to the same time, one in each session. This very
      often hits the DB deadlock scenario.
      Reviewers: dvratil, vkrause
      Reviewed By: dvratil
      Subscribers: kde-pim
      Tags: #kde_pim
      Differential Revision: https://phabricator.kde.org/D20326
  20. 26 Feb, 2019 1 commit
  21. 01 Dec, 2018 1 commit
  22. 27 Aug, 2018 2 commits
  23. 15 Jul, 2018 1 commit
  24. 14 Jul, 2018 3 commits
  25. 05 Jul, 2018 1 commit
    • Daniel Vrátil's avatar
      Server: handle race condition on connection shutdown · 154cfb8f
      Daniel Vrátil authored
      When client sends a command and disconnects immediatelly it is possible
      that the Connection gets mostly torn down from a nested event loop
      before we get back to the main loop in handleIncomingData(),
      leading to m_socket being null when we try to access it.
      BUG: 394071
      FIXED-IN: 5.8.3
  26. 21 Jun, 2018 1 commit
  27. 21 Apr, 2018 1 commit
  28. 19 Jan, 2018 1 commit
    • Daniel Vrátil's avatar
      Use QIODevice::readyRead() to wait for incoming data · 2058ae6c
      Daniel Vrátil authored
      Also avoid any reading code to be executed in a slot connected to
      readyRead() signal because Qt will not emit readyRead() signal
      recursively. This change is needed to make Akonadi work on Windows,
      because the blocking QLocalSocket::waitForReadyRead() does not work
      reliably there.
      On Linux QLocalSocket::waitForReadyRead() is used internally only
      in DataStream for performance reasons. On Windows DataStream will
      internally instantiate a QEventLoop and wait for the readyRead()
      signal, which is more expensive, especially since DataStream can
      get into the wait state multiple times while reading a single
  29. 23 Dec, 2017 1 commit
  30. 30 May, 2017 1 commit
  31. 20 May, 2017 1 commit
  32. 23 Apr, 2017 2 commits
    • Daniel Vrátil's avatar
      Generate Protocol from an XML specification (ABI break) · 5535d6e5
      Daniel Vrátil authored
      Instead of maintaining 12k lines of hand-written protocol code, we
      specify the protocol in an XML and use a custom-written generator
      that generates the code for us.
      It's not only much easier to modify the protocol - we only need to
      change a single thing in the XML instead of touching several places
      of the implementation - but it's also much safer, as there's less
      risk of accidentally introducing a bug in the code.
      The major difference between the original hand-written code and the
      generated code is that we no longer use QSharedDataPointer and virtual
      methods in the Private classes, but instead all members are directly
      in the command clas with most getters and setters inlined. This means
      that copying commands is quite costly, so we pass them around as
      QSharedPointers or const references. This should give us a tiny little
      bit more performance.
    • Daniel Vrátil's avatar
      Prevent sending multiple error messages from a single Handler · 47113076
      Daniel Vrátil authored
      Prevent single Handler from issuing multiple failureResponse()s, or
      the Handler emitting one and then Connection sending another. The
      client Jobs only expect a single error response, so when they get
      more than one, it messses up result handling especially with nested
       jobs (like Transactions or ItemSync)
  33. 01 Apr, 2017 1 commit
  34. 26 Mar, 2017 1 commit
    • Tobias C. Berner's avatar
      abi::__forced_unwind is only part of gnu's libstc++. · 9414ca9c
      Tobias C. Berner authored
      /wrkdirs/usr/ports/databases/akonadi/work/akonadi-17.03.80/src/server/connection.cpp:270:23: error: no type named '__forced_unwind' in namespace '__cxxabiv1'
              } catch (abi::__forced_unwind&) {
      1 error generated.
      NPTL is Linux's posix thread implementation, so that exception thrown by it, should only affect the Linux platforms.
      Subscribers: #kde_pim
      Tags: #kde_pim
      Differential Revision: https://phabricator.kde.org/D5168