On Thu, Apr 26, 2012 at 6:07 AM, Rasmus Borup Hansen <r...@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/001949.html 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
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
