Quello che state vedendo è un'interazione tra il ActiveMQ message store comportamento e che per durable subscriptions on topics.
Quando si hanno sottoscrizioni durature, un argomento viene trattato come una coda per ogni clientId dell'abbonato (impostato su Connection). La logica è che il client non vuole perdere alcun messaggio quando si disconnette. Quindi, se si scollegano, l'abbonamento durevole si blocca e mantiene i messaggi vivi.
L'archivio messaggi AMQ utilizza i registri di dati per il suo giornale dei messaggi. Questi sono scritti in modo sequenziale e mai realmente rimossi da (ciò richiederebbe l'accesso casuale). C'è un secondo file che tiene traccia di quali messaggi sono stati consumati. Una volta che tutti i messaggi in un file di dati sono stati consumati, quel file viene eliminato.
Quindi quello che stai vedendo è che alcuni dei messaggi nel file di dati non vengono consumati da questi abbonamenti durevoli e rimangono in giro. I ClientId per gli abbonati durevoli che non vengono utilizzati in modo coerente potrebbero causare questo problema. È probabile che ci sia qualcosa di sbagliato nel modo in cui viene utilizzata la funzione, se si utilizza JMX per ispezionare le sottoscrizioni sul broker che dovrebbero aiutare a rintracciare la causa principale.
Come regola generale, ogni volta che si pensa che si potrebbe voler utilizzare un abbonamento durevole, utilizzare invece virtual topics - sono molto più facili da ragionare, ispezionare e bilanciare il carico. D'altra parte se si desidera ottenere l'ultimo paio di messaggi quando si ricollega un utente di un argomento invece di tutti i messaggi che potrebbero essersi persi, utilizzare retroactive consumers.
Un modo semplice per aggirare questo problema è sempre use a time to live quando si invia un messaggio - praticamente ogni caso d'uso ha un limite di tempo in cui un messaggio dovrebbe essere consumato comunque. ActiveMQ scade i messaggi oltre questo punto e libera i messaggi nei file di dati per l'eliminazione.
fonte
2011-12-02 10:43:21