[Cosmo] Exception When PUTting Event, Slowness when PUTing
cyrus+lists.cosmo at daboo.name
Wed Dec 21 15:44:45 PST 2005
--On December 21, 2005 1:02:20 PM -0500 Bobby Rullo <br at osafoundation.org>
>> How to resolve this: the key thing is to try to limit the maximum
>> number of cached instances to say 1000, and generate an error on
>> PUT if the recurrence set is larger than that. When I added
>> 'COUNT=1000' to the RRULE in Bobby's example, it did get properly
>> stored and indexed and it took about 5 seconds to get the response.
>> No out of memory errors etc. A time-range report did return the
>> component as expected. Same went for the src/test/resources/dav/
>> caldav/event3.ics example that Brian was using.
> Shouldn't Cosmo be able to handle unbounded recurrences (they are legal
> in icalendar and CalDAV rfc's right?), or do you intend this as a
> temporary fix?
Whilst iCalendar supports unbounded recurrences, actually using them in a
practical sense can be limited. In particular, iTIP defines a response code
so that attendees can indicate that they are only prepared to handle up to
a certain amount of recurrences in a recurrence set. So there is a
reasonable expectation that a consumer of iCal data will reject components
that generate too much.
What Cosmo should do is accept any valid recurrence set on PUT, but only
expand up to allowable server limits. The index for that component should
be marked with the applied limit if one was applied. Then, when the report
runs, if the time-range request is outside of the server limit, the proper
DAV:number-of-matches-within-limits code can be returned.
Doing something like that will require changes to ical4j to allow expansion
to be limited to a maximum count, a change in the indexer to include in the
time-range field an indicator that the limit was or was not reached, and a
change to the time-range term comparator to catch the limit being exceeded.
More information about the Cosmo