WildFly
  1. WildFly
  2. WFLY-861

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

    Details

    • 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.

        Gliffy Diagrams

          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:

                Development