On Thu, Apr 26, 2012 at 6:07 AM, Rasmus Borup Hansen <rbh@intomics.com>wrote:
It looks like I've solved the problem. Apparently, you cannot rely on CalendarServer generating the GUIDs. I added the following configuration and haven't had problems yet:
… <key>DirectoryService</key> <dict> <key>type</key>
<string>twistedcaldav.directory.ldapdirectory.LdapDirectoryService</string>
<key>params</key> <dict> … <key>rdnSchema</key> <dict> <key>guidAttr</key> <string>entryUUID</string> …
This reuses OpenLDAP's Universally Unique IDentifiers as Globally Unique IDentifiers in CalendarServer which is probably a nice thing in itself.
Interesting. I'll have to think about how I could do something similar, since I'm not using LDAP as a directory service. With regard to disabling memcached, one of the few responses I got back to my queries regarding memcached is that it's not possible to disable: http://lists.macosforge.org/pipermail/calendarserver-users/2012-February/001... In my case, I'm not sure the GUID generation would change the situation substantially because I already have calendars with GUIDs assigned. What will happen in my case is that sometimes a request will come in and will be "found", while 5 minutes later a request for the same item will come in and not be found. With my weak python debugging skills I traced it down to trying find that something in cache and it not being there. I would think that when it's not in cache it would get loaded, but it's almost as if memcached thinks it has the item but doesn't return it. -- Chris Cleeland