Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-2537

UNICAST3 and NAKACK2 default max_xmit_req_size is too large



    • Bug
    • Resolution: Won't Do
    • Major
    • 4.2.12, 5.1.6
    • 4.0.24, 4.2.11
    • None
    • False
    • False
    • Undefined


      When the user does not set max_xmit_req_size, UNICAST3 and NAKACK2 set it automatically based on the bundle size. That is, the maximum number of messages in a XMIT (retransmission) request is supposed to be the number of sequence numbers that would fit in a single bundle.

      The calculation of estimated_max_msgs_in_xmit_req has a mistake: instead of dividing the bundle size by the size of a single sequence number, it does a multiplication. With a bundle size of 8500 (Infinispan default), max_xmit_req_size is set to 67600.

      I believe that the default should be fixed to 100, because even the "correct" value, 1056, is too large (never mind 8000, the result with the TP default bundle size of 64k). When more than 1000 messages have been lost, the cluster is almost certainly in a lot of stress, and retransmitting all of them will take a lot of time. It very likely that RetransmitTask will run again in 500ms and will ask the sender to retransmit the same messages multiple times.

      This is even worse in Infinispan, because we change the default xmit_interval from 500ms to 100ms. This makes it much more likely for the destination to send overlapping XMIT requests.


        Issue Links


            Public project attachment banner

              context keys: [headless, issue, helper, isAsynchronousRequest, project, action, user]
              current Project key: JGRP


                rhn-engineering-bban Bela Ban
                dberinde@redhat.com Dan Berindei
                0 Vote for this issue
                2 Start watching this issue