[Chandler-dev] Re: [chandler-users] osaf.us updated to Cosmo 0.6.0

Morgen Sagen morgen at osafoundation.org
Tue Feb 27 23:50:38 PST 2007


On Feb 27, 2007, at 9:24 PM, Andre Mueninghoff wrote:

> Hi Jared, (and Hi to other intrepid users),
>
> Here's what occurred for me for nine collections when restoring from
> osaf.us after the migration to Cosmo 0.6 and using my existing .ini  
> file
> with the test/restore settings menu option:
>
> No. of collections     Error msg in the restore dialogue boxes
>
> 1                          Global name 'M2Crypto' is not defined
> 1                          Can't parse webpage
> 1                          <class 'zanshin http HTTPError'> (500)>
> 1                          <class 'zanshin http HTTPError'> (501)>
> 1                          That collection was not found
> 4                          [no error msg...collection restored]
>

I tried restoring using Andre's .ini file.  4 collections worked.  I  
didn't get the m2crypto error, but Andi did point me to a source  
module that was missing an m2crypto import, so I just checked that  
into the Chandler trunk.


On one collection I got a "ConnectionDone" exception.  I'm not sure  
if that's really a timeout error in disguise, but when I looked at  
the traffic, I saw that Cosmo was taking an exceptionally long time  
to return this ics file:  Andre_Cal/19de35ff-929c-5b34-f3bd- 
e50599f93eb9.ics.  Sure enough, even using cadaver and curl, that  
particular ics file takes a couple minutes to GET a response.  Other  
ics files in that collection are returned quickly.  Seems like a  
Cosmo problem, so I am cc'ing cosmo-dev on this message.


Grant, here is the stack trace for the ConnectionDone exception:

Traceback (most recent call last):
   File "/Users/morgen/dev/trees/trunk/util/task.py", line 64, in  
__threadStart
     result = self.run()
   File "/Users/morgen/dev/trees/trunk/application/dialogs/ 
SubscribeCollection.py", line 255, in run
     forceFreeBusy=task.forceFreeBusy)
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
__init__.py", line 784, in subscribe
     username=username, password=password)
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
__init__.py", line 1274, in subscribe2
     username=username, password=password)
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
__init__.py", line 1451, in subscribeCalDAV
     share.sync(updateCallback=updateCallback, modeOverride='get')
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
shares.py", line 559, in sync
     forceUpdate=forceUpdate, debug=debug)
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
conduits.py", line 302, in sync
     updateCallback=updateCallback)
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
conduits.py", line 959, in _get
     updateCallback=updateCallback, stats=stats)
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
conduits.py", line 798, in _conditionalGetItem
     updateCallback=updateCallback, stats=stats)
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
webdav_conduit.py", line 404, in _getItem
     resp = self._getServerHandle().blockUntil(resource.get)
   File "/Users/morgen/dev/trees/trunk/parcels/osaf/sharing/ 
WebDAV.py", line 85, in blockUntil
     return zanshin.util.blockUntil(callable, *args, **keywds)
   File "/Users/morgen/dev/release/Library/Frameworks/ 
Python.framework/Versions/2.5/lib/python2.5/site-packages/zanshin/ 
util.py", line 208, in blockUntil
     res.raiseException()
   File "/Users/morgen/dev/release/Library/Frameworks/ 
Python.framework/Versions/2.5/lib/python2.5/site-packages/twisted/ 
python/failure.py", line 259, in raiseException
     raise self.type, self.value, self.tb

Is this a timeout, or something else?


Also, I tried subscribing to individual collections one by one, and  
that seems to work.  It's only when multiple subscribes are going on  
simultaneously (as happens when you do a .ini restore) that I see all  
sorts of parsing errors, as if the content from the multiple requests  
is getting co-mingled or something.  In fact, I put some  
instrumentation into zanshin to dump whenever it gets a PROPFIND  
response it can't parse, and sure enough, the following is a response  
that zanshin gets tripped up on (sensitive data edited out):

<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
     <D:response>
         <D:href>https://osaf.us:443/cosmo/home/[EDITED OUT]/ 
Aaron_Cal/</D:href>
         <D:propstat>
             <D:prop>
                 <ticket:ticketdiscovery xmlns:ticket="http:// 
www.xythos.com/namespaces/StorageServer">
                     <ticket:ticketinfo>
                         <ticket:id>[EDITED OUT]</ticket:id>
                         <D:owner>
                             <D:href>https://osaf.us:443/cosmo/home/ 
[EDITED OUT]/</D:href>
                         </D:owner>
                         <ticket:timeout>Infinite</ticket:timeout>
                         <ticket:visits>infinity</ticket:visits>
                         <D:privilege>
       HTTP/1.1 207 Multi-Status
Server: Apache-Coyote/1.1
X-Cosmo-Version: 0.6.0
Set-Cookie: JSESSIONID=[EDITED OUT]; Path=/cosmo
Content-Type: text/xml;charset=UTF-8
Content-Length: 9305
Date: Wed, 28 Feb 2007 07:33:30 GMT

<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
     <D:response>
         <D:href>https://osaf.us:443/cosmo/home/[EDITED OUT]/Alex_Cal/ 
884dc0f6-7f16-11db-9cfc-0014a51af847.ics</D:href>
         <D:propstat>
             <D:prop>
                 <D:getetag>"1020-1172517185000"</D:getetag>
                 <D:displayname>[EDITED OUT]</D:displayname>
                 <D:resourcetype/>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
         </D:propstat>
     </D:response>
     <D:response>
         <D:href>https://osaf.us:443/cosmo/home/[EDITED OUT]/ 
Alex_Cal/.chandler/d5f472b8-a1e0-11db-ac61-f75221bfdbaa.xml</D:href>
         <D:propstat>
             <D:prop>
                 <D:getetag>"378-1171492609000"</D:getetag>
                 <D:displayname>d5f472b8-a1e0-11db-ac61- 
f75221bfdbaa.xml</D:displayname>
                 <D:resourcetype/>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
         </D:propstat>
     </D:response>
     <D:response>
         <D:href>https://osaf.us:443/cosmo/home/[EDITED OUT]/ 
Alex_Cal/.chandler/884dc0f6-7f16-11

This sure looks like two different PROPFIND responses stepping on  
each others' toes.  I'll need to work with Grant on this tomorrow to  
see if this is on Chandler/Zanshin's end or on Cosmo's.  I suppose  
this could also be a side-effect of the server-side URL rewriting I  
read something about.

~morgen



More information about the chandler-dev mailing list