Hi, If helpful, I give OSAF in general permission to experiment with the .ini file referenced by Morgen and the associated Cosmo account. I have published the same collections to a different Cosmo account on osaf.us so as to avoid collisions. Please let me know if you have any questions. Thanks, Andre
On Tue, 27 Feb 2007 23:50:38 -0800, "Morgen Sagen" <[EMAIL PROTECTED]> said: > > 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 > -- Andre Mueninghoff [EMAIL PROTECTED] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
