[CalendarServer-users] Calendarserver not recognized by Apple Calendar

[Andre LaBranche]

Hi,

We’d need to see the server’s /var/log/caldavd/error.log to be sure, but I have a guess at what might be wrong. On the Pi, run the command:

netstat -na | egrep ‘8008|8443’

This will list all the network connections associated with the Calendar Server service ports. Calendar Server limits the amount of total request concurrency, and this limit is by default based on the server’s hw resources, so the setting might be fairly meager for a Pi. It should still be enough for such a simple test, however we’re tracking an issue right now (in trunk) that’s causing scalability problems that result in the behavior you’re seeing. You are probably affected by this bug if you see that all the connections slots are full when you really haven’t presented much load. Also, if there are a lot of network connections in FIN_WAIT2, that’s another sign.

If instead you see in the error.log that the server is actually processing the requests which eventually finish (they don’t get logged to access.log until they finish), then maybe the Pi is just really slow? I’d still expect some bug, because it doesn’t take a great amount of server CPU do a basic CalDAV login.

Cheers,
-dre

On Aug 11, 2013, at 7:43 AM, calendar at bastibe.de wrote:

> Hi,
> 
> I set up calendarserver on a Raspberry Pi. I can connect to it using an iPad and I can see the appropriate data in my web browser. Apple Calendar (OSX 10.8.4) however works for 30 seconds, then says "can not create a connection".
> 
> The Console is logging
> 
>> 11.08.13 16:16:42,633 CalendarAgent[14934]: [com.apple.calendar.store.log.caldav.queue] [Got error on refresh, but not rectifying principal because it was manually configured: Error Domain=NSURLErrorDomain Code=-1001 "Zeitüberschreitung bei der Anforderung." UserInfo=0x7fb2a3336580 {NSUnderlyingError=0x7fb2a1b2f640 "Zeitüberschreitung bei der Anforderung.", NSErrorFailingURLStringKey=https://bastibe@cloud.bastibe.de:8443/calendars/__uids__/3e5c3ade-c0ea-5560-8dfb-dce1e4be3c22/calendar/, NSErrorFailingURLKey=https://bastibe@cloud.bastibe.de:8443/calendars/__uids__/3e5c3ade-c0ea-5560-8dfb-dce1e4be3c22/calendar/, NSLocalizedDescription=Zeitüberschreitung bei der Anforderung.}]
> 
>> 11.08.13 16:16:42,633 CalendarAgent[14934]: [com.apple.calendar.store.log.caldav.queue] [Account bastibe at https://cloud.bastibe.de:8443/principals/users/bastibe/ timed out when executing operation: <CalDAVAccountRefreshQueueableOperation: 0x7fb2a4a13ce0; Sequence: 0>]
> 
>> 11.08.13 16:16:42,636 CalendarAgent[14934]: [com.apple.calendar.store.log.caldav.queue] [Account refresh failed with error: Error Domain=NSURLErrorDomain Code=-1001 "Zeitüberschreitung bei der Anforderung." UserInfo=0x7fb2a4a69460 {NSUnderlyingError=0x7fb2a1b2f640 "Zeitüberschreitung bei der Anforderung.", NSErrorFailingURLStringKey=https://bastibe@cloud.bastibe.de:8443/calendars/__uids__/3e5c3ade-c0ea-5560-8dfb-dce1e4be3c22/calendar/, NSErrorFailingURLKey=https://bastibe@cloud.bastibe.de:8443/calendars/__uids__/3e5c3ade-c0ea-5560-8dfb-dce1e4be3c22/calendar/, AccountName=cloud.bastibe.de, CalDAVErrFromRefresh=YES, NSLocalizedDescription=Zeitüberschreitung bei der Anforderung.}]
> 
> 
> where "Zeitüberschreitung bei der Anforderung" is German for "timeout for request".
> 
> During those 30 seconds, the Raspberry Pi is running a Python process for the caldavd user at full CPU utilization.
> 
> So I'm guessing that Apple Calendar has an internal timeout of 30 seconds and the Raspberry Pi is not fast enough to send the calendar data in that time frame.
> 
> Do you have any idea how I could fix that? Any help would be greatly appreciated!
> 
> Kind regards,
> Basti
> _______________________________________________
> calendarserver-users mailing list
> calendarserver-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/calendarserver-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20130811/f6da6d05/attachment.html>