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:
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.