JGroups أكل الذاكرة

Question

لديّ مشكلة حاليًا في تكوين JGroups الخاص بي ، مما تسبب في تعثر الآلاف من الرسائل في nakack.xmit_table. في الواقع ، يبدو أن جميعهم ينتهي بهم المطاف في xmit_table ، ويشير تفريغ آخر من بضع ساعات إلى أنهم لا ينويون المغادرة أبدًا ...

هذا هو تكوين مكدس البروتوكول

UDP(bind_addr=xxx.xxx.xxx.114;
bind_interface=bond0;
ip_mcast=true;ip_ttl=64;
loopback=false;
mcast_addr=228.1.2.80;mcast_port=45589;
mcast_recv_buf_size=80000;
mcast_send_buf_size=150000;
ucast_recv_buf_size=80000;
ucast_send_buf_size=150000):
PING(num_initial_members=3;timeout=2000):
MERGE2(max_interval=20000;min_interval=10000):
FD_SOCK:
FD(max_tries=5;shun=true;timeout=10000):
VERIFY_SUSPECT(timeout=1500):
pbcast.NAKACK(discard_delivered_msgs=true;gc_lag=50;retransmit_timeout=600,1200,2400,4800;use_mcast_xmit=true):
pbcast.STABLE(desired_avg_gossip=20000;max_bytes=400000;stability_delay=1000):UNICAST(timeout=600,1200,2400):
FRAG(frag_size=8192):pbcast.GMS(join_timeout=5000;print_local_addr=true;shun=true):
pbcast.STATE_TRANSFER

رسالة بدء التشغيل ...

2010-03-01 23:40:05,358 INFO  [org.jboss.cache.TreeCache] viewAccepted(): [xxx.xxx.xxx.35:51723|17] [xxx.xxx.xxx.35:51723, xxx.xxx.xxx.36:53088, xxx.xxx.xxx.115:32781, xxx.xxx.xxx.114:32934]
2010-03-01 23:40:05,363 INFO  [org.jboss.cache.TreeCache] TreeCache local address is 10.35.191.114:32934
2010-03-01 23:40:05,393 INFO  [org.jboss.cache.TreeCache] received the state (size=32768 bytes)
2010-03-01 23:40:05,509 INFO  [org.jboss.cache.TreeCache] state was retrieved successfully (in 146 milliseconds)

... يشير إلى أن كل شيء على ما يرام حتى الآن.

لا تشير السجلات ، التي تم ضبطها على مستوى التحذير إلى أن هناك خطأ ما باستثناء المراكز

2010-03-03 09:59:01,354 ERROR [org.jgroups.blocks.NotificationBus] exception=java.lang.IllegalArgumentException: java.lang.NullPointerException

وهو ما أعتقد أنه لا علاقة له لأنه قد شوهد في وقت سابق بدون مشكلة ذاكرة الذاكرة.

لقد كنت أحفر من خلال فتحات ذاكرة من أحد الآلات للعثور على الشذوذ ولكن لا شيء حتى الآن. باستثناء ربما بعض الإحصائيات من البروتوكولات المختلفة

UDP لديه

num_bytes_sent 53617832
num_bytes_received 679220174
num_messages_sent 99524
num_messages_received 99522

بينما Nakack لديه ...

num_bytes_sent 0
num_bytes_received 0
num_messages_sent 0
num_messages_received 0

... و XMIT_Table ضخمة.

يحتوي كل جهاز على حالتين jchannel ، واحدة لـ Ehcache وواحدة لـ Treecache. يعني التمييز الخاطئ أن كلاهما يشتركان في نفس عنوان MCAST للتشخيصات ، ولكن هذا لا ينبغي أن يشكل مشكلة ما لم أرغب في إرسال رسائل التشخيص بشكل صحيح؟ ومع ذلك ، فإنهم يفعلون بالطبع عناوين MCAST مختلفة للرسائل.

يرجى طلب التوضيحات ، لدي الكثير من المعلومات ، لكنني غير متأكد بعض الشيء بشأن ما هو ذي صلة في هذه المرحلة.

Answer 1

اتضح أن إحدى العقد في الكتلة لم تتلق أي رسائل البث المتعدد على الإطلاق. تسبب هذا في التمسك بجميع العقد على XMIT_Tables ، حيث لم تحصل على أي رسائل استقرار من العقدة "المعزولة" ، قائلة إنها تلقت رسائلها.

إعادة تشغيل الحمار ، وتغيير عنوان البث المتعدد حل المشكلة.