ActiveMQ mensaje de confirmación de eventos sólo un mensaje por segundo?

Question

Hemos construido una infraestructura de aplicaciones basado en ActiveMQ.

Podemos enviar y recibir mensajes muy bien, y en su mayor parte las cosas son bastante rápido y bien.

Sin embargo, nos hemos dado cuenta de que si nos sometemos un lote de mensajes "a la vez", dice 5.000 mensajes - que ActiveMQ obtendrá los mensajes a la aplicación de 3 ª parte en el otro extremo con bastante rapidez, y que esta aplicación procesará también con bastante rapidez, y que será en Queue las respuestas de vuelta al corredor rápido también, por ejemplo menos de un minuto.

Sin embargo, por alguna razón, nuestra EXE VB.NET que originó los mensajes en primer lugar únicamente parece estar procesando los mensajes de retorno que recibe de manera irregular, a veces haciendo alrededor del uno por segundo, a veces tomando descansos durante una hora o así y luego que se remonta a uno por segundo.

Origin (VB.NET EXE which we manage) 
    -> Broker  (which we manage)
        -> (3rd party app) 
            -> back to the same broker 
                -> back to the origin app.

El receptor está esperando el MessageListener caso de C # código descargado de ActiveMQ tal vez hace 9 meses:

Public Delegate Sub MessageListener(ByVal message As NMS.IMessage)
     Member of: NMS

Creo que lo que está sucediendo es que MessageListener sólo nos da un mensaje (NMS.IMessage) para masticar, y por lo tanto eso es lo que tratamos.

¿Hay alguna manera de decir "En un evento MessageListener, por favor ver si hay otros mensajes en la cola en este momento y todos ellos hacen"?

Answer 1

Resulta que creemos que sabemos un poco más ahora de qué se trata.

Cuando nuestra aplicación WinForms VB.NET que utiliza el archivo DLL ActiveMQ finalmente se bloquea, lo que tiende a hacer un par de veces a la semana, tenemos un programa de vigilancia que utiliza el pslist Winternals y utilidades PsKill para cosechar el zombi, y luego empezamos una nueva conexión de cliente.

Cuando esto sucede, el uso de jconsole para analizar el corredor nos muestra que la sesión del zombi se ha registrado todavía, y así es el nuevo cliente fresco.

Mi teoría en este momento es que cuando ve AMQ ambas sesiones, se trata de comenzar a distribuir mensajes a las dos sesiones de estilo round-robin. AMQ intenta enviar el mensaje al zombi, que no responde. Después de una cierta cantidad de tiempo (un segundo tal vez) AMQ rinde y va a la próxima sesión en la lista, el nuevo cliente fresco.

En algún momento, el corredor o pila TCP probablemente cuenta de que el zombi no ha mantenido su conexión TCP activa y se da por vencido; a continuación, la operación vuelve a la normalidad.

Entonces la pregunta es, cómo escribir un cliente ActiveMQ que: a) no se muere o b) muere con gracia, el cierre de la sesión que en el proceso?

Editar: la actualización a la nueva versión de ActiveMQ resolvió este. También tuvimos una sola aplicación que hace el envío y recepción, pero no fue multi-hilo - por lo que si se recibió mientras estaba tratando de enviar Esto hizo que los choques. Nos re-escribimos como dos aplicaciones de consola, que envía los datos y que recibieron los datos. No hay más accidentes. También la versión anterior de ActiveMQ que estaban usando en ese momento no manejar choques con gracia, la actualización a 4.x resuelto eso.

Answer 2

Me gustaría sugerir informar de este a la Foro de Usuarios junto con tal vez criar a un problema de soporte href="http://activemq.apache.org/camel/support.html" rel="nofollow ya que esto suena como que podría haber algún problema con el código de cliente NMS y todos los desarrolladores de NMS están en esa lista y podría responder