Thunderbird CalDAV: invite attendee causes high load

[Nachtlichtermeer]

Ubuntu 18.04.5 LTS PHP7.2 Tine-Version: 2020.08.1

The button for invite attendee in thunderbirg causes high load and triggers 97564 database queries.

Tine-Log shows only entries like:

515524 - FOO - 2020-09-09T11:27:29+00:00 WARN (4): Calendar_Convert_Event_VCalendar_Abstract::_convertCalendarModelEvent::388 failed adding events imip x-property: X-MICROSOFT-LOCATIONS:[{"DisplayName":"Mobile +49697912290\,\,1374174848# D
 ial-in +49697912290 Meeting-ID 1374174848# "\,"LocationAnnotation":""\,"Lo
 cationUri":""\,"LocationStreet":""\,"LocationCity":""\,"LocationState":""\
 ,"LocationCountry":""\,"LocationPostalCode":""\,"LocationFullAddress":""}] -> Invalid Mimedir file. Line starting at 0 did not follow iCalendar/vCard conventions

In the database there are about 35.000 events. If i delete them all on a copied machine the load is normal (1-2 seconds higher cpu usage).

[lab-at-nohl]

Can you provide a log file, level DEBUG? Please include the beginning of the call, too.

[Nachtlichtermeer]

tine20.log

This is a full debuglog starting before click 'invite attendee' and stopps after load is normal and nothing is logged anymore. Username, name und some phonenumbers are replaced by FOO

[pschuele]

thanks for the input - this looks like a bug to me. we'll look into it.

[paulmhh]

the problem is the sabre.io CalDAV plugin implementation of outbox requests / freebusy calculation. This needs to be replaced with a tine20 specific implementation. It's on the todo list now, thanks for reporting this.

[mokraemer]

In general: The same holds for Outlook. If anything went wrong during adding an event (e.g. php error), Outlook retriggers this event as soon as the sync event returns. In case of errors the return value should be checked to signal outlook an error and not to try forever.

[Nachtlichtermeer]

After some months i've tested this again and the problem is gone away

Thunderbird 91.9, Tine 2021.12 unter PHP7.4

[pschuele]

thanks for testing @Nachtlichtermeer - closing this issue