From kde-pim Thu Nov 06 11:17:45 2014 From: Daniel =?ISO-8859-1?Q?Vr=E1til?= Date: Thu, 06 Nov 2014 11:17:45 +0000 To: kde-pim Subject: Re: [Kde-pim] KMail seems to loose connection to Akonadi at times Message-Id: <3395786.aHItRFKj01 () thor> X-MARC-Message: https://marc.info/?l=kde-pim&m=141527269600898 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============4627998915483875260==" --===============4627998915483875260== Content-Type: multipart/signed; boundary="nextPart21445372.HDYWhjikcB"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart21445372.HDYWhjikcB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Wednesday 05 of November 2014 23:29:49 Ingo Kl=F6cker wrote: > On Monday 03 November 2014 11:26:24 Daniel Vratil wrote: > > From this description it sounds like the session is stuck (that's w= hy > > the window closes, but the event loop won't quit, as the Akonadi > > Session is still active. You can debug this bug trying to log > > communications between KMail and server: > >=20 > > export AKONADI_SESSION_LOGFILE=3D/tmp/akonadi.log > > kmail >=20 > I tried this, but /tmp/akonadi.log wasn't even created. Maybe my KMai= l > is too old? IIRC I added this to kdepmlibs in 4.13. > Anyway, before I looked up your message I ran akonadiconsole when KMa= il > was stuck. In one of the many tabs in the Debugger tab (in a tab call= ed > "kmail2- (some hex number)") I found the following comma= nd > (without reply): >=20 > 785 UID FETCH 441172 FULLPAYLOAD ALLATTR EXTERNALPAYLOAD (UID REMOTEI= D > REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME PLD:HEAD) >=20 >=20 > After shutting down and restarting KMail, I could reproduce the probl= em > by selecting the same message (resp. the same folder in the problemat= ic > account; the message is selected automatically by KMail) that caused = the > problem the first time. This time I found the following in > akonadiconsole >=20 > 15 UID FETCH 441172 FULLPAYLOAD ALLATTR ANCESTORS 1 EXTERNALPAYLOAD (= UID > REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME > ATR:ErrorAttribute) > 15 NO Unable to fetch item from backend (collection 0) : Unable to > retrieve item from resource: Did not receive a reply. Possible causes= > include: the remote application did not send a reply, the message bus= > security policy blocked the reply, the reply timeout expired, or the > network connection was broken. So this is most probably a problem with Resource task processing gettin= g stuck=20 (most probably on a change replay). > 16 UID FETCH 441172 FULLPAYLOAD ALLATTR EXTERNALPAYLOAD (UID REMOTEID= > REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME PLD:HEAD) >=20 >=20 > Once the account goes bad, I can reproduce the problem after each > restart of KMail simply by selecting the problematic folder. Yep, because the retrieval requests will just be piling up in the resou= rce=20 queue, but the resource is not processing new tasks. > I tried whether killing the problematic agent helps. If I do this the= n > KMail no longer gets stuck when I select the problematic folder. But > KMail cannot display the message either. In akonadiconsole I see >=20 > 15 UID FETCH 441172 FULLPAYLOAD ALLATTR ANCESTORS 1 EXTERNALPAYLOAD (= UID > REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME > ATR:ErrorAttribute) > 15 NO Unable to fetch item from backend (collection 0) : Unable to > contact resource > 16 UID FETCH 441172 FULLPAYLOAD ALLATTR EXTERNALPAYLOAD (UID REMOTEID= > REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME PLD:HEAD) > 16 NO Unable to fetch item from backend (collection 0) : Unable to > contact resource > 17 UID FETCH 441172 FULLPAYLOAD ALLATTR EXTERNALPAYLOAD (UID REMOTEID= > REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME PLD:HEAD) > 17 NO Unable to fetch item from backend (collection 0) : Unable to > contact resource >=20 > This makes sense because the agent has not been restarted. Yep. Restarting the broken agent should usually help, as it will restar= t=20 processing of the ChangeReplay queue. There is a probability, that the = queue=20 will get stuck again (if there's a change at the beginning of the queue= that=20 triggers some bug and breaks the tasks processing - the change won't ge= t=20 removed from the queue until it finishes, so if it never finishes, it w= ill=20 always be there -> then you need to remove the change replay log), but = it does=20 not happen often. I don't have any solution to this, other than completely changing the w= ay=20 tasks are processed in ResourceScheduler, and to stop using DBus for re= trieval=20 request. Dan >=20 >=20 > Regards, > Ingo =2D-=20 Daniel Vr=E1til | dvratil@redhat.com | dvratil on #kde-devel, #kontact,= #akonadi Software Engineer - KDE Desktop Team, Red Hat Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 --nextPart21445372.HDYWhjikcB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUW1jZAAoJEMWdYU9vSuNI1sIH/RZjAcribbeW3jcPuEDLIJ9s QxWWTkkeKx0Y9q4znHUCpenAF0DTIFjFirXW5+xI40z2Lu7evv3h40tXjMQw0dJM gq7M7xRe8wHS5e3/MNFG3mR30+0eM3Y40Ojy5hEfxw9Q1+TRPrADD0PxeVbVs39a lLf90Th4+wc5v+WYNwyMPSsqDJldze4ao+2GkdYVR/wKC/7OF4SRW4avcpUOXljG sZ2RaUC4FC3+YcYAbJ3FOn9onFANylhqFAl59br+m4Ub6BY4GD6dM5axgviVNnCd L5gUeNv3e5Xzz2a9Vc7/pWrGDT6d2cMWa6y4tiD8fcTQlzZh9IYzLeR7u8qcBEI= =yChO -----END PGP SIGNATURE----- --nextPart21445372.HDYWhjikcB-- --===============4627998915483875260== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KDE PIM mailing list kde-pim@kde.org https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/ --===============4627998915483875260==--