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

Messages get too large due to big headers (in large clusters)

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 3.4
    • None
    • None
    • Workaround Exists
    • Hide

      Place FRAG just above the transport. FRAG (in contrary to FRAG2) uses Message.size() to determine whether a message needs to be fragmented, and therefore takes headers into account, too.

      Show
      Place FRAG just above the transport. FRAG (in contrary to FRAG2) uses Message.size() to determine whether a message needs to be fragmented, and therefore takes headers into account, too.

    Description

      In some cases, messages get bigger than the max bundling size because of large headers:

      ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...

      In the case of INSTALL_MERGE_VIEW, we send the full view (not the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.

      Possible SOLUTION

      • Place the header fields in the message's buffer instead
      • Move FRAG2 under GMS
        • Investigate impact on flow control etc

      Attachments

        Issue Links

          relates to

          Feature Request - Feature requests from customers and/or users JGRP-1507 MFC2: multicast flow control

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Open

          Bug - A problem that impairs or prevents the functions of the product. JGRP-1713 MERGE3: view in header is too big in large clusters

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              rhn-engineering-bban Bela Ban
              rhn-engineering-bban Bela Ban
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: