Perché DefaultMessageListenerContainer non dovrebbe utilizzare CachingConnectionFactory?

Stavo leggendo la documentazione di spring su DefaultMessageListenerContainer

Dice “Nota: non utilizzare Spring’s CachingConnectionFactory in combinazione con il ridimensionamento dinamico. Idealmente, non utilizzarlo affatto con un contenitore di listener di messaggi, poiché in genere è preferibile lasciare che il contenitore del listener gestisca il caching appropriato all’interno del suo ciclo di vita. Inoltre, l’arresto e il riavvio di un contenitore listener funzioneranno solo con una connessione cache locale indipendente, non con una cache memorizzata esternamente. ”

Qualcuno potrebbe spiegare perché?

  1. Non è davvero necessario memorizzare nella cache le sessioni per i contenitori di ascolto perché le sessioni sono di lunga durata; il caching è molto utile per un uso frequente e frequente, come nel caso del JmsTemplate.
  2. Il problema è in realtà quando cacheConsumers = true (il valore predefinito). Quando si utilizza lo scaling dinamico e un listener viene arrestato, la sessione viene restituita alla cache ma il broker non sa che nessuno consumerà effettivamente da quella sessione, quindi si rimane bloccati con i messaggi che si trovano nella cache che non verranno letti fino a quella sessione sembra essere riutilizzata quando il volume aumenta.

Nota: se si desidera che JmsTemplate esecuzione sul thread del contenitore per partecipare a una transazione del contenitore, è necessario utilizzare CachingConnectionFactory modo che i produttori possano essere memorizzati nella cache, ma disabilitare la memorizzazione nella cache dei consumer in fabbrica se si dispone di una concorrenza variabile.