ObjectCache with cachingpolicy=1 seems broken + leaked nsprefix
generation when using caching
And in detail:
Suds is a cool SOAP client, great work.
However, we noticed a problem using Suds 0.4 and quite a big WSDL
(~200 KB, unfortunately I can't share it).
When we instantiate the Client with the WSDL url, it takes up to 700ms
until the Client instance has been created. This is quite long (we use
Suds in a SOAP server to call other SOAP services) as we create a new
Client per request and so 700ms is way too long.
So, for us caching is really important as it reduces the time to create
a client significantly.
Unfortunately, caching with cachingpolicy=1 (which is the only option
which gives any benefit, Document-based caching is not that useful)
causes other problems:
- the built-in ObjectCache causes an "maximum recursion depth" error
while pickling the data (stack trace attached)
- I wrote a simple memory cache to avoid pickling and having real fast
access times (code attached). However, this causes also problems, see
When using the memory-based cache, and this would most probably apply
for the filesystem-based ObjectCache as well, on each Client creation,
a ServiceDefinition object is instantiated and passed a reference to a
wsdl.Definitions object. Since this wsdl.Definitions instance is read
from the cache, multiple instantiated clients will be based on that same
wsdl.Definitions instance. Great, in theory :).
The problem is that the ServiceDefinition object manages prefix names
and creates them on-the-fly when needed and ensures the generated prefix
name is not yet used. It takes prefix suffixes out of a pool of 1024.
While the used prefixes are bound to the ServiceDefinition instance,
they are freed when this instance goes away. Unfortunately, the used
prefixes are also bound to the sax.element.Element.nsprefixes of
wsdl.Definitions instance which persists due to the cache.
Our WSDL requires about 120 prefixes after parsing and so we populate
the nsprefixes dictionaries again and again. After 9 or 10 calls the
client breaks with 'prefixes exhausted'
A couple of questions about this:
- does anyone know whether the nsprefixes dictionary should be cleared
at any point to circumvent the described exception?
I tried clearing it and it seems to solve the problem but I'm not sure
what other impacts that might have (regarding performance, stability)
as I don't know the code well enough.
- is the pickling problem with ObjectCache already known?
- any other ideas to improve Client creation performance on
bigger WSDL files?
Thanks for your help, guys.
P.S.: I would have filed a bug report in the tracker but it's quite hard
when you first have to register for a Fedora account :(.