ActiveMQ yük devretme nakliyesi - Neden bu kadar çok bağlantı var?

Question

Broker ağında 4 ActiveMQ aracısı (her biri ayrı bir sunucuda çalışıyor) kurulumumuz var. Yaklaşık 60 yapımcı var. Üreticiler, JDNI kullanarak Glassfish'ten ActiveMQ bağlantı fabrikasını aramaktadır. aşağıdaki gibi ActiveMQ URI GlassFish yapılandırılmış

olup:

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

her üretici işlemi javax.jms.ConnectionFactory bir Jndi arama yapar ve daha sonra 1 javax.jms.Connection oluşturur. Üretici çalıştığı sırada, bir javax.jms.Session ve javax.jms.MessageProducer'ı periyodik olarak oluşturacak, bir sıraya bazı mesajlar gönderecek ve ardından Oturum ve MessageProducer'ı kapatacaktır. Şimdi soruma - tüm arka plan olduğunu

. Daha az olduğu diğerleri için - bu çıktıyı her 10 dakikada göreceksiniz üreticilerin bazıları için

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] 

: Bazı itibaren değil, üreticilerin hepsi şu gibi günlük çıkış akışı göreceksiniz sık. Daha da kafa karıştırıcı olması, bu üreticilerin tümünün JMS mesajlaşma için aynı kodu kullanmasıdır - bu yüzden üreticiler ne sıklıkta oturum ve mesaj üreteci oluşturdukları konusunda değişiklik gösterse de, hepsi aynı kodu kullanır ve hepsi de sadece 1 bağlantı nesnesi oluşturur.

Dokümantasyonu okuduğumdan anlaşılan, yük devretme aktarımının, aracılardan 1'iyle (bizim durumumuzda rasgele seçerek) bir bağlantı açacağıdır. Neden bu bağlantı akışını görüyoruz (60'lı yıllarda her bir brokere birden fazla bağlantı)? Netstat kullanarak bu bağlantıları görebiliriz. Bu normal mi? Aksi halde, buna neden olabilecek herhangi bir öneri var mı? activemq loglevels kalmadan

Answer 1

spekülasyonlara bazı oda var kaldırdı ama:

• "diğerleri için daha seyrek olan" - Bu durumda tamamen doğal farklı durumlarda farklı davranışlar Gözlem. Yük, örnekler arasında mükemmel bir şekilde dağıtılmamışsa, mesajlaşma söz konusu olduğunda farklı davranacaktır. Sadece düğümlerinizden birinin tetikleyici girişlerin% 90'ını aldığını ve sadece işin çoğunu yaptığını hayal edin. Bu düğüm çok daha yüksek yük altında olurdu ve JMS kaynaklarını düğümlerin geri kalanından tamamen farklı bir şekilde kullanacaktı.
• "Anlayışım, yük devretme aracının 1 aracıyla bir bağlantı açacağıdır" - Bu tamamen doğrudur. Yük devretme sadece sarma bağlantı fabrikasının yeni bir fiziksel bağlantının açılmasını talep etmesi durumunda devreye girer. Bu durumda, bu istek için tam olarak bir bağlantı oluşturulacaktır.
• "Neden bu bağlantı akışını görüyoruz" - Bunun projenizde bir havuz uygulamasına sahip olmasından kaynaklandığından oldukça eminim. Aynı anda yeni bağlantılar için birden fazla talep olduğunu belirten tüm aracı kurumlarınıza (rastgele dağıtılmış) kurulan bağlantıların olduğunu görebilirsiniz.

Uygulamanızdaki loglevel'i artırarak, hangi katmanın bunu ve hangi sebeple başlattığını tam olarak görebileceksiniz. Olası nedenler: "tüm bağlantıların süresi doldu ve havuz, minIConConnection sayısını en aza indirir"; "uygulamanızdaki bazı gelen talepler bir kerede çok sayıda iletinin gönderilmesini gerektiriyor, dolayısıyla havuzunuz bunları oluşturuyor".