Version 2
Created by jmesnil on Sep 19, 2016 11:08 AM. Last modified by jmesnil on Sep 19, 2016 11:10 AM.

    User Story

    ActiveMQ Artemis provides HA topology using colocated servers (one live backup can "host" colocated servers for other live servers in the cluster).

    There are outstanding issues that prevents to take full advantage of this feature in WildFly/EAP7.

    The main issue being that http-acceptor/http-connector does not work with colocated backup server (JBEAP-1857).

    Issue metadata

    Hard Requirements

    • WildFly must be able to configure colocated Artemis servers with http-acceptors
    • Both shared-store-colocated and replication-colocated configuration must be configured.

    Design Details

    When an ActiveMQ server creates colocated backups, it offsets the port of the transport configurations for the backup acceptors/connectors. This works fine for remote-acceptors/remote-connectors as ActiveMQ is the code accepting connections on the socket and handling them.

     

    However there is an issue when WildFly's http-acceptor are used. This is a special acceptor that maps with a special case in Artemis acceptor code. Artemis acceptor is configured but does not actually listen on the socket. Instead, it expects WildFly to hand it over the connection.

    On WildFly side, there is a HTTP upgrade endpoint that listens to upgrade HTTP connections to ActiveMQ core connections. When the HTTP upgrade handshake is successful, WildFly pass the connections to Artemis.

     

    This works fine for main Artemis servers but fails for colocated backups.

    The colocated backups offset the connectors port and it no longer points to the HTTP upgrade endpoint of the root server.

    Even if the offset is set to 0, the HTTP upgrade endpoint is always handled by the main server and it has no way to know that the connection is meant for itself or for one of its colocated backups.

     

    To fix this issue, Artemis will have to be modified to pass to the HTTP upgrade request, the name of the server that must handle the connection. It will be either the name of the main server (e.g. "default" for the default WildFly configurations) or the name of one of the colocated backups (e.g. "colocated_backup_O1").

    When WildFly messaging-activemq subsystem handles the HTTP upgrade request, it will look for a HTTP header (named "activemqServerName") containing that name. If that name is not specified, the main Artemis server will handle the request. Otherwise, it will check if there is a colocated backup with than name and hand it over the connection if that the case.

     

    It is to be noted that these properties will be used by Artemis and WildFly to find the correct Artemis server but they will not be exposed to the end user (in WildFly configuration).

    The user will just configure http-acceptor and http-connector and the messaging-activemq subsystem will ensure that these resources are properly configured for Artemis.

    Artemis Requirements

    • Artemis must be modified to send this "activemqServerName" property in the HTTP upgrade request (from its NettyConnector class).
    • When Artemis creates colocated backup configurations, it must pass the name of the backup server to its remote connectors.
    • Artemis must support a transport configuration parameter named "doNotOffset" to ensure that connectors with that parameter does not offset the port of the connector. This ensure that the connector will not offset the port for this specific connectors. This parameter will ensure that the colocated configuration can specify a port-offset for this backups that will take into account for remote acceptor/connectors and not for the HTTP ones.

     

    WildFly Requirements

    Wildyly's messaging-activemq subsystem defines a HTTP upgrade endpoint that upgrades a HTTP request to an ActiveMQ connection.

    This endpoint will be upgraded to look for a "activemqServerName" HTTP request header. If this header is not set or point to the Artemis server that owns the upgrade endpoint, this server will be used.

    Otherwise, the server will check its colocated backups for one with that name. If a backup is found, the native ActiveMQ connection will be passed to this backup server.

     

     

    Work Decomposition

    1. Artemis must be updated to support 2 new transport parameters "activemqServerName" and "doNotOffset" and uses them when creating the colocated backup configuration and sending the HTTP upgrade request.

    2. WildFly messaging-activemq must update its HTTP upgrade endpoint to check for the activemqServerName HTTP header and hand the native ActiveMQ connection to the correct server (either the main one or one of its colocated backups).

     

    QE

    Tests must be written to check that clients that uses http-connectors to connect to WildFly can properly fail over to a collocated backup on another node when the live node is stopped/killed.

    It may be possible that existing failover tests can be reused but they will require extensive change to WildFly configuration to support all the collocated use cases (both shared-store and colocated).