2011-05-17 28 views
6

Estoy bastante seguro de que la espuma no está almacenando en caché mis WSDL y XSDs like I expect it to. Aquí es cómo sé que no están siendo utilizados los objetos almacenados en caché:Suds no está reutilizando WSDL y XSD almacenados en caché, aunque lo espero

  1. Se tarda unos 30 segundos para crear un cliente: client = Client(url)
  2. Las entradas del registrador muestran la digestión coherente de los archivos XSD y WSDL durante todos los 30 segundos
  3. Wireshark está mostrando el tráfico TCP coherente con el servidor de almacenamiento de los archivos XSD y WSDL durante todo el segundo 30
  4. veo los archivos de la memoria caché se actualiza cada vez que corro mi programa

Tengo un pequeño programa que crea un cliente de espuma, envía una sola solicitud, obtiene la respuesta y luego finaliza. Mi expectativa es que cada vez que ejecute el programa, debe buscar los archivos WSDL y XSD de la memoria caché de archivos, no de las URL. He aquí por qué creo que:

  1. client.options.cache.duration se establece en ('days', 1)
  2. client.options.cache.location se establece en c:\docume~1\mlin\locals~1\temp\suds y veo los archivos de caché que se generan y se re-genera cada vez que ejecute el programa
  3. Por un momento me pensó que tal vez el caché no se vuelve a utilizar entre ejecuciones de un programa, pero no creo que una caché de archivos se utilizaría si ese fuera el caso, debido a que una en memoria caché podría hacer muy bien

¿Entiendo mal cómo se supone que funciona el almacenamiento en caché?

+1

Cuando copié los WSDL y XSD para esto en el sistema de archivos local, solo me llevó unos 3 segundos cargar desde allí. Todavía es demasiado lento teniendo en cuenta el pequeño tamaño de esta definición de servicio web. Tengo un servicio web que toma más de 2 minutos para que la espuma se cargue desde el sistema de archivos local. ¡No quiere saber cuánto tiempo lleva cargar las URL! –

Respuesta

15

El problema está en la propia biblioteca de jabonaduras. En cache.py, aunque ObjectCache.get() siempre obtiene un puntero de archivo válido, está golpeando una excepción (EOFError) haciendo pickle.load(fp). Cuando eso sucede, el archivo simplemente se descarga nuevamente.

Aquí está la secuencia de eventos:

DocumentReader.open():

  1. Tratando http://172.28.50.249/wsdl/billingServices/v3.0/RequestScrubAddress.wsdl
  2. Cargando ObjectCache 51012453-documento
  3. Cargando ...
  4. objeto estibado
  5. Excepción levantada:
  6. Got Ninguno de caché
  7. Descargando ... Hecho
  8. ahorro filecache 51012453-documento ... Hecho

Por lo tanto, en realidad no importa que el nuevo archivo de caché se salvó, porque lo mismo sucede la la próxima vez que corro Esto sucede para TODOS los archivos WSDL y XSD.

Solucioné ese problema abriendo el archivo de caché en modo binario al leer y escribir. Específicamente, los cambios que hice estaban en el caché.py:

1) En FileCache.put(), cambie esta línea:

f = self.open(fn, 'w') 

a

f = self.open(fn, 'wb') 

2) En FileCache.getf(), cambiar esta línea:

return self.open(fn) 

a

return self.open(fn, 'rb') 

No sé el código base lo suficientemente bien como para saber si estos cambios son seguros, pero es tirando de los objetos de la caché de archivos, el servicio sigue siendo funcionando con éxito, y cargando al cliente fue de 16 segundos a 2.5 segundos. Mucho mejor si me preguntas.

Esperemos que esta solución, o algo similar, pueda introducirse nuevamente en la línea principal de la espuma. Ya he enviado esto a la lista de correo de suds (lista de fedora-suds en redhat dot com).

+1

Funcionó como un amuleto. Este problema ha sido muy frustrante para mí. ¡Gracias! – serialworm

+0

¿Recibió algún comentario sobre esto de los desarrolladores de espuma? No pude encontrar tu boleto ... –

+2

Recibí comentarios de la lista de correo. Incluso teníamos las correcciones en una rama en BitBucket (que se eliminó desde entonces), pero los cambios nunca se incorporaron al proyecto. Siéntase libre de volver a enviarlo. Siga el hilo del correo electrónico aquí: http://lists.fedoraproject.org/pipermail/suds/2011-July/001481.html –

Cuestiones relacionadas