Details

    • Type: Bug Bug
    • Status: Resolved (View Workflow)
    • Priority: Major Major
    • Resolution: Rejected
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Clustering
    • Labels:
    • Similar Issues:
      Show 10 results 

      Description

      In previous versions of AS, the cluster partition name was exposed and user changeable. Users expect to set that in order to build different clusters. This should be exposed r/w in the management api.

      See also https://issues.jboss.org/browse/ISPN-1976

        Gliffy Diagrams

          Activity

          Hide
          Radoslav Husar added a comment -

          I should say yet here again, this is not a way to build clusters.

          (11:18:18 AM) rhusar: pilhuhn: afaik the partition name was a perf killer, receiving messages on physical layer that are not intended for that node is a waste of network bandwidth moreover you need to parse the message through all stacks and then just dump it..

          The way to build clusters is to use different UDP multicast group/port.

          Show
          Radoslav Husar added a comment - I should say yet here again, this is not a way to build clusters. (11:18:18 AM) rhusar: pilhuhn: afaik the partition name was a perf killer, receiving messages on physical layer that are not intended for that node is a waste of network bandwidth moreover you need to parse the message through all stacks and then just dump it.. The way to build clusters is to use different UDP multicast group/port.
          Hide
          Paul Ferraro added a comment -

          The cluster name of a cache container (analogous to partition name) is already exposed via the management API.
          e.g.
          /subsystem=infinispan/cache-container=cluster/transport=TRANSPORT:read-attribute(name=cluster)

          As Rado mentioned, you wouldn't want to isolate your clusters via cluster name alone - this would be done via distinct jgroups-udp multicast-address/port socket bindings.

          Show
          Paul Ferraro added a comment - The cluster name of a cache container (analogous to partition name) is already exposed via the management API. e.g. /subsystem=infinispan/cache-container=cluster/transport=TRANSPORT:read-attribute(name=cluster) As Rado mentioned, you wouldn't want to isolate your clusters via cluster name alone - this would be done via distinct jgroups-udp multicast-address/port socket bindings.
          Hide
          Heiko Rupp added a comment -

          Paul, additional question

          • if the user uses jgroups over tcp, the mc-address does not exist for obvious reasons. What would be a surrogate?
          • the exposed ISPN attribute has a default of 'undefined'. Is the user ever required to set it?
          Show
          Heiko Rupp added a comment - Paul, additional question if the user uses jgroups over tcp, the mc-address does not exist for obvious reasons. What would be a surrogate? the exposed ISPN attribute has a default of 'undefined'. Is the user ever required to set it?
          Hide
          Paul Ferraro added a comment -

          1. In the TCP case, cluster communication is unicast only - so cluster "isolation" is less of an issue - since cluster membership is explicit, either defined statically or via a specific discovery method (e.g. S3_PING for EC2). Note that the default tcp stack uses multicast for discovery (i.e. MPING), so isolated clusters would still want to use distinct multicast address/ports, defined via the jgroups-mping socket binding.

          2. If undefined, the "cluster" attribute defaults to the cache container name.

          Show
          Paul Ferraro added a comment - 1. In the TCP case, cluster communication is unicast only - so cluster "isolation" is less of an issue - since cluster membership is explicit, either defined statically or via a specific discovery method (e.g. S3_PING for EC2). Note that the default tcp stack uses multicast for discovery (i.e. MPING), so isolated clusters would still want to use distinct multicast address/ports, defined via the jgroups-mping socket binding. 2. If undefined, the "cluster" attribute defaults to the cache container name.
          Hide
          Ian Springer added a comment -

          Hi Paul,

          Can you give me the full path of the multicast-address/port attributes we should be using to determine a host controller's cluster?

          Thanks,
          Ian

          Show
          Ian Springer added a comment - Hi Paul, Can you give me the full path of the multicast-address/port attributes we should be using to determine a host controller's cluster? Thanks, Ian
          Hide
          Paul Ferraro added a comment -

          The socket-binding name for the udp stack can be retrieved via:
          read-attribute --node=/subsystem=jgroups/stack=udp/transport=TRANSPORT socket-binding

          Using the default configuration, this returns: jgroups-udp

          The multicast address/port can then be retrieved via:
          read-attribute multicast-address --node=/socket-binding-group=standard-sockets/socket-binding=jgroups-udp
          read-attribute multicast-port --node=/socket-binding-group=standard-sockets/socket-binding=jgroups-udp

          Show
          Paul Ferraro added a comment - The socket-binding name for the udp stack can be retrieved via: read-attribute --node=/subsystem=jgroups/stack=udp/transport=TRANSPORT socket-binding Using the default configuration, this returns: jgroups-udp The multicast address/port can then be retrieved via: read-attribute multicast-address --node=/socket-binding-group=standard-sockets/socket-binding=jgroups-udp read-attribute multicast-port --node=/socket-binding-group=standard-sockets/socket-binding=jgroups-udp

            People

            • Assignee:
              Paul Ferraro
              Reporter:
              Heiko Rupp
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development