Cualquier razón por la que no se le permitiría confirmar un mensaje usando Tibco Rendezvous?

Question

Tengo una configuración en la que algunas aplicaciones se comunican entre sí a través de Tibco cita. Las aplicaciones se comunican a través de mensajes certificado. Mi problema es que dos de mis receptores recientemente han comenzado a mostrar el comportamiento que van a obtener un Error 27, No permitido cuando quieren confirmar un mensaje (el primer mensaje en un intercambio de mensajes certificada no está certificada, hemos representaron eso).

He estado buscando alrededor de la Internet para encontrar personas con el mismo error, y he encontrado muchos, pero todos ellos conseguir el error al intentar crear el transporte TIBCO. Puedo crear el transporte muy bien, pero no puedo confirmar los mensajes recibidos sobre ella.

Nuestro entorno utiliza tanto 7.X TIBCO y 8.X, algunas veces entremezclados. Este problema aparece cuando tanto los compañeros utilizan la misma versión de TIBCO y cuando se utilizan diferentes versiones. Que no se presenta para todas las aplicaciones, pero cuando no se presentó a una aplicación, sigue siendo "roto". Descartando los archivos del libro mayor para el remitente y el receptor no hace nada. Todavía recibimos el error. Tanto el emisor como el receptor tienen los permisos adecuados para escribir en (y crear los archivos de libro mayor). Estamos conectando a RVDS ejecutan de forma permanente. El emisor y el receptor estén en diferentes máquinas. La comunicación ha funcionado sin problemas en el pasado, pero en algún momento, dejó de hacerlo. La aplicación está en java, y estamos usando las bibliotecas de auto-nativa tibrvj.jar.

El error es

...
Caused by: TibrvException[error=27,message=Not permitted]
  at com.tibco.tibrv.TibrvImplCmTPortC.natConfirmMsg(Native Method)
  at com.tibco.tibrv.TibrvImplCmTPortC.confirmMsg(TibrvImplCmTPortC.java:304)
  at com.tibco.tibrv.TibrvCmListener.confirmMsg(TibrvCmListener.java:88)
....

sé que me vas a preguntar "¿qué hiciste para que sea empezar a suceder", y mi respuesta es "no sé".

Cualquier entrada sería apreciada.

Gracias.

Answer 1

Como resultado, fue una metida de pata en el nivel de aplicación. Debido a algún viejo código por ahí, después de haber actualizado una dependencia (nuestra capa de mensajería), que había pasado de una confirmación de nivel de aplicación para una confirmación nivel de contenedor, pero habíamos olvidado de quitar un mensaje de confirmación explícita en el código de la aplicación.

Para resumir:. Tratamos de confirmar el mensaje dos veces, y la segunda vez que lanzó esta excepción

Answer 2

Puede ser posible que las conexiones TCP entre los dos servidores RVD no es posible. ¿Se puede comprobar si se puede conectar de una a la otra (la conexión de la parte posterior anfitrión del abonado a la editorial)? En mi experiencia, los acuses de recibo CM se manejan a través de TCP (por favor tomar esto con un grano de sal que a mí más que un usuario final de un individuo de la ayuda Middleware).

Answer 3

Hace poco me encontré con la misma excepción - solicitud había estado trabajando durante meses, de repente estaba lanzando una excepción. En mi caso un poco de mantenimiento se había hecho en el servidor Windows se ejecutó la aplicación en directorios y había sido marcado de sólo lectura. Una vez que se autorizó la excepción fue.

Descubierto esto después de horas de fallos y averías valor de otras causas potenciales.

Answer 4

Sólo mis dos centavos:. Esta excepción se produce cuando se intenta explícitamente mensaje de confirmación en el transporte no-CM