2014-12-31 16 views
20

Abbiamo 4 programmi di broker ActiveMQ (ognuno in esecuzione su un server separato) in una rete di broker. Ci sono circa 60 produttori. I produttori cercano la factory di connessione ActiveMQ di Glassfish usando JDNI.Trasporto failover ActiveMQ - Perché così tante connessioni?

L'ActiveMQ URI configurato in Glassfish è la seguente:

failover:(tcp://phxgapm01:61616,tcp://phxgapm02:61616,tcp://phxgapm03:61616,tcp://phxgapm04:61616)?randomize=true&backup=false&maxReconnectAttempts=8 

Ogni processo produttore fa una ricerca JNDI del javax.jms.ConnectionFactory e quindi crea 1 javax.jms.Connection. Durante l'esecuzione del produttore, crea periodicamente javax.jms.Session e javax.jms.MessageProducer, invia alcuni messaggi a una coda e chiude la sessione e MessageProducer.

Questo è tutto sfondo - ora alla mia domanda. Da alcuni, ma non tutti i produttori, vedremo un flusso di output di registro simile al seguente:

2014-12-30 21:07:06,534 INFO FailoverTransport - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,538 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,544 INFO FailoverTransport - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,548 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,552 INFO FailoverTransport - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,556 INFO FailoverTransport - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,561 INFO FailoverTransport - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,565 INFO FailoverTransport - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,568 INFO FailoverTransport - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,572 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,577 INFO FailoverTransport - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,581 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,586 INFO FailoverTransport - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,590 INFO FailoverTransport - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,594 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 

Per alcuni dei produttori che vedremo questa uscita ogni 10 minuti - per altri è meno frequente. Ancora più confuso è il fatto che tutti questi produttori utilizzano un codice identico per la messaggistica JMS - così, mentre i produttori possono variare nel modo in cui creano sessioni e programmi di gestione dei messaggi, tutti usano lo stesso codice e creano tutti solo 1 oggetto di connessione.

Dalla lettura della documentazione, la mia comprensione è che il trasporto di failover aprirebbe una connessione a 1 dei broker (selezionando casualmente nel nostro caso). Perché vediamo questo flusso di connessioni (più connessioni a ciascuno dei broker entro 60 ms)? Usando netstat possiamo vedere queste connessioni. È normale? Se no, qualche suggerimento su cosa potrebbe causare questo?

+0

È utile il codice che utilizza gli esempi diritti JMS o JMSTemplate ecc. Esiste un PooledConnectionFactory in uso. –

+0

JMS diretto - Non è presente alcuna PooledConnectionFactory utilizzata (almeno non direttamente) – sceaj

+0

Se esiste una connessione XA Factory, è necessario utilizzare PooledConnectionFactory, altrimenti si disconnetterà/riconnetterà tutto il tempo. Puoi vedere il conteggio delle connessioni crescere in uno degli argomenti di gestione (non ricordi quale) – stringy05

risposta

1

senza avere la loglevels ActiveMQ sollevato c'è qualche spazio per la speculazione, ma:

  • "per altri è meno frequente" - osservazione del comportamento diverso su diverse istanze in questo caso è del tutto naturale. Se il carico non è perfettamente distribuito tra le istanze, si comportano diversamente quando si tratta di messaggistica. Immagina solo che uno dei tuoi nodi raccolga il 90% degli input di trigger e faccia la maggior parte del lavoro da solo. Quel nodo sarebbe sotto carico molto più elevato e userebbe le sue risorse JMS in modo completamente diverso dal resto dei nodi.
  • "la mia comprensione è che il trasporto di failover aprirebbe una connessione a 1 dei broker" - Questo è completamente vero. Il failover entrerà in gioco solo se il wrapping connectionFactory richiede l'apertura di una nuova connessione fisica. In questo caso ci sarà esattamente una connessione creata per quella richiesta.
  • "Perché vediamo questo flusso di connessioni" - Sono abbastanza sicuro che ciò è dovuto al fatto di avere un'implementazione di pool nel progetto. Puoi vedere che ci sono quelle connessioni stabilite per tutti i tuoi broker (distribuiti casualmente), indicando più richieste per nuove connessioni allo stesso tempo.

Aumentando il loglevel nella tua applicazione, sarai in grado di vedere esattamente quale layer avvia questo e per quale motivo. I possibili motivi sono: "tutte le connessioni sono scadute e il pool ripristina il conteggio minIdleConnection al minimo"; "alcune richieste in entrata nella tua applicazione richiedono l'invio di molti messaggi contemporaneamente, quindi il tuo pool li crea".

Problemi correlati