I've been observing wallace allocating 100% of CPU. After doing some debuging it looks like the problem occurs when wallace tries to determine if there is any conflicts between resource events and reservation conflict.
2016-11-22 14:37:42,102 pykolab.wallace DEBUG [20846]: iTip event conflict checked for 145 on shared/Resources/Besprechungsraum 2-42-F1@domain 2016-11-22 14:37:42,102 pykolab.wallace DEBUG [20846]: Fetching message UID '146' from folder 'shared/Resources/Besprechungsraum 2-42-F1@domain' 2016-11-22 14:37:42,150 pykolab.wallace DEBUG [20846]: * Comparing events 2016-11-24 13:30:00+01:00/2016-11-24 14:30:00+01:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,151 pykolab.wallace DEBUG [20846]: iTip event conflict checked for 146 on shared/Resources/Besprechungsraum 2-42-F1@domain 2016-11-22 14:37:42,151 pykolab.wallace DEBUG [20846]: Fetching message UID '147' from folder 'shared/Resources/Besprechungsraum 2-42-F1@domain' 2016-11-22 14:37:42,196 pykolab.wallace DEBUG [20846]: * Comparing events 2016-11-10 14:30:00+01:00/2016-11-10 15:30:00+01:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,196 pykolab.wallace DEBUG [20846]: iTip event conflict checked for 147 on shared/Resources/Besprechungsraum 2-42-F1@domain 2016-11-22 14:37:42,197 pykolab.wallace DEBUG [20846]: Fetching message UID '148' from folder 'shared/Resources/Besprechungsraum 2-42-F1@domain' 2016-11-22 14:37:42,220 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-12 10:00:00+02:00/2016-09-12 11:00:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,240 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-19 10:00:00+02:00/2016-09-19 11:00:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,259 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,276 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,291 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,306 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,320 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,334 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,347 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,360 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,372 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,385 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,398 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00 2016-11-22 14:37:42,410 pykolab.wallace DEBUG [20846]: * Comparing events 2016-09-26 09:00:00+02:00/2016-09-26 09:30:00+02:00 with 2016-11-29 11:00:00+01:00/2016-11-29 12:00:00+01:00
and the last line goes forever. It looks like event conflict checking gets into endless loop. The logs I pasted here I got by uncommenting line ~176, in pykolab/itip/__init__.py, def check_event_conflict(kolab_event, itip_event): method.
The most relevant part of the offending message (148 (or 2564)) has this content (most relevant).
<components> <vevent> <properties> <uid> <text>3C93514BA89A1BCC38DA740341DF8D74-EBE2BB8E57A31106</text> </uid> <created> <date-time>2016-09-05T14:33:12Z</date-time> </created> <dtstamp> <date-time>2016-09-05T14:33:11Z</date-time> </dtstamp> <sequence> <integer>0</integer> </sequence> <class> <text>PUBLIC</text> </class> <dtstart> <parameters> <tzid> <text>/kolab.org/Europe/Berlin</text> </tzid> </parameters> <date-time>2016-09-12T10:00:00</date-time> </dtstart> <dtend> <parameters> <tzid> <text>/kolab.org/Europe/Berlin</text> </tzid> </parameters> <date-time>2016-09-12T11:00:00</date-time> </dtend> <rrule> <recur> <freq>WEEKLY</freq> <byday>MO</byday> </recur> </rrule> <summary> <text>Enterprise Meeting</text> </summary>
can present full payload of the event upon request.
Removing the message from resource makes wallace work again (after restart it doesn't take 100% of CPU anymore).
pykolab 0.7.30-0~kolab1
wallace 0.7.30-0~kolab1