Details

    • Type: Bug Bug
    • Status: Resolved 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

        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: