JGroups
  1. JGroups
  2. JGRP-872

TP: cluster name is shipped with each message

    Details

    • Type: Feature Request Feature Request
    • Status: 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.

        Gliffy Diagrams

          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:

                  Development