[Kde-pim] Reproduceable error on imap_resource startup

Daniel Vratil dvratil at redhat.com
Tue Sep 30 16:27:20 BST 2014


On Monday 29 of September 2014 15:27:19 David Faure wrote:
> On Sunday 28 September 2014 19:52:48 David Faure wrote:
> > Today, whenever I start the imap resource and press F5 in a folder, it
> > errors out with ResourceTask::onSessionRequested: Cancelling this request.
> > Probably there is no more session available
> > 
> > I debugged it by adding debug output in the imap resource, see diff and
> > log
> > attached.
> > 
> > I think the problem is that it's starting a RetrieveCollectionMetadataTask
> > before the RetrieveItemsTask is done.
> > 
> > I believe this comes from commit c15f671e81b7d6cea9ce668660231dea5120077b
> > Author: Christian Mollekopf <chrigi_1 at fastmail.fm>
> > Date:   Fri May 2 15:04:12 2014 +0200
> > 
> >     IMAP-Resource: Always fetch the collection before doing a
> > 
> > RetrieveCollectionMetadataTask
> 
> The relevant diff from that commit is:
> 
> --- a/resources/imap/imapresource.cpp
> +++ b/resources/imap/imapresource.cpp
> @@ -431,7 +431,27 @@ void ImapResource::triggerCollectionExtraInfoJobs(
> const QVariant &collectionVar const Collection collection(
> collectionVariant.value<Collection>() ); emit status( AgentBase::Running,
> i18nc( "@info:status", "Retrieving extra folder information for '%1'",
> collection.name() ) );
> 
> -  startTask(new RetrieveCollectionMetadataTask(
> createResourceState(TaskArguments(collection)), this )); +  //The
> collection that we received is potentially outdated.
> +  //Using it would overwrite attributes with old values.
> +  //FIXME: because this is async and not part of the resourcetask, it can't
> be killed. ResourceBase should just provide an up-to date copy of the
> collection. +  Akonadi::CollectionFetchJob *fetchJob = new
> Akonadi::CollectionFetchJob(collection, CollectionFetchJob::Base, this); + 
> fetchJob->fetchScope().setAncestorRetrieval( CollectionFetchScope::All ); +
>  fetchJob->fetchScope().setIncludeStatistics( true );
> +  connect(fetchJob, SIGNAL(result(KJob*)), this,
> SLOT(onMetadataCollectionFetchDone(KJob*))); +}
> [...]
> 
> Shouldn't that Akonadi::CollectionFetchJob be moved to inside the
> RetrieveCollectionMetadataTask class? Then it would use the imap session
> for that task, rather than a separate one.

But Akonadi::CollectionFetchJob does not use KIMAP session, so this would make 
no difference I think. 

However you are right that it seems like if the RetrieveCollectionMetadataTask 
was executed before the ItemsRetrieveTask finished properly, i.e. before it 
releases it's IMAP session back to SessionPool::m_unusedPool, here's probably 
why: judging from the 
"Akonadi::ResourceBasePrivate::createItemSyncInstanceIfMissing: Calling items 
retrieval methods although no item retrieval is in progress" warnings it's 
possible that ItemSync has failed (i.e. you hit the problem we discussed on 
Akademy), which caused ResourceScheduler to move on to next task 
(RetrieveCollectionMetadataTask), while the RetrieveItemsTask was still 
running and trying to feed more items into the - now finished - ItemSync (see 
my reply in the "Detected inconsistency in local cache" thread.

Dan

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140930/1cf08077/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list