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

Andre Mueninghoff andre_mueninghoff at fastmail.fm
Wed Feb 28 04:18:39 PST 2007


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"
<morgen at osafoundation.org> 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
  andre_mueninghoff at fastmail.fm



More information about the chandler-dev mailing list