It is implemented also in KE14 for a long time. I didn't close this task, because converting to plain text is not the same as supporting HTML.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 26 2016
@machniak - Can this me backported to KE14 - please.
Sep 19 2016
This has been implemented.
Sep 12 2016
Sep 5 2016
Aug 29 2016
- The RID is null until the item has been first written to the server (but the resource will always first upload pending items before triggering a sync).
- There is no flag to indicate that an item has not been uploaded and I don't think there is a way to search for items that haven't been uploaded.
Aug 16 2016
Aug 11 2016
My thought is to fix this:
get the count of messages without an remoteId ( these are not uploaded)
and exclude this count from identify the missing mails on the server aka:
the performance is mentionable slower than without the patch.
Aug 10 2016
waiting for input from genua side
Aug 8 2016
Aug 1 2016
Add a method to trigger the notifications by hand, it first displays the current status of the timer:
qdbus org.freedesktop.Akonadi /notifications org.freedesktop.Akonadi.NotificationManager.triggerTimer The timer is currently inactive The intervall is currently 50
fixed with rKP9c14a56
can reproduce.
How you think we should test if it performs adequately?
We have not UNSUBSCRIBE messages, because kdepimlibs never triggers them. I added now a patch to fix this. See Differntial
The above output only shows 3 SUBSCRIBE commands instead of the usual 4 in previous instances....,
and it never shows an UNSUBSCRIBE command. Needs to be investigated.
From the following debug output that was captured after the problem appeared, we can see that the notifications indeed seem to pile up in the NotificationManager for some reason.
Jul 28 2016
dev/noRealMessageCount disables all codepaths that rely on the message count. If that performs adequately, then we could just be using that.
This is apparently a synchronization issue.
We're currently waiting for more information (see otrs).
In imap/retrieveitemstask.cpp:
With the latest version it is now possible to introspect the notificationManager with:
appendAndCompress only optimizes collection modifications, so that's not it.
Akonadiconsole subscribes in notificationmodel.cpp directly to dbus, so it's unlikely that this is the reason.
Some additional checks that could be done:
Given that we do see some unrelated sync operations including non-SILENT modifications in the log, but still no notifications in akonadiconsole we can conclude that this is a problem where the akonadiserver fails to send any notifications to any process.
In T1321#22196, @mollekopf wrote:The current hypothesis is:
- The DataStore does a reestablishConnectionIfLost because we lost the connection to the mysql server while a transaction was ongoing.
- m_transactionLevel is never reset to 0 so remains > 0
- commitTransaction get's m_transactionLevel > 1 and thus never emits transactionComitted
- NotificationCollector::dispatchNotification is always in transaction and thus always enqueues new notifications, and never emits them since it's waiting on transactionCommitted.
DataStore is a thread-local singleton that also instantiates NotificationCollector which would explain why this behavior is observed only for the session of kontact.
It doesn't explain why a restart of kontact isn't enough to fix the situation though it seems?
Jul 27 2016
The current hypothesis is:
- The DataStore does a reestablishConnectionIfLost because we lost the connection to the mysql server while a transaction was ongoing.
- m_transactionLevel is never reset to 0 so remains > 0
- commitTransaction get's m_transactionLevel > 1 and thus never emits transactionComitted
- NotificationCollector::dispatchNotification is always in transaction and thus always enqueues new notifications, and never emits them since it's waiting on transactionCommitted.
From the latest information provided (otrs 07/20/2016 13:03:24):
- The UID STORE +FLAGS command is successfully executed and we can see the FETCH (REV 2) response)
- The Job Tracker also reports the ItemModifyJob as successful
- No notifications at all are visible in the notification monitor
- The "INSERT INTO PimItemFlagRelation ..." command is successfully executed as recorded by the querydebugger.
Jul 25 2016
Jul 18 2016
Jul 14 2016
Jul 13 2016
Jul 11 2016
Jul 7 2016
Can they please add the message that they try to look at - the stacetrace also has problems with the viewing part. So it looks like the message has an attached vCard:
Judging from the backtrace it could be that we have calls to exec that execute the eventloop:
Another potentially related crash:
https://support.kolabsys.com/provider?Action=AgentTicketZoom&TicketID=22211