JGroups
  1. JGroups
  2. JGRP-872

TP: cluster name is shipped with each message

    Details

    • Type: Feature Request Feature Request
    • Status: Resolved Resolved (View Workflow)
    • Priority: Major Major
    • Resolution: Won't Fix Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 3.3
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      If a cluster name (the name used in Channel.conect()) is long, because we ship it with each message (in the TP header), this blows up the size of the marshalled messages.

      Maybe we can canonicalize the cluster name shipped with each message, similar to what we want to do with Addresses, e.g. replace the cluster name with a short.

        Issue Links

          Activity

          Hide
          Bela Ban
          added a comment -

          We could use the same protocol as used to canonicalize UUIDs into IDs, to canonicalize strings to shorts

          Show
          Bela Ban
          added a comment - We could use the same protocol as used to canonicalize UUIDs into IDs, to canonicalize strings to shorts
          Hide
          Bela Ban
          added a comment - - edited

          If we had a configuration file mapping cluster names to IDs, we could replace the cluster name with the ID (a short), and only send IDs around rather than strings.

          If we want to do without this file, or don't find it, we could simply generate the ID as a hash of the cluster name. If 2 cluster names happen to hash to the same ID, we would accept the traffic, but most likely de-serialization would fail anyway.

          Show
          Bela Ban
          added a comment - - edited If we had a configuration file mapping cluster names to IDs, we could replace the cluster name with the ID (a short), and only send IDs around rather than strings. If we want to do without this file, or don't find it, we could simply generate the ID as a hash of the cluster name. If 2 cluster names happen to hash to the same ID, we would accept the traffic, but most likely de-serialization would fail anyway.
          Hide
          Bela Ban
          added a comment -

          Another alternative is to remove cluster names altogether: if the user can guarantee that we'll never see traffic from a different cluster, we could drop shipping the cluster name in the transport header !

          Show
          Bela Ban
          added a comment - Another alternative is to remove cluster names altogether: if the user can guarantee that we'll never see traffic from a different cluster, we could drop shipping the cluster name in the transport header !
          Hide
          Galder Zamarreño
          added a comment -

          I wouldn't trust the user on that

          Show
          Galder Zamarreño
          added a comment - I wouldn't trust the user on that
          Hide
          Sebastian Hennebrueder
          added a comment -

          What about an optional cluster name?

          It can be omitted for performance reason, if the user can guaranty separation of clusters. If not he is entitled to use a short cluster name.

          We could consider to change naming from cluster name to cluster id on the long run.

          Best Regards Sebastian

          Show
          Sebastian Hennebrueder
          added a comment - What about an optional cluster name? It can be omitted for performance reason, if the user can guaranty separation of clusters. If not he is entitled to use a short cluster name. We could consider to change naming from cluster name to cluster id on the long run. Best Regards Sebastian
          Hide
          Bela Ban
          added a comment -

          With the implementation of message batching [1], the cluster name is shipped only once per batch, so this issue is moot

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

          Show
          Bela Ban
          added a comment - With the implementation of message batching [1] , the cluster name is shipped only once per batch, so this issue is moot [1] https://issues.jboss.org/browse/JGRP-1564

            People

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

              Dates

              • Created:
                Updated:
                Resolved: