<?xml version="1.0" encoding="UTF-8"?>
<!-- Do not remove this line. File tag: adapters_conf-APV-7.4.5. -->

<!--
    This is a generic template for the configuration file of an Adapter Set
    pluggable into Lightstreamer Server.
    It can be considered a reference example of Proxy Adapters deploy in
    the "Robust" version.
    Note that element and attribute names are handled in a case sensitive way.

    A very simple variable-expansion feature is available; see
    <enable_expansion_for_adapters_config> in the Server's main configuration file.
-->

<!-- Mandatory. Define an Adapter Set and its unique ID. -->
<adapters_conf id="PROXY_SOCKET_ROBUST">

    <!-- Optional. Requests the creation of a specific "SET" thread pool, devoted
         to the management of all the client requests pertaining to sessions
         based on this Adapter Set. Only requests related with the special
         Data Adapter used to supply the state of the MPN Module (if enabled)
         are not included and fall into the global SERVER pool.
         Note, however, that the AUTHENTICATION
         and MSG pools are always created, hence they don't contribute to this pool.

         If not defined, these requests are managed by the global SERVER
         thread pool.
         If defined, the <max_size> and <max_free> elements are mandatory,
         with meaning similar to that of the global <server_pool_max_size>
         and <server_pool_max_free> settings. Note that <max_size> also
         indicates the maximum number of pending requests to the Remote
         Adapters.
         Using a specific thread pool is advisable if the implementation
         of any of the Adapter methods introduces delays and more specific
         thread pools are not being used. -->
    <!--
    <adapter_set_pool>
        <max_size>100</max_size>
        <max_free>10</max_free>
    </adapter_set_pool>
    -->

    <!-- Optional. If "Y", ensures that the initialization of the Metadata
         Adapter ends before any initialization of the Data Adapters is performed.
         Otherwise the Metadata Adapter is initialised in parallel with all the
         other Data Adapters. In case of a Remote Adapter, the initialization
         consists of an invocation of the Metadata Init or Data Init method.
         Note that, if this flag is "Y" and there is any Remote Data Adapter
         in the Adapter Set, then, until the Metadata Adapter initialization
         is complete, the listening ports for these Remote Data Adapters will not
         be open and any connection attempt by the Remote Data Adapters will fail.

         If not defined, the default value is "Y" (i.e. Metadata Adapter
         initialised first). -->
    <metadata_adapter_initialised_first>N</metadata_adapter_initialised_first>

    <!-- Mandatory. The Metadata Adapter is the Java Proxy Adapter. -->
    <metadata_provider>

        <!-- Optional. Specify a directory other than "."
             for this Adapter's configuration files (e.g. the keystore). -->
        <install_dir>metadata</install_dir>

        <!-- Mandatory. Java class name of the Robust Proxy Metadata Adapter.
             In this case, "ROBUST_PROXY_FOR_REMOTE_ADAPTER" is a special keyword that
             identifies the Robust Proxy Metadata Adapter, which is embedded
             in Lightstreamer Server and available out of the box.
             The Robust Proxy Metadata Adapter communicates with its remote counterpart
             through standard TCP sockets. It listens on a configurable port
             and waits for its counterpart to connect.
             Moreover, this Metadata Adapter manages the case in which the remote
             counterpart is missing, by just refusing all new requests from the
             clients and storing all state change notifications that have to be
             sent to the backend (namely, session closing and table closing
             notifications).
             Meanwhile, this Metadata Adapter keeps waiting for connection
             from a new Remote Server; upon connection, it will flush pending
             notify requests, then start working normally. However, if the remote
             counterpart has restarted from scratch, then retrieving and
             restoring the state of the previously connected instance will be
             its own burden; for how to identify the involved Server instance,
             see "remote_params_prefix" below.
             Note that the unavailability of the Metadata Adapter is a severe
             issue for Lightstreamer and all client requests performed in this
             condition will fail with an "unexpected error" cause;
             this can be avoided only for requests for new sessions (see
             "notify_user_disconnection_code" below). -->
        <adapter_class>ROBUST_PROXY_FOR_REMOTE_ADAPTER</adapter_class>

        <!-- Mandatory for Proxy Adapters. Determines the ClassLoader to be used
             to load the Adapter related classes (see the base template).
             In case a Proxy Adapter is configured, it is advisable to use the
             special "log-enabled" option, to let the Proxy Adapter share the
             logging support and configuration with the Server.
             If set to "dedicated", logging support must be explicitly provided,
             by adding the slf4j library, together with a suitable log
             implementation and configuration. If an "install_dir" element
             is defined, it will be used also to this purpose.
             With this special configuration, the "common" option is forbidden. -->
        <classloader>log-enabled</classloader>

        <!-- Optional. Configures the specific "AUTHENTICATION"
             thread pool, expressly devoted to the calls of Notify User against
             the Remote Metadata Adapter.
             This pool is always created and the
             Notify User calls to Proxy Adapters are performed
             asynchronously, hence they are not supposed to keep threads engaged.
             In order to keep track of the pending asynchronous requests,
             they are counted in the global statistics as part of the pool
             task queue (but not as contributing to the pool queue wait).

             By default, the pool has one fixed thread. If this block
             is defined, its <max_size> and <max_free> subelements, with meaning
             similar to that of the global <server_pool_max_size> and
             <server_pool_max_free> settings, are optional, both with default 1.
             In fact, it is not expected that more than one thread will ever be
             needed, since the pool's only task is to forward the Notify User
             requests.
             On the other hand, configuring the pool is recommended, to constrain
             the maximum number of pending requests to the Remote Metadata Adapter
             through the optional <max_pending_remote_requests> subelement
             (if set <= 0, it poses no limitation; this is also the default).
             The optional <max_queue> subelement is also available, with meaning
             similar to the global <server_pool_max_queue>. If defined,
             the length of the queue of this pool, instead of being added to the
             length checked by <server_pool_max_queue>, will be checked against
             this limit , but with the same consequent backpressure actions. -->
        <!--
        <authentication_pool>
            <max_size>1</max_size>
            <max_free>1</max_free>
            <max_pending_remote_requests>100</max_pending_remote_requests>
            <max_queue>100</max_queue>
        </authentication_pool>
        -->

        <!-- Optional. Configures the specific "MSG" thread pool,
             expressly devoted to the calls of Notify User Message, which
             handle messages sent by the client, against the Remote Metadata Adapter.
             This pool is always created and the
             Notify User Message calls to Proxy Adapters are performed
             asynchronously, hence they are not supposed to keep threads engaged.
             In order to keep track of the pending asynchronous requests,
             they are counted in the global statistics as part of the pool
             task queue (but not as contributing to the pool queue wait).

             By default, the pool has one fixed thread. If this block
             is defined, its <max_size> and <max_free> subelements, with meaning
             similar to that of the global <server_pool_max_size> and
             <server_pool_max_free> settings, are optional, both with default 1.
             In fact, it is not expected that more than one thread will ever be
             needed, since the pool's only task is to forward the Notify User
             requests.
             On the other hand, configuring the pool is recommended, to constrain
             the maximum number of pending requests to the Remote Metadata Adapter
             through the optional <max_pending_remote_requests> subelement
             (if set <= 0, it poses no limitation; this is also the default).
             The optional <max_queue> subelement is also available, with meaning
             similar to the global <server_pool_max_queue>. If defined,
             the length of the queue of this pool, instead of being added to the
             length checked by <server_pool_max_queue>, will be checked against
             this limit , but with the same consequent backpressure actions. -->
        <!--
        <messages_pool>
            <max_size>1</max_size>
            <max_free>1</max_free>
            <max_pending_remote_requests>100</max_pending_remote_requests>
            <max_queue>100</max_queue>
        </messages_pool>
        -->

        <!-- Optional. Requests the creation of a specific "MPN REQUESTS" thread
             pool, devoted to the submission to the Remote Metadata Adapter
             of all the mobile push notification requests pertaining to sessions
             based on this Adapter Set.

             If not defined, these calls are managed by the thread pool related
             with the Adapter Set, if, in turn, defined.
             If defined, the <max_size> and <max_free> elements are mandatory,
             with meaning similar to that of the global <server_pool_max_size>
             and <server_pool_max_free> settings. Note that <max_size> also
             indicates the maximum number of pending requests to the Remote
             Metadata Adapter.
             Using a specific thread pool is advisable if the implementation
             of MPN operations (like Notify MPN Subscription Activation etc.)
             may introduce delays. -->
        <!--
        <mpn_pool>
            <max_size>100</max_size>
            <max_free>10</max_free>
        </mpn_pool>
        -->

        <!-- Optional. If "Y", ensures that all Table (i.e. Subscription)
             notifications (that is, all the invocations to the Notify New Tables
             and Notify Tables Close methods) pertaining to the same session will
             be sequential, with no overlapping; if "N", then concurrent
             invocations will be possible.
             Note that the final invocation to Notify Session Close is always
             guaranteed to occur after all the above notifications have terminated.

             If not defined, the default value is "N" (i.e. do not sequentialize). -->
        <!--
        <sequentialize_table_notifications>Y</sequentialize_table_notifications>
        -->

        <!-- List of initialization parameters specific to the Robust Proxy Metadata Adapter. -->

        <!-- Mandatory for all Proxy Metadata Adapters.
             The request/reply port to listen on. The connection on this port will
             carry the requests/replies channels. -->
        <param name="request_reply_port">6663</param>

        <!-- Optional for all Proxy Metadata Adapters.
             If set, inverts the normal connection establishment behavior, by having
             the Proxy Adapter open a client socket on the configured request/reply
             port towards the Remote Adapter, using the host address specified here.
             This is not the preferred setting but it can be useful in some scenarios.
             See a discussion in the Adapter Remoting Infrastructure architecture
             document. Obviously, the setting requires a corresponding behavior
             by the Remote Server.
             When this setting is leveraged, most of the other elements and parameters
             are still valid (in particular, the "tls" parameter), although some of their
             descriptions refer to the listening port case and should be reinterpreted;
             only the following ones are ignored:
             - interface
             - tls.enforce_server_cipher_suite_preference
             - tls.enforce_server_cipher_suite_preference.order
             - tls.force_client_auth
             - remote_address_whitelist
             Note, in particular, that the keystore parameters are available, though
             optional. This allows for authentication of the Proxy Adapter by the
             Remote Server by requesting the Proxy Adapter's TLS client certificate. -->
        <!--
        <param name="remote_host">my.host.name</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             The local network interface to bind to.
             If not specified, it will bind to any available interface. -->
        <!--
        <param name="interface">192.168.1.1</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             If Y, enforces TLS on the listening port.
             The configuration of the port is done in a way similar
             to the TLS configuration in the Server's <https_server> blocks.
             See the available parameters below and find their meanings in the
             corresponding configuration elements in the Server configuration file.

             Note that the parameters with multiple values should be distinguished
             from one another by adding a dot-suffix
             (see for instance "tls.remove_cipher_suites" below).
             The choice of the suffix is free; however, if "config" is specified in
             "tls.enforce_server_cipher_suite_preference.order", then only numeric
             suffixes (not necessarily consecutive) will be accepted
             for "tls.allow_cipher_suite", to express the ordering.

             If N, the port configuration parameters below are ignored.
             Default: N. -->
        <!--
        <param name="tls">Y</param>
        -->

        <!--
        <param name="tls.keystore.type">JKS</param>
        -->
        <!--
        <param name="tls.keystore.keystore_file">../../conf/myserver.keystore</param>
        -->
        <!--
        <param name="tls.keystore.keystore_password.type">file</param>
        -->
        <!--
        <param name="tls.keystore.keystore_password">../../conf/myserver.keypass</param>
        -->
        <!--
        <param name="tls.allow_cipher_suite.1">TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384</param>
        -->
        <!--
        <param name="tls.allow_cipher_suite.2">........</param>
        -->
        <!--
        <param name="tls.allow_cipher_suite.3">........</param>
        -->
        <param name="tls.remove_cipher_suites.1">_DHE_</param>
        <!--
        <param name="tls.remove_cipher_suites.2">TLS_RSA_</param>
        -->
        <param name="tls.enforce_server_cipher_suite_preference">Y</param>
        <param name="tls.enforce_server_cipher_suite_preference.order">JVM</param>
        <param name="tls.allow_protocol.1">TLSv1.2</param>
        <!--
        <param name="tls.allow_protocol.2">TLSv1.1</param>
        -->
        <!--
        <param name="tls.allow_protocol.3">TLSv1.3</param>
        -->
        <!--
        <param name="tls.remove_protocols.1">TLSv1$</param>
        -->
        <!--
        <param name="tls.remove_protocols.2">TLSv1.1</param>
        -->
        <!--
        <param name="tls.force_client_auth">Y</param>
        -->
        <!--
        <param name="tls.truststore.type">JKS</param>
        -->
        <!--
        <param name="tls.truststore.truststore_file">../../conf/myserver.truststore</param>
        -->
        <!--
        <param name="tls.truststore.truststore_password.type">file</param>
        -->
        <!--
        <param name="tls.truststore.truststore_password">../../conf/myserver.trustpass</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             Only used if "remote_host" is configured and "tls" is Y.
             If Y, suppresses the check of the hostname in the TLS certificate,
             which, in this context, is received from the Remote Server.
             The setting is only meant to be used in a development/test scenario.
             Default: N. -->
        <!--
        <param name="tls.skip_hostname_check">N</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             If Y, enforces Remote Adapter authentication on the connection
             based on a user/password credential check.
             Note that the user names will be used in log messages at INFO level
             or above, whereas the passwords won't.
             The configuration of the accepted credentials is shown below.
             Note that the various credential pairs should be distinguished
             from one another by adding a free dot-suffix to the base
             auth.credentials part.
             If N, the credential configuration parameters below are ignored.
             Default: N. -->
        <!--
        <param name="auth">Y</param>
        -->

        <!--
        <param name="auth.credentials.1.user">user1</param>
        -->
        <!--
        <param name="auth.credentials.1.password">pwd1</param>
        -->
        <!--
        <param name="auth.credentials.2.user">user2</param>
        -->
        <!--
        <param name="auth.credentials.2.password">pwd2</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             Only used if "remote_host" is configured. Delay to be enforced
             before retrying a connection attempt to the Remote Server,
             to prevent a possible strict loop of unsuccessful attempts.
             Default: 10000. -->
        <!--
        <param name="connection_retry_millis">1000</param>
        -->

        <!-- Optional.
             The timeout for initialization errors. After an unsuccessful attempt
             to achieve a connection from a remote server due to an error
             in configuration, network access or initialization, the Proxy Adapter
             will be allowed to retry listening for connections only after ensuring
             that at least this time has elapsed since the previous attempt.
             A negative value prevents further attempts, so that no remote server
             will be available.
             Default: -1. -->
        <param name="connection_recovery_timeout_millis">10000</param>

        <!-- Optional.
             The timeout for the first connection attempt. Upon the Proxy Adapter
             initialization at Lightstreamer Server startup, if a remote server
             is not available, Lightstreamer Server startup can be delayed until
             this timeout expires.
             A negative value stands for an unlimited timeout.
             Note that, when Lightstreamer Server startup completes,
             as long as a connection to a remote server is still missing,
             all client requests will be refused.
             Default: -1. -->
        <param name="first_connection_timeout_millis">10000</param>

        <!-- Optional.
             The strategy to be adopted whenever a new remote server is available
             in order to resend the state change notifications that could not
             or might not have been sent to the previous remote server.
             This involves the notifications of session closing and the optional
             notifications of table closing.
             Note that the Proxy Adapter has no way of knowing exactly if a
             notification has been processed by a remote server if no answer
             had been received at the time the connection was closed. Also
             Consider that the answers from the remote server are not expected
             to come in the same sequence as the requests.
             Hence, no perfect recovery is possible and the remote server must
             be able to deal with an imperfect notification sequence.
             Currently, the only available options are:

             - pessimistic
               All notifications since the first one that could not or may not
               have been processed by the previous remote server are resent
               to the new one.
               This ensures that all notifications are processed at least once,
               but may cause some notifications to be issued for a second time.
               Even notifications that did get an answer could be resent,
               in order to preserve the original sequence.
               Note that timed out requests (see the "timeout" setting) are
               considered as processed.

             - optimistic
               Only notifications after the last one that got an answer by the
               previous remote server are resent to the new one.

             - unneeded
               No notifications are resent. In case the close notifications
               are ignored by the remote server implementation, this can save
               a possibly long playback of unneeded messages.
               Note that table notifications, for both opening and closing, are
               already omitted, unless requested by the remote server through
               the wantsTablesNotification method.

             Default: pessimistic. -->
        <param name="close_notifications_recovery">unneeded</param>

        <!-- Optional.
             The action to be performed when the authentication of the request
             for a new Session (through notifyUser) cannot be carried out
             because of the unavailability of the Remote Metadata Adapter.
             Can be one of the following:

             - fail
               The request will fail as though an unexpected error had been
               occurred.

             - force_retry
               The request will fail, but the server should also instruct
               the client to retry the request.

             - send_code
               The request will be refused by throwing a CreditsException
               with a custom error code that has to be specified through the
               "notify_user_disconnection_code" parameter; in this way,
               the code will be communicated to the client as a Metadata Adapter
               custom refusal code.

             Default: either send_code or fail, depending on whether or not
             the "notify_user_disconnection_code" parameter is supplied. -->
        <!--
        <param name="notify_user_on_disconnection">force_retry</param>
        -->

        <!-- Optional when "notify_user_on_disconnection" is not supplied;
             mandatory when "notify_user_on_disconnection" is send_code;
             otherwise forbidden.
             An integer to be supplied as a custom error code by notifyUser,
             through a CreditsException, when the request is being refused
             because of the unavailability of the Remote Metadata Adapter.
             The code must be zero or negative, as positive codes are reserved
             by the Server.
             Default: no code will be used, hence "notify_user_on_disconnection"
             will be set as fail. -->
        <param name="notify_user_disconnection_code">-10</param>

        <!-- Optional, only effective when "notify_user_disconnection_code" is set.
             A string to be supplied as a custom error message by notifyUser,
             through a CreditsException, when the request is being refused
             because of the unavailability of the Remote Metadata Adapter.
             The message will be used in association with the error code
             configured through "notify_user_disconnection_code".
             Default: the error message is supplied by the
             Robust Proxy Metadata Adapter. -->
        <param name="notify_user_disconnection_msg">Remote Metadata Adapter unavailable</param>

        <!-- Optional for all Proxy Metadata Adapters.
             Name of the Proxy Metadata Adapter, to better identify its connections
             and threads when assessing problems.
             If not specified, the Adapter Set id,
             as configured in this file, will be used. -->
        <!--
        <param name="name">MyFeedMetadata</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters, extended by the Robust
             Proxy Metadata Adapter.
             Determines the custom initialization parameters to be sent to the
             remote counterpart.
             The supplied value is meant as a prefix, such that all parameters
             supplied to this Proxy Adapter and whose names start with this
             prefix will be sent. The value must contain a ':' character, as all
             parameter names that don't contain a ':' character are reserved.
             Hence, the normal configuration parameters will not be sent to the
             remote counterpart, unless explicitly duplicated with a prefixed
             name. Anyway, the following parameters, with obvious meaning,
             will be provided by the Proxy Adapter and will also be sent:
             - ARI.version
             - keepalive_hint.millis (optional)
             - adapters_conf.id
             - server.instance_id
             - proxy.instance_id
             where the latter is added by the Robust Proxy Metadata Adapter
             and allows a Remote Metadata Adapter to detect if it is in
             replacement of a previous instance for the same Proxy Adapter
             instance, and to possibly recover the state, including the currently
             active sessions and the related users.
             Default: if not defined, no custom initialization parameters
             will be sent. -->
        <!--
        <param name="remote_params_prefix">remote:</param>
        -->
        <!--
        <param name="remote:xxxx">my value for the remote counterpart</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             Timeout for sent requests. A negative value stands for an unlimited timeout.
             Timed out requests are considered as failed and later answers are ignored.
             Default: 10000 ms (10 seconds). -->
        <!--
        <param name="timeout">10000</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             If set to false, suppresses clearing of the cached profile data
             for a user when no sessions for the user are active. This is only for
             troubleshooting purpose, as profile data are always refreshed upon
             Notify User requests.
             Default: true. -->
        <!--
        <param name="clear_on_session_close">true</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             Sets the minimum time (in milliseconds) cached profile data are kept;
             these cached data are needed in order to manage request processing before a session
             is fully started. Ignored if clear_on_session_close is false.
             Default: 10000 ms (10 seconds). -->
        <!--
        <param name="user_data_timeout">1000</param>
        -->

        <!-- Optional.
             If set to true, enforces the clearing of all internal caches when a new
             Remote Metadata Adapter instance is connected after the disconnection
             of the previous instance. In fact, some requests to the Remote Adapter
             can be used to fulfill multiple subsequent requests from the Server,
             hence their responses are cached for a few seconds. However, for requests
             whose responses are not supposed to change with time, the cached responses
             are kept longet, so as to be also used to save further identical requests
             to the Remote counterpart.
             By setting true, responses obtained from a previous instance will never
             be used to save requests to the new instance.
             Default: false. -->
        <!--
        <param name="clear_on_new_remote">true</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             Specifies a comma-separated list of hosts allowed to connect to this proxy adapter
             in order to act as remote adapters.
             If a list is specified, connections received from addresses not in the list will be
             turned down, otherwise any connection will be accepted.
             The addresses can be in any form accepted by Java InetAddress.getByName method. -->
        <!--
        <param name="remote_address_whitelist">localhost,192.168.0.190</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             Timeout for inactivity on the connection with respect to messages coming
             from the Remote Metadata Adapter.
             If neither replies nor keepalives are received within the specified
             timeout, the TCP connection will be considered broken and will be closed;
             as a consequence, a connection with a new Remote Metadata Adapter will be attempted.
             Setting a timeout is only meaningful if the Remote Metadata Adapter
             is configured to either send keepalive messages at a shorter interval, or obey
             the keepalive interval requested by this Proxy (see "keepalive_hint_millis").
             A zero or negative value stands for an unlimited timeout.
             Default: -1 (unlimited timeout). -->
        <!--
        <param name="keepalive_timeout_millis">10000</param>
        -->

        <!-- Optional for all Proxy Metadata Adapters.
             Keepalive interval to be requested to the Remote Metadata Adapter.
             The value should be low enough to ensure that, if obeyed, the connection
             will pass the timeout checks (see "keepalive_timeout_millis").
             A zero or negative value stands for no keepalive request, which still allows
             the Remote Metadata Adapter to send keepalives for its own purpose.
             Default: Depending on the setting of keepalive_timeout_millis:
             - if not configured: -1
             - if less than 4 seconds: half the keepalive_timeout_millis
             - otherwise: 2 seconds less than the keepalive_timeout_millis. -->
        <!--
        <param name="keepalive_hint_millis">6000</param>
        -->

    </metadata_provider>


    <!-- Mandatory and cumulative. The Data Adapter is the Java Proxy Adapter.
         The "name" attribute is optional and the default name is "DEFAULT";
         if multiple Data Adapters are defined in the same Adapter Set,
         then using the "name" attribute is needed to distinguish them. -->
    <data_provider name="MY_REMOTE">

        <!-- Optional. Specify a directory other than "."
             for this Adapter's configuration files (e.g. the keystore). -->
        <install_dir>myadapter_one</install_dir>

        <!-- Mandatory. Java class name of the Robust Proxy Data Adapter.
             In this case, "ROBUST_PROXY_FOR_REMOTE_ADAPTER" is a special keyword that
             identifies the Robust Proxy Data Adapter, which is embedded
             in Lightstreamer Server and available out of the box.
             The Robust Proxy Data Adapter communicates with its remote counterpart
             through standard TCP sockets. It listens on a configurable port
             (or, optionally, two ports) and waits for its counterpart to connect.
             Moreover, this Data Adapter manages the case in which the remote
             counterpart is missing, by accepting subscriptions and sending empty
             snapshots to the clients, when requested (note that the clients
             should be able to manage null field values for items subscribed to
             in MERGE mode).
             This Data Adapter also manages failures of the remote counterpart,
             by waiting for connection from a new Remote Server, then trying
             to recover the data flow by resubmitting all the pending subscription
             requests. However, if the remote counterpart needs to retrieve and
             restore the state of the previously connected instance, this will be
             its own burden; for how to identify the involved Server instance,
             see "remote_params_prefix" below. -->
        <adapter_class>ROBUST_PROXY_FOR_REMOTE_ADAPTER</adapter_class>

        <!-- Mandatory for Proxy Adapters. Determines the ClassLoader to be used
             to load the Adapter related classes (see the base template).
             In case a Proxy Adapter is configured, it is advisable to use the
             special "log-enabled" option, to let the Proxy Adapter share the
             logging support and configuration with the Server.
             If set to "dedicated", logging support must be explicitly provided,
             by adding the slf4j library, together with a suitable log
             implementation and configuration. If an "install_dir" element
             is defined, it will be used also to this purpose.
             With this special configuration, the "common" option is forbidden. -->
        <classloader>log-enabled</classloader>

        <!-- Optional. Requests the creation of a specific "DATA" thread pool,
             expressly devoted to the submission to the Remote Data Adapter
             of table subscription and unsubscription requests for all the tables
             based on this Data Adapter.
             This involves the calls of Subscribe and Unsubscribe to the Remote
             Data Adapter and the calls of Get Items, Get Schema, Get Item Data,
             Get User Item Data, Notify New Tables, and the MPN-related methods
             to the Remote Metadata Adapter.

             If not defined, these requests are managed by the thread pool
             related with the Adapter Set, if, in turn, defined.
             If defined, the <max_size> and <max_free> elements are mandatory,
             with meaning similar to that of the global <server_pool_max_size>
             and <server_pool_max_free> settings. Note that <max_size> also
             indicates the maximum number of pending requests to the Remote
             Adapters.
             Using a specific thread pool is advisable if the implementation
             of any of the involved Adapter methods introduces delays. -->
        <!--
        <data_adapter_pool>
            <max_size>100</max_size>
            <max_free>10</max_free>
        </data_adapter_pool>
        -->

        <!-- List of initialization parameters specific to the Robust Proxy Data Adapter. -->

        <!-- Mandatory for all Proxy Data Adapters.
             The request/reply port to listen on. The connection on this port will
             carry the requests/replies channels.
             However, in case the configuration of "notify_port" has to be
             leveraged, the connection will only carry the pure-replies subpart
             of the replies channel. -->
        <param name="request_reply_port">6661</param>

        <!-- Optional for all Proxy Data Adapters.
             The notification port to listen on. If leveraged, a two-connections
             behavior will be adopted and the connection on this second port
             will be used, unidirectionally, to carry the notifications
             subpart of the replies channel, whereas the request/reply port will
             only carry the pure-replies subpart.
             The two-ports configuration is only available to ensure backward
             compatibility with old Remote Servers, which were based on
             on a two-connections behavior for Remote Data Adapters.
             On the other hand, Remote Servers based on most recent SDK versions
             may even no longer support the two-connections behavior.
             Hence, the choice of a two-ports configuration should match
             the Remote Server behavior. Note that there is no automatic
             detection of how the Remote Server behaves. -->
        <!--
        <param name="notify_port">6662</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             If set, inverts the normal connection establishment behavior, by having
             the Proxy Adapter open a client socket on the configured request/reply
             port towards the Remote Adapter, using the host address specified here.
             This setting is not compatible with the setting of "notify_port".
             This is not the preferred setting but it can be useful in some scenarios.
             See a discussion in the Adapter Remoting Infrastructure architecture
             document. Obviously, the setting requires a corresponding behavior
             by the Remote Server.
             When this setting is leveraged, most of the other elements and parameters
             are still valid (in particular, the "tls" parameter), although some of their
             descriptions refer to the listening port case and should be reinterpreted;
             only the following ones are ignored:
             - interface
             - tls.enforce_server_cipher_suite_preference
             - tls.enforce_server_cipher_suite_preference.order
             - tls.force_client_auth
             - remote_address_whitelist
             Note, in particular, that the keystore parameters are available, though
             optional. This allows for authentication of the Proxy Adapter by the
             Remote Server by requesting the Proxy Adapter's TLS client certificate. -->
        <!--
        <param name="remote_host">my.host.name</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             The local network interface to bind to.
             If not specified, it will bind to any available interface. -->
        <!--
        <param name="interface">192.168.1.1</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             If Y, enforces TLS on the listening port.
             The configuration of the port is done in a way similar
             to the TLS configuration in the Server's <https_server> blocks.
             In case of two-ports configuration, the TLS configuration applies
             the same for both ports.
             See the available parameters below and find their meanings in the
             corresponding configuration elements in the Server configuration file.

             Note that the parameters with multiple values should be distinguished
             from one another by adding a dot-suffix
             (see for instance "tls.remove_cipher_suites" below).
             The choice of the suffix is free; however, if "config" is specified in
             "tls.enforce_server_cipher_suite_preference.order", then only numeric
             suffixes (not necessarily consecutive) will be accepted
             for "tls.allow_cipher_suite", to express the ordering.

             If N, the port configuration parameters below are ignored.
             Default: N. -->
        <!--
        <param name="tls">Y</param>
        -->

        <!--
        <param name="tls.keystore.type">JKS</param>
        -->
        <!--
        <param name="tls.keystore.keystore_file">../../conf/myserver.keystore</param>
        -->
        <!--
        <param name="tls.keystore.keystore_password.type">file</param>
        -->
        <!--
        <param name="tls.keystore.keystore_password">../../conf/myserver.keypass</param>
        -->
        <!--
        <param name="tls.allow_cipher_suite.1">TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384</param>
        -->
        <!--
        <param name="tls.allow_cipher_suite.2">........</param>
        -->
        <!--
        <param name="tls.allow_cipher_suite.3">........</param>
        -->
        <param name="tls.remove_cipher_suites.1">_DHE_</param>
        <!--
        <param name="tls.remove_cipher_suites.2">TLS_RSA_</param>
        -->
        <param name="tls.enforce_server_cipher_suite_preference">Y</param>
        <param name="tls.enforce_server_cipher_suite_preference.order">JVM</param>
        <param name="tls.allow_protocol.1">TLSv1.2</param>
        <!--
        <param name="tls.allow_protocol.2">TLSv1.1</param>
        -->
        <!--
        <param name="tls.allow_protocol.3">TLSv1.3</param>
        -->
        <!--
        <param name="tls.remove_protocols.1">TLSv1$</param>
        -->
        <!--
        <param name="tls.remove_protocols.2">TLSv1.1</param>
        -->
        <!--
        <param name="tls.force_client_auth">Y</param>
        -->
        <!--
        <param name="tls.truststore.type">JKS</param>
        -->
        <!--
        <param name="tls.truststore.truststore_file">../../conf/myserver.truststore</param>
        -->
        <!--
        <param name="tls.truststore.truststore_password.type">file</param>
        -->
        <!--
        <param name="tls.truststore.truststore_password">../../conf/myserver.trustpass</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             Only used if "remote_host" is configured and "tls" is Y.
             If Y, suppresses the check of the hostname in the TLS certificate,
             which, in this context, is received from the Remote Server.
             The setting is only meant to be used in a development/test scenario.
             Default: N. -->
        <!--
        <param name="tls.skip_hostname_check">N</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             If Y, enforces Remote Adapter authentication on the connection
             based on a user/password credential check.
             In case of two-ports configuration, the same check is performed
             on both connections.
             Note that the user names will be used in log messages at INFO level
             or above, whereas the passwords won't.
             The configuration of the accepted credentials is shown below.
             Note that the various credential pairs should be distinguished
             from one another by adding a free dot-suffix to the base
             auth.credentials part.
             If N, the credential configuration parameters below are ignored.
             Default: N. -->
        <!--
        <param name="auth">Y</param>
        -->

        <!--
        <param name="auth.credentials.1.user">user1</param>
        -->
        <!--
        <param name="auth.credentials.1.password">pwd1</param>
        -->
        <!--
        <param name="auth.credentials.2.user">user2</param>
        -->
        <!--
        <param name="auth.credentials.2.password">pwd2</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             Only used if "remote_host" is configured. Delay to be enforced
             before retrying a connection attempt to the Remote Server,
             to prevent a possible strict loop of unsuccessful attempts.
             Default: 10000. -->
        <!--
        <param name="connection_retry_millis">1000</param>
        -->

        <!-- Optional.
             The timeout for initialization errors. After an unsuccessful attempt
             to achieve a connection from a remote server due to an error
             in configuration, network access or initialization, the Proxy Adapter
             will be allowed to retry listening for connections only after ensuring
             that at least this time has elapsed since the previous attempt.
             A negative value prevents further attempts, so that no remote server
             will be available.
             Default: -1. -->
        <param name="connection_recovery_timeout_millis">10000</param>

        <!-- Optional.
             The timeout for the first connection attempt. Upon the Proxy Adapter
             initialization at Lightstreamer Server startup, if a remote server
             is not available, Lightstreamer Server startup can be delayed until
             this timeout expires.
             A negative value stands for an unlimited timeout.
             Note that, when Lightstreamer Server startup completes,
             as long as a connection to a remote server is still missing,
             all subscription requests will get an empty snapshot; then, when the
             connection is established, the data flow will be restored according
             to the "events_recovery" setting.
             Default: 0. -->
        <param name="first_connection_timeout_millis">10000</param>

        <!-- Optional.
             The strategy to be adopted whenever a new remote server is available
             in order to restore the data flow for items that were subscribed to
             while no remote server was available.
             No sophisticated recovery algorithms are available, as they could
             only depend on the specific item meanings.
             Currently, the only available options are:

             - leave_hole
               The real time update flow is just restarted; this may give rise
               to an inconsistent overall flow:
               for RAW and DISTINCT subscriptions, there will be a hole in the
               event sequence;
               for MERGE and COMMAND subscriptions, out of date field values
               might be mixed with up to date field values on the same item or key;
               for COMMAND subscriptions, some keys might be missing for some
               time and others might remain garbage for long time; some harmless
               warning messages might also be issued by the Server.

             - use_snapshot
               The snapshot of the item is requested to the remote server and
               it is sent in the update flow "as is"; this strategy is suitable
               for MERGE subscriptions, while in other cases it may give rise
               to an inconsistent overall flow:
               for RAW subscriptions, there will be a hole in the event sequence
               and possible spurious entries;
               for DISTINCT subscriptions, there might be either a hole or some
               duplicates in the event sequence;
               for COMMAND subscriptions, some keys might just remain garbage
               for long time; some harmless warning messages might also be
               issued by the Server.

             - enforce_snapshot
               Upon interruption, a ClearSnapshot event is sent. Then, upon
               reconnection, the snapshot of the item is requested to the remote
               server and it is sent in the update flow as though it was a sequence
               of real-time updates; this strategy successfully restores the
               correct state for MERGE and COMMAND subscriptions, but it must be
               considered that:
               for MERGE subscriptions, the clients will see null values during
               the interruption;
               for RAW subscriptions, there will be a hole in the event sequence
               and possible spurious entries;
               for DISTINCT subscriptions, there might be either a hole or some
               duplicates in the event sequence, but the ClearSnapshot signal may
               act as a warning of the issue;
               for COMMAND subscriptions, the clients will see an empty list
               during the interruption, then the fictitious ADDs to restore the
               list, but the ClearSnapshot signal may act as a warning of the issue.

             The configured strategy will be applied with all items.
             Default: leave_hole. -->
        <param name="events_recovery">use_snapshot</param>

        <!-- Optional.
             Specifies an item name to be managed by the Proxy Adapter for
             carrying information about the availability of the Remote Data Adapter.
             This item will only supply one field, named "status", whose value
             may only be one of the following:
             - "connecting" if no connection with a remote server has taken place yet;
             - "connected" if a connection with a remote server is currently in place;
             - "reconnecting" if a connection with a remote server has been lost.
             The item will support subscriptions in MERGE or RAW mode and requests
             for the snapshot will also be supported.

             Note that the chosen name should be such that no conflicts with the
             item names supplied by the Remote Data Adapter can be possible.
             Also note that the Metadata Adapter must be aware of this item when
             performing permission checks.
             Default: no item is added for carrying status information. -->
        <param name="status_item">remote_adapter_status</param>

        <!-- Optional for all Proxy Data Adapters.
             Timeout that is activated in case of two-ports configuration,
             when the first connection, to either port, has been received.
             If the second connection is not received within this time,
             the first connection is also invalidated.
             A zero or negative value stands for an unlimited timeout.
             Default: -1. -->
        <param name="missing_connection_timeout_millis">10000</param>

        <!-- Optional for all Proxy Data Adapters.
             Name of the Proxy Data Adapter, to better identify its connections
             and threads when assessing problems.
             If not specified, the Adapter Set id and the Data Adapter name,
             as configured in this file, will be used. -->
        <!--
        <param name="name">MyFeedData</param>
        -->

        <!-- Optional for all Proxy Data Adapters, extended by the Robust
             Proxy Data Adapter.
             Determines the custom initialization parameters to be sent to the
             remote counterpart.
             The supplied value is meant as a prefix, such that all parameters
             supplied to this Proxy Adapter and whose names start with this
             prefix will be sent. The value must contain a ':' character, as all
             parameter names that don't contain a ':' character are reserved.
             Hence, the normal configuration parameters will not be sent to the
             remote counterpart, unless explicitly duplicated with a prefixed
             name. Anyway, the following parameters, with obvious meaning,
             will be provided by the Proxy Adapter and will also be sent:
             - ARI.version
             - keepalive_hint.millis (optional)
             - adapters_conf.id
             - data_provider.name
             - server.instance_id
             - proxy.instance_id
             where the latter is added by the Robust Proxy Data Adapter and
             allows a Remote Data Adapter to detect if it is in replacement
             of a previous instance for the same Proxy Adapter instance.
             Default: if not defined, no custom initialization parameters
             will be sent. -->
        <!--
        <param name="remote_params_prefix">remote:</param>
        -->
        <!--
        <param name="remote:xxxx">my value for the remote counterpart</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             Timeout for sent requests. A negative value stands for an unlimited timeout.
             Timed out requests are considered as failed and later answers are ignored.
             Default: 10000 ms (10 seconds). -->
        <!--
        <param name="timeout">10000</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             Specifies a comma-separated list of hosts allowed to connect to this proxy adapter
             in order to act as remote adapters.
             If a list is specified, connections received from addresses not in the list will be
             turned down, otherwise any connection will be accepted.
             The addresses can be in any form accepted by Java InetAddress.getByName method. -->
        <!--
        <param name="remote_address_whitelist">localhost,192.168.0.190</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             Timeout for inactivity on the connection with respect to messages coming
             from the Remote Data Adapter.
             If neither replies/notifications nor keepalives are received within the specified
             timeout, the TCP connection will be considered broken and will be closed;
             as a consequence, a connections with a new Remote Data Adapter will be attempted.
             In case of two-ports configuration, the timeout applies to both connections
             independently.
             Setting a timeout is only meaningful if the Remote Data Adapter
             is configured to either send keepalive messages at a shorter interval, or obey
             the keepalive interval requested by this Proxy (see "keepalive_hint_millis").
             A zero or negative value stands for an unlimited timeout.
             Default: -1 (unlimited timeout). -->
        <!--
        <param name="keepalive_timeout_millis">10000</param>
        -->

        <!-- Optional for all Proxy Data Adapters.
             Keepalive interval to be requested to the Remote Data Adapter.
             The value should be low enough to ensure that, if obeyed, the connections
             will pass the timeout checks (see "keepalive_timeout_millis").
             A zero or negative value stands for no keepalive request, which still allows
             the Remote Data Adapter to send keepalives for its own purpose.
             Default: Depending on the setting of keepalive_timeout_millis:
             - if not configured: -1
             - if less than 4 seconds: half the keepalive_timeout_millis
             - otherwise: 2 seconds less than the keepalive_timeout_millis. -->
        <!--
        <param name="keepalive_hint_millis">6000</param>
        -->

    </data_provider>

</adapters_conf>
