2010-02-20 31 views
12

Tenemos una situación increíblemente frustrante con una API basada en CF Web Services que escribimos y mantenemos. Durante años, teníamos una API estable y que funcionaba bien con los clientes de Ruby, PHP y ColdFusion. Luego, este año apareció un cliente .NET, y descubrimos que nuestro servicio web no era interoperable con los lenguajes de tipo estático debido a nuestro uso extensivo de las estructuras.Errores serios e intermitentes con CF Web Service

Finalmente nos dimos cuenta de que teníamos que volver a escribir la API sin estructuras, y lo hemos hecho. Ahora usa valores escalares, matrices y CFC (que se traducen a SOAP complexTypes). El cliente de .NET está contento, y escribimos clientes de prueba de concepto en aproximadamente 6 idiomas diferentes para asegurarnos de que pudiéramos ser interoperables esta vez.

Para nuestra gran consternación, parece que nuestros servidores ColdFusion 7 no pueden servir a la nueva API de manera confiable. Funciona por alrededor de un día o dos después de reiniciar, a continuación, los clientes empiezan a ponerse errores como:

error: coldfusion.xml.rpc.CFCInvocationException [java.lang.ClassNotFoundException: tafkan.remote_api.pfapi.v.trunk. rsp_pf_survey_status_array]

y

java.lang.NoClassDefFoundError: tafkan/remote_api/pfapi/v/trunk/pf_unit

Reinicio de las instancias CF es la única manera de hacer que el problema desaparezca. Se invirtió mucho tiempo y dinero en la reconstrucción de la API, por lo que todo el mundo está realmente al borde de esto.

Hemos notado que los directorios de WEB-INF/cfc-skeletons de nuestras instancias CF eventualmente parecen tener dos copias de las clases para cada uno de los CFC utilizados por la API. Por ejemplo:

-rw-r--r-- Feb 17 09:15 remote_api.pfapi.v.trunk.pf_datum.class 
-rw-r--r-- Feb 3 12:20 tafkan.remote_api.pfapi.v.trunk.pf_datum.class 

Parece que los errores vienen de un problema del camino espacio de nombres o de búsqueda de clases, por lo que trató de cambiar todas las referencias de CFC a ser completamente calificado (notación de puntos a partir de un mapeo) en lugar de una simple referencias a CFC en el directorio actual. Esto parecía prometedor, pero el problema volvió en 24 horas.

Medio Ambiente:

  • ColdFusion 7,0,2,142559 con hf702-70523, el grupo 2-instancia
  • Sun Java 1.4.2_13
  • Apache 2.0.52
  • Centos 4.5 32 -bit

Tal vez la actualización de uno de estos venerables software ayudaría? ¿Tal vez actualizar solo AXIS?

El soporte de Adobe no parece ser una opción, ya que CF7 está EOL'ed y en soporte de extensión extendida (y eso solo por unos días más).

Actualización:

Gracias a todos los que he unido a esta discusión! Aquí hay una actualización de dónde están las cosas en este momento.

El servicio acaba de cagar por primera vez hoy.Una de las instancias de clúster todavía era capaz de generar el WSDL, mientras que la otra instancia dijo:

AXIS error 
Sorry, something seems to have gone wrong... here are the details: 
Exception - java.lang.NoClassDefFoundError: tafkan/remote_api/pfapi/v/trunk/rsp_pf_numeric_array 

Ambos CFC-esqueletos directorios contienen un archivo llamado tafkan.remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class, y no parece contener los archivos de otro nombre que hemos visto algunas veces (remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class). Los archivos en cfc-skeletons no parecen haber sido modificados desde que los servidores se iniciaron ayer.

El tiempo de actividad en ambas instancias fue de aproximadamente 21.5 horas. Me estaba ejecutando sin JIT (-Xint).

He reiniciado ambas instancias. Ahora se están ejecutando en Sun Java 1.4.2_19 (en lugar de _13), y JIT se ha vuelto a habilitar ya que claramente no estaba causando este error y las cosas eran mucho más lentas sin él. También borré las casillas de verificación "guardar archivos de clase".

Y ahora, esperamos de nuevo ...

Actualización 2 El problema persiste. No estoy seguro de qué más probar en este momento. Arg!

FYI, esto es cruzada publicada en http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:60922

+0

Empezaría por saltar a una JVM mucho más nueva y considerar romper el clúster (simplemente haga un ciclo completo de la solicitud si puede). También recuerde que puede configurar un par de servidores CF8 o CF9 para una prueba interna gratuita si puede acceder a ellos desde solo 1 o 2 direcciones IP – kevink

+1

Tuve un problema similar con los espacios de nombres WSDL. La solución consistía en utilizar el contenedor .cfm para generar la información de servicio web adecuada. Quizás esto también puede funcionar para ti, consulta este control de calidad http://stackoverflow.com/questions/1119721/duplicate-file-name-for-same-wsdl-namespace-when-using-web-service-from-differe/1126143 # 1126143 – Sergii

+0

uh, ColdFusion solo usa Apache Axis en el fondo (Java .... totalmente tipeado por última vez que revisé) .NET no debería tener problemas para consumir las estructuras. Lo hago todo el tiempo. Creo que se trata de algunos desarrolladores de .net por debajo del par y debería volver a las estructuras – ryber

Respuesta

3

He leído este hilo , y el hilo de CFTalk. Parece que Mark Kruger y Dave Watts ya sugirieron mis ideas iniciales sobre soluciones alternativas. La única otra solución alternativa que tuve fue detectar el error y actualizar el código del servicio web utilizando los métodos de Service Factory. (En CF8 -9 hay un método de API de administración para hacer esto, no estoy seguro acerca de CF7).

Investigando el error Reduje posibles coincidencias con estos:

http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:144821 Este fue un partido, pero no resuelto

http://blog.coldfusionpowered.com/?p=28 Este fue un error muy similar, resuelto por "cuestiones de casos de fijación" en todos los CFC & invocaciones.

ColdFusion Google Adwords Business Component Error resuelta por reescribir el código y eliminar cfcomments (sospecho que otros factores eran en realidad responsable de resolver aquí)

http://forums.crystaltech.com/index.php?topic=22364.0 Estamos cada vez más cerca ahora.La resolución implicó equivocadamente tener dos raíces de documento

http://qaix.com/coldfusion/313-410-web-service-on-cfmx-6-1-jrun-suddenly-not-working-read.shtml Coincidencia exacta para el mensaje de error. Coincidencia exacta para tener la asignación de CFC a la raíz del documento. La resolución era tener solo 1 mapeo apuntando a docroot, solo "/". Esta podría ser la solución. En MX 6/6.1 y tal vez 7, había una asignación predeterminada para "/" apuntando a docroot. Si tienes otra asignación que apunta a docroot, entonces puedo ver cómo podría surgir este problema. Verifique las rutas físicas para las asignaciones y pruebe la solución aquí, para usar solo la asignación "/".

+0

Gracias, Steven, por su investigación detallada. Lo revisé y no hay un mapeo "/" definido. Hay un/tafkan, que estoy usando para encontrar mis CFC dentro del código API. Como no puede usar un "/" en una ruta de objeto delimitada por puntos, parece que mis únicas opciones son utilizar rutas de objetos locales no calificadas (por ejemplo, "unidad pf"), lo que no funcionó (el mismo problema que tengo ahora), o para usar rutas "totalmente calificadas" comenzando con "tafkan.", que ya estoy haciendo.También noté que la última referencia que me diste, que sonaba prometedora, era un error de todos los tiempos, no intermitente. ¿Alguna otra idea? – sbleon

0

¿Cómo son los clientes externos interactúan con su servicio web? ¿Solo a través del WSDL, supongo?

¿Es posible que alguna aplicación cliente, una prueba de unidad ... algo, cualquier cosa ... tenga una URL incorrecta ... tiene una URL para su archivo WSDL con el "tafkan" en ella?

Si estuviera trabajando en ello, probablemente la primera avenida que miraría sería averiguar qué podría resultar en ese problema. ¿Es "tafkan" un directorio válido en su sistema? ¿Dónde viven realmente los archivos .cfc en el sistema de archivos, qué pasa si hay asignaciones para estas rutas en CF Admin, y cuáles son las URL que las personas están utilizando para acceder a su servicio web?

La clave aquí, creo, es meterse en la cabeza de la FQ y pidiéndole que "¿por qué se generan y se busca, una clase con 'tafkan' como un paquete?

+0

Gracias, Marc. Todos solo usan el punto final WSDL. "tafkan" es un mapeo CF que apunta a la raíz web de nuestra aplicación (/ var/www/tafkan/htdocs). Los CFC viven en/var/www/tafkan/htdocs/remote_api/pfapi/v/trunk /. Preferiría no enumerar las URL completas aquí, pero tienen el formato (https: //CLIENT_SITE_URL/remote/pfapi/v/trunk/pfapi.cfc/wsdl). Su sugerencia de entrar en la cabeza de CF es buena, pero no tengo idea de cómo hacerlo. – sbleon

+0

Marc, estoy bastante seguro de que los nombres de las clases son correctos, y que CF simplemente deja de ser capaz de encontrar la clase después de un tiempo. El WSDL tiene targetNamespace = "http: //trunk.v.pfapi.remote_api.tafkan" en su etiqueta de esquema, por lo que el nombre de clase pf_unit.trunk.v.pfapi.remote_api.tafkan parece correcto. – sbleon

+0

Estoy perdido. Tal vez contacte a Steven Erat (talkingtree.com), que solía ser ingeniero de soporte de CF con Allaire, MM, y Adobe –

Cuestiones relacionadas