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

TP: cluster name is shipped with each message

    Details

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

      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
            belaban Bela Ban added a comment -

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

            Show
            belaban Bela Ban added a comment - We could use the same protocol as used to canonicalize UUIDs into IDs, to canonicalize strings to shorts
            Hide
            belaban 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
            belaban 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
            belaban 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
            belaban 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.zamarreno Galder Zamarreño added a comment -

            I wouldn't trust the user on that

            Show
            galder.zamarreno Galder Zamarreño added a comment - I wouldn't trust the user on that
            Hide
            laliluna 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
            laliluna 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
            belaban 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
            belaban 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:
                belaban Bela Ban
                Reporter:
                belaban Bela Ban
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development