Options
All
  • Public
  • Public/Protected
  • All
Menu

Interface RemoteServers

This feature allows a client session to manage remote servers.

This feature provides the ability to configure the various modes of operation for the use of remote topic views. This is the ability for a topic view specification to indicate that the source topics for the view are to come from another server in a different Diffusion cluster. The server where the topic views are configured is referred to as the 'secondary server' and the server where the actual topics are is referred to as the 'primary server'.

Outbound Connection from the Secondary Server

The typical configuration for a remote server is that there is only configuration at the secondary server (the configuration is automatically distributed to all members of the secondary cluster). In this case, each secondary server connects to a server in the primary cluster (typically via a load-balancer).

Remote topic views can specify the use of such remote servers by name. The connection and disconnection is handled automatically by the server (or servers in the same cluster) where the remote servers are defined.

A component can specify a remote server by name even if it does not exist (has not yet been created) and when the remote server is created the connection will take place automatically.

If a remote server is removed and there are topic views that depend upon it, those topic views will be disabled.

This form of connection is provided by a RemoteServer of type SECONDARY_INITIATOR and represented by the sub-type SecondaryInitiator.

Such a remote server can be built using a SecondaryInitiatorBuilder created using newRemoteServerBuilder. It may then be added to the server (cluster) using createRemoteServer.

In this mode a connection from secondary to primary server is only maintained when there is a topic view that depends upon it. There will be no connections if there are no topic views that specify the remote server.

Outbound Connection from the Primary Server

In some cases it may be preferred that the connection is initiated by the primary server, connecting to the secondary server cluster. In this case a single primary server will connect to all members of the secondary cluster.

This form of connection is provided by a RemoteServer of type PRIMARY_INITIATOR and represented by the sub-type PrimaryInitiator. This can be built using a PrimaryInitiatorBuilder created using newRemoteServerBuilder. It may then be added to the primary server (cluster) using createRemoteServer. Secondly a RemoteServer of type SECONDARY_ACCEPTOR and represented by the sub-type SecondaryAcceptor should be created in the secondary server (cluster) with the same name as the primary initiator. Such a remote server can be built using a SecondaryAcceptorBuilder created using newRemoteServerBuilder. It may then be added to the secondary server (cluster) using createRemoteServer.

Unlike the secondary initiator mode, this mode of connection will establish connections even if there are no topic views in the secondary server (cluster) that name the remote server. If the connection is lost any topic views that depend upon it will be disabled and the primary initiator will attempt to re-establish the connection(s). Topic views depending upon the remote server will only be enabled when the connection is re-established.

Remote Server persistence and replication

Remote server configurations created through this feature are replicated across a cluster and persisted to disk.

Access control

The following access control restrictions are applied:

Accessing the feature

This feature may be obtained from a session as follows:

RemoteServers remoteServers = session.feature(RemoteServers.class);
since

6.5

Hierarchy

  • RemoteServers

Index

Methods

checkRemoteServer

  • Check the current state of a named remote server.

    This will report back the current state of the remote server, but also can be used to forcibly retry a failed remote server connection.

    Currently this only reports the state of the remote server at the server the session is connected to. In a cluster the state of the remote server on other cluster members is not reported.

    Parameters

    • name: string

      the name of the remote server

    Returns Result<RemoteServerStatus>

    a Result that completes when a response is received from the server, returning details of the remote server state.

    If the task fails, the Result will resolve with an error. Common reasons for failure include:

    • the calling session does not have CONTROL_SERVER permission;
    • the session is closed.

createRemoteServer

  • Create a new remote server instance at the server.

    If a remote server with the same name already exists an error will be returned.

    Parameters

    Returns Promise<RemoteServer>

    a Result that completes when a response is received from the server, returning the definition of the remote server created by the operation.

    If the task fails, the Result will resolve with an error. Common reasons for failure include:

    • a remote server with the given name already exists;
    • one or more connection options are invalid;
    • the operation failed due to a transient cluster error;
    • the calling session does not have CONTROL_SERVER permission;
    • the session is closed;
    • the feature is not licensed.

  • Create a new remote server instance with default connection options.

    If a remote server with the same name already exists an error will be returned.

    deprecated

    since 6.7

    Use RemoteServers.createRemoteServer in preference. This method will be removed in a future release.

    Parameters

    • name: string

      the name of the remote server

    • url: string

      the URL to use to connect to the primary server

    • principal: string

      the name of a principal used by the remote server to connect to the primary server. A zero length string may be supplied to indicate an anonymous connection

    • credentials: Credentials

      to use for connecting to the primary server

    • Optional connectionOptions: Partial<ConnectionOptions>

      (optional) a map of connection option settings. Any options not supplied will take their default values

    Returns Result<RemoteServer>

    a Result that completes when a response is received from the server, returning the definition of the remote server created by the operation.

    If the task fails, the Result will resolve with an error. Common reasons for failure include:

    • a remote server with the given name already exists;
    • one or more connection options are invalid;
    • the operation failed due to a transient cluster error;
    • the calling session does not have CONTROL_SERVER permission;
    • the session is closed.

listRemoteServers

  • List all the remote servers that have been created.

    Returns Result<RemoteServer[]>

    a Result that resolves when a response is received from the server, returning a list of remote servers.

    If the task fails, the Result will resolve with an Error. Common reasons for failure include:

    • the calling session does not have CONTROL_SERVER permission;
    • the session is closed.

removeRemoteServer

  • removeRemoteServer(name: string): Result<void>
  • Remove a named remote server if it exists.

    When a named remote server is removed, any topic views that specify it would be disabled.

    If the named remote server does not exist the completable future will complete successfully.

    Parameters

    • name: string

      the name of the remote server

    Returns Result<void>

    a Result that resolves when a response is received from the server.

    If the task fails, the Result will resolve with an Error. Common reasons for failure include:

    • the cluster was repartitioning;
    • the calling session does not have CONTROL_SERVER permission;
    • the session is closed.