Hash stability
Peter Otten
__peter__ at web.de
Mon Jan 16 03:18:48 EST 2012
Heiko Wundram wrote:
> Am 15.01.2012 13:22, schrieb Peter Otten:
>> I'm curious: did you actually get false cache hits
in a suds cache
>> or just slower responses?
> It broke the application using suds, not due to false cache hits, but
> due to not getting a cache hit anymore at all.
> so basically I worked around
> the problem by creating an appropriate cache entry with the appropriate
> name based on hash() using a local copy of xml.dtd I had around. This
> took place on a development machine (32-bit), and when migrating the
> application to a production machine (64-bit), the cache file wasn't used
> anymore (due to the hash not being stable).
Thanks for the explanation.
> if the hash() output is changed. Additionally, if hash() isn't stable
> between runs (the randomized hash() solution which is preferred, and
> would also be my preference), suds caching becomes completely useless.
> And for the results, see above.
I've taken a quick look into the suds source; the good news is that you have
to change a single method, reader.Reader.mangle(), to fix the problem with
hash stability.
However, I didn't see any code to deal with hash collisions at all.
More information about the Python-list
mailing list