[Akonadi] [Bug 472282] Kolab Now reports too many open connections
https://bugs.kde.org/show_bug.cgi?id=472282 Heinz Wiesinger changed: What|Removed |Added Resolution|FIXED |UPSTREAM --- Comment #5 from Heinz Wiesinger --- I can confirm. Started working a couple weeks ago, just didn't come around to updating the relevant bug reports yet. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 472282] Kolab Now reports too many open connections
https://bugs.kde.org/show_bug.cgi?id=472282 Andreas Cord-Landwehr changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Andreas Cord-Landwehr --- @heinz, yesterday at FOSDEM I ran into Christoph Molenkopf. On Kolab side they were able to reproduce a crash in their IMAP servers coming from the specific sequence sent by Kontact/Akonadi and apparently could fix it. On my side I do not see this issue anymore and thus would close the defect. Please reopen, if you see it different. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 472282] Kolab Now reports too many open connections
https://bugs.kde.org/show_bug.cgi?id=472282 --- Comment #3 from Andreas Cord-Landwehr --- OK, I found a horrible workaround to not trigger this error: I did a local patch that filters the "METADATA" capability out of the announced IMAP server capabilities (before handing them over to KMail) and it seems to work well in terms of not leading to infinite server answers. At the downside, obviously this IMAP feature is not functional anymore. The important insight though is that it further pins the problem to the sever side handling it GETMEATADATA requests. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 472282] Kolab Now reports too many open connections
https://bugs.kde.org/show_bug.cgi?id=472282 --- Comment #2 from Andreas Cord-Landwehr --- After some more debug outputs, essentially uncommenting the GOT/SENT debug lines in getmetadatajob.cpp and increasing the debug level to debug for kimap, I am very sure that the Kolab server behaves in a way that some calls to "GETMETADATA (DEPTH infinity)" never are answered and thus the socket timeout is hit. What is quite interesting, in the same IMAP session the exact same call, eg C: A08 GETMETADATA (DEPTH infinity) "KDE/Community" (/shared) S: * METADATA KDE/Community ( /shared/vendor/cmu/cyrus-imapd/server imapb036.mykolab.com ) S: A08 OK Completed at one point succeeds and a few seconds later C: A15 GETMETADATA (DEPTH infinity) "KDE/Community" (/shared) never is answered (I modified getmetadatajob such that timeout is set to infinity and now after waiting 15 minutes, I am very sure that the sever never will answer). @heinz, do you see the same behavior? With my limited IMAP knowledge, as far as I can see, here is not much that can be done on the client Akonadi side other than some crude hacks that retry the getmetadatajob once a socket timeout is reached instead of tearing down the full connection. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 472282] Kolab Now reports too many open connections
https://bugs.kde.org/show_bug.cgi?id=472282 --- Comment #1 from Andreas Cord-Landwehr --- I had a slightly deeper look into this issue because I can also reproduce this behavior with the Kolabnow.com server: Using the KIMAP_LOGFILE logging option when restarting Akonadi I monitored the socket disconnects and in every single connection loss I see a "GETMETADATA (DEPTH infinity) operation as last operation before losing connection, here one example log tail: [...] S: * OK Ok [ ANNOTATIONS 65536 ] S: A10 OK Completed [ READ-WRITE ] C: A11 UID FETCH 1:26193 (FLAGS UID) (CHANGEDSINCE 39247) S: * 24503 FETCH ( FLAGS (\Seen) UID 26164 MODSEQ (39273) ) S: * 24504 FETCH ( FLAGS (\Seen) UID 26165 MODSEQ (39271) ) S: * 24505 FETCH ( FLAGS (\Seen) UID 26166 MODSEQ (39272) ) S: * 24506 FETCH ( FLAGS (\Seen) UID 26167 MODSEQ (39274) ) S: * 24507 FETCH ( FLAGS (\Seen) UID 26168 MODSEQ (39270) ) S: * 24508 FETCH ( FLAGS (\Seen) UID 26169 MODSEQ (39269) ) S: * 24509 FETCH ( FLAGS (\Seen) UID 26170 MODSEQ (39267) ) S: * 24510 FETCH ( FLAGS (\Seen) UID 26171 MODSEQ (39268) ) S: * 24511 FETCH ( FLAGS (\Seen) UID 26172 MODSEQ (39266) ) S: * 24512 FETCH ( FLAGS (\Seen) UID 26173 MODSEQ (39276) ) S: * 24513 FETCH ( FLAGS (\Seen) UID 26174 MODSEQ (39260) ) S: * 24514 FETCH ( FLAGS (\Seen) UID 26175 MODSEQ (39264) ) S: * 24515 FETCH ( FLAGS (\Seen) UID 26176 MODSEQ (39275) ) S: * 24516 FETCH ( FLAGS (\Seen) UID 26177 MODSEQ (39265) ) S: * 24517 FETCH ( FLAGS (\Seen) UID 26178 MODSEQ (39257) ) S: * 24518 FETCH ( FLAGS (\Seen) UID 26179 MODSEQ (39263) ) S: * 24519 FETCH ( FLAGS (\Seen) UID 26180 MODSEQ (39261) ) S: * 24520 FETCH ( FLAGS (\Seen) UID 26181 MODSEQ (39258) ) S: * 24521 FETCH ( FLAGS (\Seen) UID 26182 MODSEQ (39259) ) S: * 24522 FETCH ( FLAGS (\Seen) UID 26183 MODSEQ (39256) ) S: * 24523 FETCH ( FLAGS (\Seen) UID 26184 MODSEQ (39262) ) S: * 24524 FETCH ( FLAGS (\Seen) UID 26185 MODSEQ (39255) ) S: * 24525 FETCH ( FLAGS (\Seen) UID 26186 MODSEQ (39250) ) S: * 24526 FETCH ( FLAGS (\Seen) UID 26187 MODSEQ (39251) ) S: * 24527 FETCH ( FLAGS (\Seen) UID 26188 MODSEQ (39252) ) S: * 24528 FETCH ( FLAGS (\Seen) UID 26189 MODSEQ (39253) ) S: * 24529 FETCH ( FLAGS (\Seen) UID 26190 MODSEQ (39248) ) S: * 24530 FETCH ( FLAGS (\Seen) UID 26191 MODSEQ (39254) ) S: * 24531 FETCH ( FLAGS (\Seen) UID 26192 MODSEQ (39249) ) S: A11 OK Completed ( 0.001 sec ) C: A12 GETMETADATA (DEPTH infinity) "KDE/Devel" (/shared) X -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 472282] Kolab Now reports too many open connections
https://bugs.kde.org/show_bug.cgi?id=472282 Andreas Cord-Landwehr changed: What|Removed |Added CC||cordlandw...@kde.org -- You are receiving this mail because: You are the assignee for the bug.
