Actualmente estoy investigando un problema de memoria en mi red de intermediarios. Según JConsole, ActiveMQ.Advisory.TempQueue ocupa el 99% de la memoria configurada cuando el bróker comienza a bloquear mensajes.Red de intermediarios inundada con mensajes ActiveMQ.Advisory.TempQueue no consumidos
algunos detalles sobre la configuración
config en su mayor parte. Un conector stomp + nio abierto, un conector openwire abierto. Todos los intermediarios forman un hipercubo (una conexión en el camino con cada otro intermediario (más fácil de generar automáticamente)). Sin control de flujo Detalles
Problema
El webconsole muestra algo así como 1.974.234 enqueued y 45345 quitadas de la cola de mensajes a los 30 consumidores (6 corredores, uno de los consumidores y el resto es clientes que usan el conector de Java). Hasta donde yo sé, el recuento de dequeue no debería ser mucho más pequeño que: consumidores en cola *. entonces en mi caso, un gran grupo de advertencias no se consume y comienza a llenar mi espacio de mensajes temporales. (Actualmente configuré varios gb como espacio temporal)
Dado que ningún cliente utiliza activamente las colas temporales, esto me parece muy extraño. Después de echar un vistazo a la cola temporal, estoy aún más confundido. La mayoría de los mensajes de este aspecto (msg.toString):
ActiveMQMessage {commandId = 0, responseRequired = false, messageId = ID:srv007210-36808-1318839718378-1:1:0:0:203650, originalDestination = null, originalTransactionId = null, producerId = ID:srv007210-36808-1318839718378-1:1:0:0, destination = topic://ActiveMQ.Advisory.TempQueue, transactionId = null, expiration = 0, timestamp = 0, arrival = 0, brokerInTime = 1318840153501, brokerOutTime = 1318840153501, correlationId = null, replyTo = null, persistent = false, type = Advisory, priority = 0, groupID = null, groupSequence = 0, targetConsumerId = null, compressed = false, userID = null, content = null, marshalledProperties = [email protected], dataStructure = DestinationInfo {commandId = 0, responseRequired = false, connectionId = ID:srv007210-36808-1318839718378-2:2, destination = temp-queue://ID:srv007211-47019-1318835590753-11:9:1, operationType = 1, timeout = 0, brokerPath = null}, redeliveryCounter = 0, size = 0, properties = {originBrokerName=broker.coremq-behaviortracking-675-mq-01-master, originBrokerId=ID:srv007210-36808-1318839718378-0:1, originBrokerURL=stomp://srv007210:61612}, readOnlyProperties = true, readOnlyBody = true, droppable = false}
Después de ver estos mensajes Tengo varias preguntas:
- ¿Entiendo correctamente que el origen del mensaje es un pisotón ¿conexión?
- En caso afirmativo, ¿cómo puede una conexión stomp crear colas temporales?
- ¿Hay alguna razón simple por la cual los avisos no se consuman?
Actualmente, de alguna manera, pospuse el problema desactivando la propiedad bridgeTempDestinations en los conectores de red. de esta forma, los mensajes no se propagan y llenan el espacio temporal mucho más lentamente. Si no puedo solucionar el origen de estos mensajes, al menos me gustaría evitar que llenen la tienda:
- ¿Puedo dejar estos mensajes no consumidos después de un tiempo determinado?
- ¿Qué consecuencias puede tener esto?
ACTUALIZACIÓN: Supervisé mi clúster un poco más y descubrí que los mensajes se han consumido. Se colocan en cola y se envían, pero los consumidores (los otros nodos del clúster se silencian como los consumidores de Java que usan la biblioteca activemq) no reconocen los mensajes. para que permanezcan en la cola de mensajes enviados y esta cola crece y crece.
es lo que realmente tienen colas con mensajes de aviso en ellos? ¿O son temas? Si son colas, ¿tiene un consumidor específico para esas? – Paul
son temas, pero los nodos de las redes de intermediarios y el adaptador de recursos java escuchan en el destino TempQueue de forma predeterminada. – Laures
Hola @Laures, tengo un problema similar. 1. ¿Cómo se las arregló para controlar esa situación? 2. ¿Cómo lo resolvió finalmente? –