[CalendarServer-dev] Error running calendarserver after upgrading db from 5.x to 7.x

[Rahul Amaram]

On Sunday 31 January 2016 07:27 AM, Andre LaBranche wrote:
>
>> On Jan 30, 2016, at 1:18 PM, Andre LaBranche <dre at apple.com 
>> <mailto:dre at apple.com>> wrote:
>>
>> This is not expected. Does memcached need to be configured for 
>> Unicode, maybe?
>
> It looks like we expect to be in ascii mode, as far as memcached is 
> concerned:
>
> You can debug the memcache side of this by configuring calendarserver 
> to not launch memcached; instead you'll do so manually, in the foreground.
>
> Edit caldavd.plist, and insert the following Pools configuration under 
> the Memcached dict:
>
>       <key>Pools</key>
>       <dict>
>           <key>Default</key>
>           <dict>
>               <key>MemcacheSocket</key>
>               <string></string>
>               <key>ServerEnabled</key>
>               <false/>
>               <key>BindAddress</key>
>               <string>127.0.0.1</string>
>               <key>Port</key>
>               <integer>11211</integer>
>           </dict>
>       </dict>
>
> Manually start memcached in verbose mode on 127.0.0.1:
> memcached -l 127.0.0.1 -vv
>
> Start calendar server, load a principal page: 
> https://whatever:8443/principals/users/you
>
> As you log in, you should see stuff in the memcached window:
>
> <22 new auto-negotiating client connection
> 22: Client using the *ascii protocol*
> <22 get DIGESTCREDENTIALS:...
> >22 END
>
>
> Also try the following test script which sets and gets unicode 
> strings. bytes. whatever they are :) In SVN mode, I run ./bin/python 
> mctest.py from the SVN dir to make sure the interpreter has access to 
> six and memcache. If you don't use SVN mode, and don't have these 
> modules installed system-wide, edit PYTHONPATH to help your 
> interpreter find these modules.
>
> #!/usr/bin/python
> # -*- coding: latin-1 -*-
> from __future__ import print_function
>
> import six
> from memcache import Client, SERVER_MAX_KEY_LENGTH, 
> SERVER_MAX_VALUE_LENGTH
>
> servers = ["127.0.0.1:11211"]
> mc = Client(servers, debug=1)
>
> def setget(key, val):
>     mc.set(key, val)
>     newval = mc.get(key)
>     print("key:", key)
>     print("set:".rjust(8), val)
>     print ("got:".rjust(8), newval, "\n")
>
> setget("ascii", "xyzzy")
>
> setget("unicode_1", six.u('\U0001f648'))
> setget("unicode_2", six.u('\u25c9'))
> setget("unicode_3", six.u('\u4f1a'))
> setget("unicode_4", six.u('dr\\xe9'))
>
> mc.disconnect_all()
>
>
>
> Output looks like:
>
> key: ascii
>     set: xyzzy
>     got: xyzzy
>
> key: unicode_1
>     set: 🙈
>     got: 🙈
>
> key: unicode_2
>     set: ◉
>     got: ◉
>
> key: unicode_3
>     set: 会
>     got: 会
>
> key: unicode_4
>     set: dré
>     got: dré
>
>
> ... and the memcached log confirms we're still in ascii mode:
>
> <25 new auto-negotiating client connection
> 25: Client using the ascii protocol
> <25 set ascii 0 0 5
> >25 STORED
> <25 get ascii
> >25 sending key ascii
> >25 END
> <25 set unicode_1 0 0 4
> >25 STORED
> <25 get unicode_1
> >25 sending key unicode_1
> >25 END
>
>
> -dre

Tried the experiment. Here is the output:

root at wheezy:/tmp# python test.py
key: ascii
     set: xyzzy
     got: xyzzy

key: unicode_1
     set: 🙈
     got: 🙈

key: unicode_2
     set: ◉
     got: ◉

key: unicode_3
     set: 会
     got: 会

key: unicode_4
     set: dré
     got: dré

and here is the memcached log:

<37 new auto-negotiating client connection
37: Client using the ascii protocol
<37 set ascii 0 0 5
 >37 STORED
<37 get ascii
 >37 sending key ascii
 >37 END
<37 set unicode_1 0 0 4
 >37 STORED
<37 get unicode_1
 >37 sending key unicode_1
 >37 END
<37 set unicode_2 0 0 3
 >37 STORED
<37 get unicode_2
 >37 sending key unicode_2
 >37 END
<37 set unicode_3 0 0 3
 >37 STORED
<37 get unicode_3
 >37 sending key unicode_3
 >37 END
<37 set unicode_4 0 0 4
 >37 STORED
<37 get unicode_4
 >37 sending key unicode_4
 >37 END
<37 connection closed.


What next :)? I believe I could however safely go ahead and upload the 
new calendarserver version as this bug does not seem to breaking any 
functionality.

Thanks,
Rahul.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/calendarserver-dev/attachments/20160209/dd0a0c03/attachment.html>