Проблемы с jgroups Connection.Receiver

Question

Мы используем jgroups для синхронизации нескольких java-объектов через наш кластер. На данный момент у нас есть только два сервера, и мы используем протокол TCP. Мы настроили один порт TCP (42812) для синхронизации.

Мы обнаружили следующую проблему: когда серверы работают некоторое время, от 1 часа до 3 часов, тогда использование памяти значительно возрастает. Вот почему мы взяли дамп кучи, и на обоих серверах мы находим следующую утечку:

The thread java.lang.Thread @ 0x5ff35fdd8 Connection.Receiver [11.63.99.51:42813 
- 11.63.99.51:42813],userNotificationCounterSync,hjad-gts4-de16-38376 keeps local
variables with total size 1.650.814.560 (38,04%) bytes.

The memory is accumulated in one instance of "byte[]" loaded by "".
The stacktrace of this Thread is available. See stacktrace.

Когда мы делали дамп tcp, мы видели только пакеты syn ack, отправленные через порт 42813, но это было после того, как память поднялась. Поэтому нам кажется, что серверы получают сообщения через ненастроенный порт и не обрабатывают их. Использование памяти никогда не превышает 1.650.814.560 байт, и синхронизированные контейнеры синхронизируются, поэтому у нас нет проблем с синхронизацией. Мы настраиваем JChannel в нашей весенней конфигурации xml с port_range 0:

TCP(bind_port=12812;
port_range=0;
recv_buf_size=130k;
send_buf_size=130k;
tcp_nodelay=true;
enable_bundling=false;)
:TCPPING(initial_hosts=server1[42812],server2[42812])
:MERGE2:FD_SOCK:VERIFY_SUSPECT:pbcast.NAKACK(use_mcast_xmit=false;retransmit_timeout=300,600,1200,2400,4800;discard_delivered_msgs=true;)
:UNICAST:pbcast.STABLE(stability_delay=1000;desired_avg_gossip=50000;max_bytes=400000;)
:FRAG:pbcast.GMS(print_local_addr=true;join_timeout=3000;view_bundling=true;):pbcast.STATE

По нашему мнению, при такой конфигурации узлы не должны связываться через порт 42813.

Как это возможно, что Connection.Receiver получает так много данных через этот порт, и почему это не обрабатывается?

Answer 1

Вся проблема заключалась в том, что диапазон портов, который, по моему мнению, был установлен по умолчанию равным 0. Это оказалось неверным, мы просто установили параметр port_range=0 в конфигурации TCP и TCPPING, и все работает как положено.