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.
the name of the remote server
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:
Create a new remote server instance at the server.
If a remote server with the same name already exists an error will be returned.
a remote server definition created using the appropriate sub-type of RemoteServerBuilder.
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:
null or undefined
List all the remote servers that have been created.
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:
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.
the name of the remote server
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:
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:
6.5