WildFly
  1. WildFly
  2. WFLY-861

modcluster doesn't expose the jvmRoute information via cli. Can't execute *-context operations without it properly.

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved (View Workflow)
    • Priority: Critical Critical
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 8.0.0.Final
    • Component/s: Web (Undertow)
    • Security Level: Public (Everyone can see)
    • Labels:
    • Environment:
      EAP6
    • Steps to Reproduce:
      Hide

      i)Setup a modcluster instance with two AS7 nodes(running on two different machines).
      ii)Use read-proxy-info to view list of Nodes/cluster members and their identifiers.
      iii)Attempt to execute disable*/enable*/stop* operations and they will only affect one of the nodes.
      iv)Browsing the modcluster subsystem this is no way to view the jvmRoute identifier.
      v) Without it is is unclear how to determine what from the proxyInformation is relevant to a specific AS7 instance.

      Show
      i)Setup a modcluster instance with two AS7 nodes(running on two different machines). ii)Use read-proxy-info to view list of Nodes/cluster members and their identifiers. iii)Attempt to execute disable*/enable*/stop* operations and they will only affect one of the nodes. iv)Browsing the modcluster subsystem this is no way to view the jvmRoute identifier. v) Without it is is unclear how to determine what from the proxyInformation is relevant to a specific AS7 instance.
    • Similar Issues:
      Show 10 results 

      Description

      The modcluster subsystem needs to expose the 'jvmRoute' identifier via cli for the modcluster subsystem at the configuration level(at subsystem=modcluster/mod-cluster-config=configuration level). Without this information it is ambiguous how and which contexts will be affected when you execute the following operations:
      disable, disable-context, enable, enable-context, stop, stop-context.

      The other configuration attributes/operations target cluster-wide configuration, but the previous list of operations can only be executed at the cluster member/node level. In other words, a modcluster group could have 30 members/nodes but the above CLI operations will only affect the virtual-hosts and contexts for one of those nodes as uniquely identified by the jvmRoute. There is currently no consistent way to determine what a valid cluster identifier should be.

      The jvmRoute can be explicitly set via the 'jboss.mod_cluster.jvmRoute' property or is automatically generated. Either way the correct jvmRoute or modcluster node identifier information needs to be correctly exposed as read-only information for the modcluster subsystem.

      This post (https://community.jboss.org/message/632900), mentions an 'instance-id' on the web subsytem but it is also 'undefined' even for systems where the jvmRoute has been explicitly set or autogenerated.

      As the identifier is used by modcluster the identifier should be exposed consistently.

      Additionally there is no way to read whether a specific context is enabled/disabled. That issue probably needs it's another JIRA though.

        Activity

        Hide
        Simeon Pinder
        added a comment - - edited

        So to be a little clearer, there are several ways to set what becomes the unique mod cluster node identifier:

        • do nothing
        • explicitly set 'jboss.mod_cluster.jvmRoute' property
        • use ui/config properties files to explicitly set the 'instance-id'
          but regardless there is always a modcluster node identifier. Note: even when there is no explicit setting of this value by the last two there is still a jvmRoute identifier available if even the default.

        The request from this bug is that there is a property added to the modcluster system that reliably reports whatever that identifier is regardless of mechanism it was set. In the second and third cases one could search but for case zero there is no option. Either way this identifier is used/required by modcluster and should be made consistently available.

        Mod cluster node members need to be able to reliably know their identifier to recognize the vhosts and contexts that apache has associated with it as described by getProxyInfo for example.

        Show
        Simeon Pinder
        added a comment - - edited So to be a little clearer, there are several ways to set what becomes the unique mod cluster node identifier: do nothing explicitly set 'jboss.mod_cluster.jvmRoute' property use ui/config properties files to explicitly set the 'instance-id' but regardless there is always a modcluster node identifier. Note: even when there is no explicit setting of this value by the last two there is still a jvmRoute identifier available if even the default. The request from this bug is that there is a property added to the modcluster system that reliably reports whatever that identifier is regardless of mechanism it was set. In the second and third cases one could search but for case zero there is no option. Either way this identifier is used/required by modcluster and should be made consistently available. Mod cluster node members need to be able to reliably know their identifier to recognize the vhosts and contexts that apache has associated with it as described by getProxyInfo for example.
        Hide
        Paul Ferraro
        added a comment -

        IMO, the web subsystem is the most appropriate subsystem to expose this operation. The operation should not just report the instance id defined in the configuration (or jboss.jvmRoute system property), but rather query the value of Engine.getJvmRoute().

        Show
        Paul Ferraro
        added a comment - IMO, the web subsystem is the most appropriate subsystem to expose this operation. The operation should not just report the instance id defined in the configuration (or jboss.jvmRoute system property), but rather query the value of Engine.getJvmRoute().
        Hide
        Simeon Pinder
        added a comment -

        Sure. I'd be fine with that too. There just needs to be a consistent way to query that jvmRoute via CLI regardless of how the jvmRoute details are specified.

        Show
        Simeon Pinder
        added a comment - Sure. I'd be fine with that too. There just needs to be a consistent way to query that jvmRoute via CLI regardless of how the jvmRoute details are specified.
        Hide
        Radoslav Husar
        added a comment -

        I am taking this to see what's the status for WildFly.

        Show
        Radoslav Husar
        added a comment - I am taking this to see what's the status for WildFly.
        Hide
        Radoslav Husar
        added a comment -

        Still relevant in WildFly. Undertow does not expose a way to get this:

        [standalone@localhost:9990 /] /subsystem=undertow:read-resource(include-runtime=true,recursive=true)
        {
            "outcome" => "success",
            "result" => {
                "default-server" => "default-server",
                "default-servlet-container" => "default",
                "default-virtual-host" => "default-host",
                "instance-id" => undefined,
        ...
        
        Show
        Radoslav Husar
        added a comment - Still relevant in WildFly. Undertow does not expose a way to get this: [standalone@localhost:9990 /] /subsystem=undertow:read-resource(include-runtime=true,recursive=true) { "outcome" => "success", "result" => { "default-server" => "default-server", "default-servlet-container" => "default", "default-virtual-host" => "default-host", "instance-id" => undefined, ...
        Hide
        Tomaz Cerar
        added a comment -

        /subsystem=undertow:read-resource(name=instance-id,include-defaults=true)

        Show
        Tomaz Cerar
        added a comment - /subsystem=undertow:read-resource(name=instance-id,include-defaults=true)

          People

          • Assignee:
            Radoslav Husar
            Reporter:
            Simeon Pinder
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: