On Fri, Jul 22, 2011 at 7:15 PM, Lin, Mike M <mmlin(a)directv.com> wrote:
Hi Michael,
That does help FileCache.validate() recognize that the cache is not expired yet.
However, it did not improve the times. It takes 16 seconds to create a client either
way.
After that change, the problem is that although ObjectCache.get is always getting a valid
file pointer, it's hitting an exception (EOFError) doing pickle.load(fp). When that
happens, the file is just downloaded again.
Here's the sequence of events:
DocumentReader.open:
Trying
http://172.28.50.249/wsdl/billingServices/v3.0/RequestScrubAddress.wsdl
Loading ObjectCache 51012453-document
Loading pickled object...
Exception raised: <type 'exceptions.EOFError'>
Got None from cache
Downloading... Done
Saving FileCache 51012453-document... Done
So it doesn't really matter that the new cache file was saved, because the same thing
happens the next time I run. This happens for ALL of WSDL and XSD files.
I fixed that problem by opening the file in binary mode when reading and writing.
Specifically, the changes I made were in cache.py:
1. In FileCache.put(), change this line:
f = self.open(fn, 'w')
to
f = self.open(fn, 'wb')
2. In FileCache.getf(), change this line:
return self.open(fn)
to
return self.open(fn, 'rb')
I don't know the codebase well enough to know if these changes are safe, but it is
pulling the objects from the file cache, the service is still running successfully, and
loading the client went from 16 seconds down to 2.5 seconds.
Hopefully this fix, or something similar can be introduced back into the suds main line.
Nice spot! I guess you are running this on Windows? That change makes
sense and should to be safe enough. Jeff I think is primarily a Linux
guy, so probably didn't hit this issue.
I'm not sure what is going to happen to suds in the longer term.
Perhaps it is time to create a public fork?