Problems with caching and nsprefix creation
by Enrico Tröger
Hi guys,
tl;dr
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
below.
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'
(ServiceDefinition.nextprefix()).
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.
Regards,
Enrico
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 :(.
12 years
I want to hack on Suds but have some questions
by Hsu, Ryan
Hi All,
I am looking to work on the Suds project as it looks like the project has stagnated and a new release hasn't been released in a while. Some questions though:
1. First, I have looked at the code already but haven't delved into it too deeply. Can anyone give a short overview of the modules and/or architecture?
2. What is the most recent build or what is the latest code. I looked through the mailing list and it looks like Veres-Szentkiralyi Andras has created a version with some fixes here: https://github.com/dnet/suds. Should I fork his or is there a newer version someone knows about?
3. Any resources for someone who has worked on with SOAP on a surface level but has not delved too deeply into SOAP internals? Any resources useful in general to work with the Suds?
Any help is greatly appreciated!
Thanks,
Ryan
12 years
Can't get around HTTP/401 response
by Adam Tauno Williams
SUDS version 0.4 pn x86_64 Python 2.7
I'm having a bear of a time getting HTTP Basic Authentication to work
for a SOAP request via suds. Also using an HTTP proxy server.
In WireShark I just see a request -
GET http://...../services/services/JobService-0.0.1?wsdl HTTP/1.1
Accept-Encoding: identity
Host: .......
Connection: close
User-Agent: Python-urllib/2.7
This doesn't contain any authentication credentials so the response is
HTTP/401, and the client doesn't retry with credentials. The response
does come from the remote as I can see there is a WWW-Authenticate
header and it is from an Apache Tomcat server - so it makes it through
the proxy server.
Code
================
url = 'http://....../services/services/JobService-0.0.1?wsdl'
proxy = urllib2.ProxyHandler({'http': 'http://.....:3128'})
transport = suds.transport.http.HttpAuthenticated()
transport.urlopener = urllib2.build_opener(proxy)
client = suds.client.Client(url, transport=transport,
username='******', password='********')
....
I've tried the above as well as the method described at
<http://blogs.oucs.ox.ac.uk/inapickle/2011/05/14/exchange-web-services-sud...> It has the same problem.
Back Trace
================
Traceback (most recent call last):
File "etrace.py", line 30, in <module>
client = suds.client.Client(url, transport=transport,
username='*******', password='*****')
File
"/usr/local/lib/python2.7/site-packages/suds-0.4-py2.7.egg/suds/client.py", line 112, in __init__
self.wsdl = reader.open(url)
File
"/usr/local/lib/python2.7/site-packages/suds-0.4-py2.7.egg/suds/reader.py", line 152, in open
d = self.fn(url, self.options)
File
"/usr/local/lib/python2.7/site-packages/suds-0.4-py2.7.egg/suds/wsdl.py", line 136, in __init__
d = reader.open(url)
File
"/usr/local/lib/python2.7/site-packages/suds-0.4-py2.7.egg/suds/reader.py", line 79, in open
d = self.download(url)
File
"/usr/local/lib/python2.7/site-packages/suds-0.4-py2.7.egg/suds/reader.py", line 95, in download
fp = self.options.transport.open(Request(url))
File
"/usr/local/lib/python2.7/site-packages/suds-0.4-py2.7.egg/suds/transport/http.py", line 173, in open
return HttpTransport.open(self, request)
File
"/usr/local/lib/python2.7/site-packages/suds-0.4-py2.7.egg/suds/transport/http.py", line 64, in open
raise TransportError(str(e), e.code, e.fp)
suds.transport.TransportError: HTTP Error 401: Unauthorized
--
System & Network Administrator [ LPI & NCLA ]
<http://www.whitemiceconsulting.com>
OpenGroupware Developer <http://www.opengroupware.us>
Adam Tauno Williams
12 years, 1 month
ITC société de TRADUCTION!
by Marie Françoise Greck – ITC France
English ( "http://www.itcglobaltranslations.com/email/itcfrance/english/index.html" ) - Español ( "http://www.itcglobaltranslations.com/email/itcfrance/spanish/index.html" )- Deutsch ( "http://www.itcglobaltranslations.com/email/itcfrance/german/index.html" )
Bonjour,
J’ai obtenu les informations concernant votre entreprise sur Internet et je prends donc la liberté de vous contacter.
Notre société de traduction, ITC Traduction ( "http://www.itcfrance.com/" ), serait intéressée par une collaboration avec votre entreprise pour vos projets de traduction. Accepteriez-vous, à cet égard, de transférer cet email à la personne responsable de la traduction de vos documents ainsi qu’à votre département marketing ?
ITC est une société de traduction qui propose des services de traduction très technique dans plus de 25 langues. Forts d’une expérience de 10 ans de collaboration avec des entreprises internationales et avec des bureaux en Europe et aux Etats-Unis, nous nous sommes forgé une solide réputation et nous disposons d’un portefeuille clients incluant des organisations réputées telles que Cap Gemini, Johnson Controls, Emerson Process, John Deere, Haulotte, Sciemetric, Toyota, Pfizer, Covidien, Publicis, L’Oréal, Nestlé, Sanofi, l’Organisation Mondiale de la Santé (OMS), Averion, Alstom, l’Association Word Trade Center, et les Nations Unies, pour n’en citer que quelques-unes.
Traductions de documents techniques : guides d’utilisateur, notices d’emballage, documentation technique, interfaces graphiques (GUI), systèmes d’aide, guides de résolution de problèmes, instructions de travail, documents portant sur les caractéristiques produit etc.
Traductions de documents médicaux/pharmaceutiques : protocoles, comptes-rendus médicaux, brochures pour investigateur, suivis d’essai clinique, formulaires de rapport de cas (CRF), documents et attestations de conformité et d’innocuité des tests, documents relatifs aux essais cliniques, dispositions réglementaires, documents relatifs à l’enregistrement d’un médicament, autorisations de mise sur le marché, formulaires de consentement éclairé, questionnaires patients, rapports toxicologiques, rapports de sûreté et rapports d’études cliniques, mode d’emploi et encarts publicitaires, etc. Traductions de documents marketing : brochures, questionnaires/études, notices d’utilisation, emballages/étiquettes, sites Internet, communiqués de presse, livres blancs, etc.
Traductions de documents juridiques : brevets, procédures légales, contrats, traités, lois et dispositifs réglementaires, rapports d’experts, engagements de confidentialité, etc.
N’hésitez pas à me contacter pour tout renseignement complémentaire.
Je vous prie d’agréer, Madame, Monsieur, mes sincères salutations.
Marie-Françoise Greck
( "mailto:mf.greck@itcfrance.com?" )
Pour vous désinscrire ( "mailto:jm.conseil@itcglobaltranslations.com?subject=d%E9sinscrire" ). Pour demander un devis ( "mailto:mf.greck@itcfrance.com?subject=demander%20un%20devis" ).
Si on vous a transféré cet e-mail et que vous souhaitez vous inscrire pour recevoir notre newsletter ( "mailto:mf.greck@itcfrance.com?subject=inscrire" ).
( "mailto:mgreck@itcfrance.com?subject=subscribe" )
© 2011 International Traduction Conseil ( "http://www.itcfrance.com/" ) - 4 allée de la combe - 69380 Lissieu France - Tél. +33 4 78 33 02 55 - Fax +33 4 72 54 93 89
12 years, 1 month
