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

Headers.resize() called unnecessarily

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 3.6.12, 4.0
    • Labels:

      Description

      Each message has space for 4 headers. When a 5th header needs to be added, the array needs to be resized. This is something we want to avoid as much as possible.

      However, the following scenario can lead to resizing:

      • A bundler writes a message list with (say) 3 headers
      • A message list always ignores the transport header, as it is only used to carry the cluster name, but that name is available in the batch header, too.
      • Therefore, the size of the headers written is 2 and the transport header is not written
      • On the receiver side, when reading the batch, we create and read 2 headers
        • This is OK, as message batches are matched against the receiver's cluster name using the cluster name shipped in the batch itself and not in the message
        • Message batches are therefore passed up without the individual messages carrying a transport header
      • However, single messages need to carry a transport header as it will be used to do the cluster name matching
      • Now, if a batch contains messages tagged as OOB|DONT_BUNDLE, they will be removed from the batch and sent up the stack as separate messages, each in a separate thread.
      • To do this, each of these messages is added a transport header (created using the batch's cluster name).
      • However, this necessitates a resizing as the headers array has a length of only 2, but we now need 3 headers

      Note that we don't run into this in 4.0, as Infinispan 9 (which uses 4) doesn't use DONT_BUNDLE any longer. It is still an unnecessary memory allocation and needs to be optimized.

      However, we should fix it in 3.6 as we still use DONT_BUNDLE in Infinispan 8.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  belaban Bela Ban
                  Reporter:
                  belaban Bela Ban
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: