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

<!--
    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.
    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">

    <!-- 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 Proxy Metadata Adapter.
             In this case, "PROXY_FOR_REMOTE_ADAPTER" is a special keyword that
             identifies the Proxy Metadata Adapter, which is embedded
             in Lightstreamer Server and available out of the box.
             The 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. -->
        <adapter_class>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 Proxy Metadata Adapter. -->

        <!-- Mandatory.
             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.
             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.
             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.
             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.
             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.
             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.
             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.
             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.
             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
             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.
             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.
             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.
             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.
             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.
             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, the whole Server will be shut down.
             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.
             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 Proxy Data Adapter.
             In this case, "PROXY_FOR_REMOTE_ADAPTER" is a special keyword that
             identifies the Proxy Data Adapter, which is embedded
             in Lightstreamer Server and available out of the box.
             The 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. -->
        <adapter_class>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 Proxy Data Adapter. -->

        <!-- Mandatory.
             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.
             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.
             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.
             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.
             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.
             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.
             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.
             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.
             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.
             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.
             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
             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.
             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.
             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.
             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, the whole Server will be shut down.
             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.
             Keepalive interval to be requested to the Remote Data 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 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>
