Rete broker inondata di messaggi ActiveMQ.Advisory.TempQueue non consumati

Question

Attualmente sto esaminando un problema di memoria nella mia rete di broker. In base a JConsole, ActiveMQ.Advisory.TempQueue occupa il 99% della memoria configurata quando il broker inizia a bloccare i messaggi.

Alcuni dettagli circa la configurazione

configurazione di default per la maggior parte. Un connettore aperto stomp + nio, un connettore openwire aperto. Tutti i broker formano un ipercubo (una connessione a ogni altro broker (più facile da generare automaticamente)). Nessun controllo del flusso. Dettagli

Problema

La webconsole mostra qualcosa come 1.974.234 accodato e 45345 rimosse dalla coda dei messaggi a 30 consumatori (6 broker, un consumatore e il resto è client che utilizzano il connettore Java). Per quanto ne so, il conteggio delle dequeue non dovrebbe essere molto più piccolo di: accodato * i consumatori. quindi nel mio caso non viene consumato un gran numero di avvisi e inizia a riempire il mio spazio di messaggi temporanei. (attualmente ho configurato diversi GB come spazio temporaneo)

Poiché nessun client utilizza attivamente le code temporanee, lo trovo molto strano. Dopo aver dato un'occhiata alla coda dei temp sono ancora più confuso. La maggior parte dei messaggi simile a questa (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 = org.apache.activemq.util.ByteSequence@45290155, 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} 

Dopo aver visto questi messaggi Ho molte domande:

1. Ho capito bene che l'origine del messaggio è uno Stomp connessione?
2. In caso affermativo, in che modo una connessione Stomp può creare code temporanee?
3. C'è un motivo semplice per cui gli avvisi non vengono consumati?

Attualmente ho risolto il problema disattivando la proprietà bridgeTempDestinations sui connettori di rete. in questo modo i messaggi non vengono diffusi e riempiono lo spazio temp molto più lentamente. Se non riesco a correggere l'origine di questi messaggi vorrei almeno impedirgli di riempire il negozio:

1. Posso eliminare questi messaggi non consumati dopo un certo tempo?
2. quali conseguenze può avere?

AGGIORNAMENTO: Ho monitorato il mio cluster ancora e ho scoperto che i messaggi sono stati consumati. Vengono accodati e inviati ma i consumatori (gli altri nodi del cluster come mutanti come utenti java che utilizzano la lib activemq) non riescono a riconoscere i messaggi. quindi rimangono nella coda dei messaggi inviati e questa coda cresce e cresce.

Answer 1

Se non si utilizza questo argomento advisory - si consiglia di spegnerlo come è suggerito a http://activemq.2283324.n4.nabble.com/How-to-disable-advisory-for-gt-topic-ActiveMQ-Advisory-TempQueue-td2356134.html

Dropping i messaggi di consulenza non avrà alcuna conseguenza - dal momento che questi sono solo i messaggi destinati per l'analisi dello stato del sistema e statistiche.

Answer 2

Questo è un vecchio thread, ma nel caso in cui qualcuno si imbatte in esso avendo lo stesso problema, si potrebbe voler controllare questo post: http://forum.spring.io/forum/spring-projects/integration/111989-jms-outbound-gateway-temporary-queues-never-deleted

Il problema in quel collegamento suona simile, vale a dire le code temporanee che producono grandi quantità di messaggi di consulenza. Nel mio caso, stavamo utilizzando le code temporanee per implementare la richiesta sincrona/la messaggistica di risposta, ma il volume dei messaggi di avviso ha causato che ActiveMQ trascorresse la maggior parte del suo tempo in GC e alla fine generasse un'eccezione superata per il limite superiore del GC. Questo era su v5.11.1. Anche se abbiamo chiuso la connessione, la sessione, il produttore, il consumatore, la coda temporanea non sarebbe stata GC e continuerebbe a ricevere messaggi di avviso.

La soluzione era quella di eliminare in modo esplicito le code temporanei durante la pulizia le altre risorse (vedi https://docs.oracle.com/javaee/7/api/javax/jms/TemporaryQueue.html)