неправильные представления слияния с infinispan и jgroups

Question

У меня есть 3-х узелный бесконечный кластер с numOwners = 2, и я сталкиваюсь с проблемами с представлениями кластера, когда один из узлов отключается от сети и возвращается обратно. Ниже приведены журналы:

(Incoming-1, BrokerPE-0-28575) ISPN000094: Получен новый вид кластера для канала ISPN: [BrokerPE-0-28575 | 2] (3) [BrokerPE-0-28575 , SEM03VVM-201-59385, SEM03VVM-202-33714]

ISPN000094: Полученное новое представление кластера для канала ISPN: [BrokerPE-0-28575 | 3] (2) [BrokerPE-0-28575, SEM03VVM- 202-33714] -> один узел отсоединен

ISPN000093: Received нового, слившийся вид кластера для канала ISPN: MergeView :: [BrokerPE-0-28575 | 4] (2) [BrokerPE-0-28 575, SEM03VVM-201-59385], 2 подгруппы: [BrokerPE-0-28575 | 3] (2) [BrokerPE-0-28575, SEM03VVM-202-33714], [BrokerPE-0-28575 | 2] (3) [BrokerPE-0-28575, SEM03VVM-201-59385, SEM03VVM-202-33714] -> неправильное слияние

Ниже мои JGroups конфигурации:

<config xmlns="urn:org:jgroups" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups-3.6.xsd"> 
    <TCP 
      bind_addr="${jgroups.tcp.address:127.0.0.1}" 
     bind_port="${jgroups.tcp.port:7800}" 
     loopback="true" 
     port_range="30" 
     recv_buf_size="20m" 
     send_buf_size="640k" 
     max_bundle_size="31k" 
     use_send_queues="true" 
     enable_diagnostics="false" 
     sock_conn_timeout="300" 
     bundler_type="old" 

     thread_naming_pattern="pl" 

     timer_type="new3" 
     timer.min_threads="4" 
     timer.max_threads="10" 
     timer.keep_alive_time="3000" 
     timer.queue_max_size="500" 


     thread_pool.enabled="true" 
     thread_pool.min_threads="2" 
     thread_pool.max_threads="30" 
     thread_pool.keep_alive_time="60000" 
     thread_pool.queue_enabled="true" 
     thread_pool.queue_max_size="100" 
     thread_pool.rejection_policy="Discard" 

     oob_thread_pool.enabled="true" 
     oob_thread_pool.min_threads="2" 
     oob_thread_pool.max_threads="30" 
     oob_thread_pool.keep_alive_time="60000" 
     oob_thread_pool.queue_enabled="false" 
     oob_thread_pool.queue_max_size="100" 
     oob_thread_pool.rejection_policy="Discard" 

     internal_thread_pool.enabled="true" 
     internal_thread_pool.min_threads="1" 
     internal_thread_pool.max_threads="10" 
     internal_thread_pool.keep_alive_time="60000" 
     internal_thread_pool.queue_enabled="true" 
     internal_thread_pool.queue_max_size="100" 
     internal_thread_pool.rejection_policy="Discard" 
     /> 

    <!-- Ergonomics, new in JGroups 2.11, are disabled by default in TCPPING until JGRP-1253 is resolved --> 
    <TCPPING timeout="3000" initial_hosts="${jgroups.tcpping.initial_hosts:HostA[7800],HostB[7801]}" 
      port_range="2" 
      num_initial_members="3" 
      ergonomics="false" 
     /> 

    <!-- MPING bind_addr="${jgroups.bind_addr:127.0.0.1}" break_on_coord_rsp="true" 
     mcast_addr="${jboss.default.multicast.address:228.2.4.6}" 
     mcast_port="${jgroups.mping.mcast_port:43366}" 
     ip_ttl="${jgroups.udp.ip_ttl:2}" 
     num_initial_members="3"/--> 
    <!-- <MPING bind_addr="${jgroups.bind_addr:127.0.0.1}" break_on_coord_rsp="true" 
     mcast_addr="${jboss.default.multicast.address:228.2.4.6}" 
     mcast_port="${jgroups.mping.mcast_port:43366}" 
     ip_ttl="${jgroups.udp.ip_ttl:2}" 
     num_initial_members="3"/> --> 
    <MERGE3 max_interval="30000" min_interval="10000"/> 

    <FD_SOCK bind_addr="${jgroups.bind_addr}"/> 
    <FD timeout="3000" max_tries="3"/> 
    <VERIFY_SUSPECT timeout="3000"/> 
    <!-- <BARRIER /> --> 
    <!-- <pbcast.NAKACK use_mcast_xmit="false" retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="true"/> --> 
    <pbcast.NAKACK2 use_mcast_xmit="false" 
        xmit_interval="1000" 
        xmit_table_num_rows="100" 
        xmit_table_msgs_per_row="10000" 
        xmit_table_max_compaction_time="10000" 
        max_msg_batch_size="100" discard_delivered_msgs="true"/> 
    <UNICAST3 xmit_interval="500" 
      xmit_table_num_rows="20" 
      xmit_table_msgs_per_row="10000" 
      xmit_table_max_compaction_time="10000" 
      max_msg_batch_size="100" 
      conn_expiry_timeout="0"/> 

    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/> 
    <pbcast.GMS print_local_addr="true" join_timeout="3000" view_bundling="true" merge_timeout="6000"/> 
    <tom.TOA/> <!-- the TOA is only needed for total order transactions--> 

    <UFC max_credits="2m" min_threshold="0.40"/> 
    <!-- <MFC max_credits="2m" min_threshold="0.40"/> --> 
    <FRAG2 frag_size="30k"/> 
    <RSVP timeout="60000" resend_interval="500" ack_on_delivery="false" /> 
    <!-- <pbcast.STATE_TRANSFER/> --> 
</config> 

Я использую Infinispan 7.0. 2 и jgroups 3.6.1. Я пробовал много конфигов, но ничего не получилось. Ваша помощь будет высоко оценена.

[UPDATE] Все исправлено после установки следующего свойства более чем на 1: «internal_thread_pool.min_threads».

Answer 1

Итак, чтобы упростить это, мы имеем

• Посмотреть брокер | 2 = {брокер, 201202}
• 201 листьев, вид теперь брокер | 3 = {брокер, 202}
• Затем происходит слияние между броузерами | 3 и брокером | 2, что приводит к неправильному представлению брокера | 4 = {broker, 201}

Я создал [1], чтобы узнать, что здесь происходит. Во-первых, в подпунктах представления слияния должно быть указано 202, являющееся координатором подгруппы, но это было не так.

Опишите, что именно произошло: Можно ли это воспроизвести? Было бы неплохо иметь журналы уровня TRACE для FD, FD_ALL, MERGE3 и GMS ...

[1] https://issues.jboss.org/browse/JGRP-2128