[Kde-pim] Akonadi ChangeReplay never completes

[David Jarvie]

Having had no response previously, I hope somebody (Volker / Kevin / other
?) can take a look at this. There seems to be a bug in the Akonadi code -
I don't think that KAlarm or the KAlarmResource is at fault.

On Mon, November 21, 2011 9:19 pm, David Jarvie wrote:
> On Wednesday 16 November 2011 23:30:06 David Jarvie wrote:
>> A ChangeReplay job seems to be getting stuck when the KAlarmResource
>> starts up. Looking at the code in ChangeRecorder::replayNext(), it
>> doesn't seem to handle the case highlighted below:
>>
>> if ( !d->pendingNotifications.isEmpty() ) {
>>   ...
>>   if ( d->ensureDataAvailable( msg ) )
>>     ...
>>   else if ( !d->translateAndCompress( d->pipeline, msg ) ) {
>>     ...
>>   }
>>   ///// *THIS CASE ISN'T HANDLED*
>> } else {
>>   // This is necessary when none of the notifications were accepted /
>> processed above ...
>> }
>>
>> Shouldn't something happen in the unhandled case as well? KAlarmResource
>> reaches that point and then seems to get stuck.
>
> I've looked at this more, and there definitely seems to be something wrong
> with ChangeRecorder. Once the ChangeReplay job has been scheduled, the
> ResourceScheduler doesn't execute any more jobs for that resource. That
> is, it calls scheduleNext() for further jobs, but never calls
> executeNext() from then on. The last call to ChangeRecorder::replayNext()
> goes to the unhandled case (see above), and it never gets called again.
>
> This can easily be reproduced, as follows:
>
> 1. Create a new KAlarm Calendar File resource in akonadiconsole, file
> /tmp/x.ics. Do not select read-only. Select Active Alarms.
>
> 2. Demonstrate configuration working correctly: Go to Configure Natively,
> and set the resource read-only. The resource's Collection -> Folder
> Properties -> Access Rights attribute changes, and its settings file
> (~/.kde/share/config/akonadi_kalarm_resourcexxrc) is updated to
> ReadOnly=true.
>
> 3. Run KAlarm, show the calendar list (View -> Show Calendars) and enable
> the resource by checking it in the list. This adds a KAlarmCollection
> attribute, value "1 0 0 0". This triggers the ChangeReplay job to be
> scheduled, but it doesn't complete.
>
> 4. Demonstrate configuration not working: Go to Configure Natively, and
> clear the read-only setting. The Access Rights attribute does not update,
> but the settings file does. This is because although
> ResourceScheduler::scheduleCollectionTreeSync() is called, the
> CollectionTreeSync (which is responsible for updating the Access Rights
> attribute for SingleFileResource derived resources) never executes,
> because ChangeRecorder::replayNext() never does anything.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm

_______________________________________________
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/