<?xml version="1.0" encoding="UTF-8"?>
<!-- Do not remove this line. File tag: mqtt.cool_configuration-20200318. -->

<mqttcool>

<!--
    The following elements, subelements and attributes are consulted
    by MQTT.Cool to setup its own configuration. Elements with
    an empty or blank value are ignored and considered as not defined at all.
    Elements described as "cumulative" can be inserted multiple times in the
    same place. Note that element and attribute names are handled in a case
    insensitive way.

    A very simple variable-expansion feature is available. Element or attribute
    values of the form $propname are expanded by looking for a corresponding
    JVM property (which, for instance, can be defined by adding
    -Dpropname=propvalue to the Server command line arguments in the launch
    script). If the property is not defined, then the element or attribute
    is considered as not defined at all. Optionally, system environment
    variables can also be referred (see <env_prefix> below).
    Note that the variable-expansion feature is not available for setting
    the value of non-leaf elements.
    If needed, the variable-expansion feature can be disabled for an element
    or for an element's attribute (let's say: attr) by adding prop_prefix=""
    or, respectively, attr_prop_prefix="" to the element (note that these
    "prop_prefix" attributes are handled in a special way). This also allows
    for setting a prefix other than "$".

    All the element or attribute values described as directory or file paths
    can be expressed as absolute or relative pathnames; when relative,
    they are considered as relative to the directory that contains this
    configuration file.
    Note that, on Windows, if a drive name is not specified, a double initial
    slash or backslash is needed to make a path absolute.
-->

<!--
    MQTT.Cool embeds Lightstreamer Server and provides its core logic through a
    custom Java In-Process Lightstreamer Adapter Set, the "MQTT Connector",
    which comes pre-deployed into the distribution package.

    As required by the Lightstreamer's extension mechanisms to build a custom
    server-side component, the "MQTT Connector" comprises:
    - a Metadata Adapter
    - a Data Adapter

    In this configuration file, you will find terms and settings related to
    Adapter Sets and, more in general, the Lightstreamer's domain. For an
    in-depth introduction to Lightstreamer Server, see the General Concepts document
    (available at https://www.lightstreamer.com/docs/base/General%20Concepts.pdf).

    On the contrary, for a deep dive into MQTT.Cool, see
    <MQTT.COOL_HOME>/doc/MQTT.Cool Getting Started Guide.html.
-->

<!--
  =====================
  LICENSE CONFIGURATION
  =====================
-->

    <!-- Mandatory. Path of the configuration file for all licensing and version
         configuration stuff. The file path is relative to the conf directory. -->
    <edition_conf>./edition.xml</edition_conf>

<!--
  =========================
  ENVIRONMENT CONFIGURATION
  =========================
-->

    <!-- Optional. If set, modifies the behavior of the variable-expansion
         feature in this configuration file. It specifies a prefix such that,
         if a $propname value is found and propname starts with this prefix,
         the propname will be searched among the system environment variables
         rather than the JVM properties. -->
    <!--
    <env_prefix>env.</env_prefix>
    -->

<!--
  ===============================
  HTTP/HTTPS SERVER CONFIGURATION
  ===============================
-->

    <!-- Optional and cumulative (but at least one from <http_server> and
         <https_server> should be defined). HTTP server socket configuration.
         Multiple listening sockets can be defined, by specifying multiple
         <http_server> elements. This allows, for instance, the coexistence
         of private and public ports.
         The "name" attribute is mandatory. Note that it is notified to the
         client upon connection and it is made available to application code
         by the Client SDKs through the serverSocketName property in the
         ConnectionDetails class. It must be an ASCII string with no
         control characters. -->
    <http_server name="MQTT.Cool HTTP Server">

        <!-- Mandatory. Listening TCP port. -->
        <port>8080</port>

        <!-- Optional. Size of the system buffer for incoming TCP connections
             (backlog). Overrides the default system setting. -->
        <!--
        <backlog>50</backlog>
        -->

        <!-- Optional. Provides meta-information on how this listening socket
             will be used, according with the deployment configuration.
             This can inform the Server of a restricted set of requests expected
             on the port, which may improve the internal backpressure mechanisms.
             It can be one of the following:
             - CREATE_ONLY
               Declares that the port is only devoted to "S" connections,
               according with the provided Clustering.pdf document.
             - CONTROL_ONLY
               Declares that the port is only devoted to "CR" connections,
               according with the provided Clustering.pdf document.
               The Server will enforce the restriction.
             - PRIORITY
               If set, requests issued to this port will follow a fast track.
               In particular, they will be never enqueued to the SERVER thread
               pool, but only the ACCEPT pool; and they will not be subject to any
               backpressure-related limitation (like <accept_pool_max_queue>).
               This should ensure that the requests will be fulfilled as soon as
               possible, even when the Server is overloaded.
               Such priority port is, therefore, ideal for opening the Monitoring
               Dashboard to inspect overload issues in place.
               Anyway, such port is only meant for internal use and it is
               recommended not to leave it publicly accessible.
             - GENERAL_PURPOSE
               To be set when the port can be used for any kind of request.
               It can always be set in case of doubts.
             Note that ports can be CREATE_ONLY or CONTROL_ONLY only depending
             on client behavior. For clients based on LS SDK libraries, this is
             related to the use of the <control_link_address> setting. Usage
             examples are provided in the Clustering.pdf document.
             Default: GENERAL_PURPOSE. -->
        <!--
        <port_type>PRIORITY</port_type>
        -->

        <!-- Optional. Settings that allow some control over the HTTP headers
             of the provided responses. Header lines can only be added to those
             used by the Server, either by specifying their value or by copying
             them from the request.
             Multiple rules can be defined; their order is ignored.
             In any case of replicated header fields, multiple lines will be
             inserted; it is assumed that multiple occurrences are allowed for
             those fields.
             No syntax and consistency checks are performed on the resulting
             HTTP headers; only custom or non-critical fields should be used.
             The header names involved are always converted to lower case. -->
        <response_http_headers>

            <!-- Optional and cumulative. Requests to look for any header
                 lines for the specified field name on the HTTP request header
                 and to copy them to the HTTP response header.
                 The "name" attribute is mandatory; a final ":" is optional.
                 The value should be left empty. -->
            <!--
            <echo name="cookie" />
            -->
            <!-- Optional and cumulative. Requests to add to the HTTP response
                 header a line with the specified field name and value.
                 The "name" attribute is mandatory; a final ":" is optional.
                 The suggested setting for "X-Accel-Buffering" may help to enable
                 streaming support when proxies of several types are involved. -->
            <add name="X-Accel-Buffering">no</add>
            <!--
            <add name="my-header">MyValue</add>
            -->

        </response_http_headers>

        <!-- Optional. Can be used on a multihomed host to specify the IP address
             to bind the server socket to.
             The default is to accept connections on any/all local addresses. -->
        <!--
        <listening_interface>200.0.0.1</listening_interface>
        -->

        <!-- Optional. Settings that allow for better identifying the remote
             address of the connected clients. This can be done in two ways:
             - by taking advantage of the X-Forwarded-For HTTP header, that
               intermediate HTTP proxies usually set to supply connection
               routing information in an incremental way;
             - by receiving the routed address directly from a TCP reverse proxy
               or load balancer through the Proxy Protocol, when the proxy
               is configured to do so.
             The two techniques can also coexist, but, in that case, the address
             received through the proxy protocol would always be considered as
             the real client address and all addresses in the chain specified
             in X-Forwarded-For would be considered as written by client-side
             proxies.
             The address determined in this way will be used in all cases
             in which the client address is reported or checked. For logging
             purposes, the connection endpoint will still be written, but the
             real remote address, if available and different, will be added.
             The determined address may also be sent to the clients, depending
             on the Client SDK in use.
             The optional "private" attribute (whose default is "N"), if set to
             "Y", prevents the determined address from being sent to the clients.
             In fact, the address is notified to the client upon connection and
             it is made available to application code by the most recent
             Client SDKs through the clientIp property in the ConnectionDetails
             class.
             For instance, the attribute can and should be set to "Y" in case
             the identification of the remote address is not properly tuned
             and the determined address may be a local one.
             If the whole block is omitted, this just means that all settings
             are at their defaults. -->
        <!--
        <client_identification private="N">
        -->

            <!-- Optional. If Y, instructs the Server that the connection endpoint
                 is a reverse proxy or load balancer that sends client address
                 information through the Proxy Protocol. The received address and
                 port will be used as the real client address and port; on the
                 other hand, the reported protocol will always refer to the actual
                 connection.
                 There is no dynamic detection of the proxy protocol; hence, if Y
                 is set, all connections to this port must speak the proxy protocol
                 (for instance, any healthcheck requests should be configured
                 properly on the proxy) and, if N is set, no connection can speak
                 the proxy protocol, otherwise the outcome would be unspecified.
                 On the other hand, if Y, both proxy protocol version 1 and 2 are
                 handled; only information for normal TCP connections is considered.
                 Default: N. -->
            <!--
            <proxy_protocol_enabled>Y</proxy_protocol_enabled>
            -->

            <!-- Optional. Timeout applied while reading for information through
                 the proxy protocol, when enabled. Note that a reverse proxy or
                 load balancer speaking the proxy protocol is bound to send
                 information immediately after connection start; so the timeout
                 can only apply to cases of wrong configuration, local network
                 issues or illegal access to this port.
                 For this reason, the read is performed directly in the ACCEPT
                 thread pool and this setting protects that pool against such
                 unlikely events.
                 Default: 1000. -->
            <!--
            <proxy_protocol_timeout_millis>3000</proxy_protocol_timeout_millis>
            -->

            <!-- Optional, but forbidden if "proxy_protocol_enabled" is Y.
                 Number of entries in the X-Forwarded-For header that are
                 expected to be supplied by the intermediate nodes (e.g. reverse
                 proxies, load balancers) standing in the local environment.
                 If N entries are expected from local nodes, this means that the
                 Nth-nearest entry corresponds to the node connected to the farthest
                 local intermediate node, hence to the client. So, that entry will
                 be used as the real client address.
                 If 0, any information in X-Forwarded-For will be ignored and the
                 connection endpoint address (or information from the proxy protocol,
                 if "proxy_protocol_enabled" is Y) will always be used.
                 Note that a similar correction for port and protocol is not applied;
                 hence, when an address corrected through a nonzero setting is
                 reported, any port and protocol associated will still refer to the
                 actual connection.
                 Default: 0. -->
            <!--
            <skip_local_forwards>2</skip_local_forwards>
            -->

            <!-- Optional. If Y, causes the list of entries of the X-Forwarded-For
                 header, when available, to be added to log lines related to the
                 client activity. If "skip_local_forwards" is nonzero, only the
                 entries farther than the determined "real" remote address are
                 included.
                 These entries are expected to be written by client-side proxies.
                 Default: N. -->
            <!--
            <log_forwards>Y</log_forwards>
            -->

        <!--
        </client_identification>
        -->

    </http_server>

    <!-- Optional and cumulative (but at least one from <http_server> and
         <https_server> should be defined). HTTPS server socket configuration.
         Multiple listening sockets can be defined, by specifying multiple
         <https_server> elements. This allows, for instance, the coexistence
         of private and public ports.
         This also allows the use of multiple addresses for accessing the
         Server via TLS/SSL, because different HTTPS sockets can use
         different keystores. In particular, this is the case when the Server
         is behind a load balancer and Lightstreamer "control link" technique
         is used to ensure that all Requests issued by the same client are
         dispatched to the same Server instance.
         The "name" attribute is mandatory. Note that it is notified to the
         client upon connection and it is made available to application code
         by the Client SDKs through the serverSocketName property in the
         ConnectionDetails class. It must be an ASCII string with no
         control characters. -->
    <!--
    <https_server name="MQTT.Cool HTTPS Server">
    -->

        <!-- Mandatory. Listening TCP port. -->
        <!--
        <port>443</port>
        -->

        <!-- Optional. Size of the system buffer for incoming TCP connections
             (backlog). Overrides the default system setting. -->
        <!--
        <backlog>50</backlog>
        -->

        <!-- Optional. Provides meta-information on how this listening socket
             will be used, according with the deployment configuration.
             See the same element inside <http_server> for a description.
             In addition, when set to "PRIORITY" on a HTTPS listening socket,
             TLS-handshake-related tasks will not be enqueued to the
             TLS-SSL HANDSHAKE or TLS-SSL AUTHENTICATION thread pool,
             but only to a dedicated pool.
             Default: GENERAL_PURPOSE. -->
        <!--
        <port_type>PRIORITY</port_type>
        -->

        <!-- Optional. Settings that allow some control over the HTTP headers
             of the provided responses. See the same element inside
             <http_server> for a description. -->
        <response_http_headers>
             <!--
             <echo name="cookie" />
             -->
             <!--
             <add name="my-header">MyValue</add>
             -->
             <add name="X-Accel-Buffering">no</add>
        </response_http_headers>

        <!-- Optional. Can be used on a multihomed host to specify the IP address
             to bind the server socket to.
             The default is to accept connections on any/all local addresses. -->
        <!--
        <listening_interface>200.0.0.1</listening_interface>
        -->

        <!-- Optional. Settings that allow for better identifying the remote address
             of the connected clients. See the same element inside
             <http_server> for a description. -->
        <!--
        <client_identification private="N">
            <proxy_protocol_enabled>Y</proxy_protocol_enabled>
            <proxy_protocol_timeout_millis>3000</proxy_protocol_timeout_millis>
            <skip_local_forwards>2</skip_local_forwards>
            <log_forwards>Y</log_forwards>
        </client_identification>
        -->

        <!-- Mandatory. Reference to the keystore used by the HTTPS service.
             The keystore type should be specified in the optional "type"
             attribute; the currently supported types are:
             - JKS, which is the Sun/Oracle's custom keystore type, whose
               support is made available by every Java installation;
             - PKCS12, which is supported by all recent Java installations;
             - PKCS11, which as a bridge to an external PKCS11 implementation;
               this is an experimental extension; contact Lightstreamer
               Support for details.
             The default value is JKS.
             With a JKS or PKCS12 keystore, the <keystore_file> and <keystore_password>
             subelements are mandatory. The access to the included certificates
             is subject to the following constraints:
             - only the first certificate found in the keystore can be sent
               to the Client;
             - the password of the keystore and the password of the included
               certificate should be the same (hence, the <keystore_password>
               subelement refers to both).
             Instructions on how to setup a JKS keystore are provided in the
             SSL Certificates document. -->
        <!--
        <keystore type="JKS">
        -->

            <!-- Specifies a path relative to the conf directory.
                 The referred file can be replaced at runtime and the new keystore
                 will be loaded immediately. Only in case of successful load
                 will the previous keystore be replaced.
                 NOTE: The JKS keystore "myserver.keystore", which is provided out
                 of the box, obviously contains an invalid certificate. In order to
                 use it for your experiments, remember to add a security exception
                 to your browser. -->
            <!--
            <keystore_file>./myserver.keystore</keystore_file>
            -->

            <!-- Specified the password for the keystore. The factory setting below
                 refers to the test keystore "myserver.keystore", provided out of the box.
                 The optional "type" attribute, whose default is "text", when set
                 to "file", allows you to supply the path, relative to the conf
                 directory, of a file containing the password. Note that the password
                 has to be stored in clear, but the file could be protected from
                 external access.
                 In case the keystore file is replaced, a password of "file" type
                 will be reread as well. This is the only way to supply a new
                 password, if needed. Note that the password file should be modified
                 before the keystore file. -->
            <!--
            <keystore_password type="file">./myserver.keypass</keystore_password>
            -->

        <!--
        </keystore>
        -->

        <!-- Optional and cumulative, but forbidden if <remove_cipher_suites> is used.
             Specifies all the cipher suites allowed for the TLS/SSL interaction,
             provided that they are included, with the specified name, in the set
             of "supported" cipher suites of the underlying JVM implementation.
             The default set of the "supported" cipher suites is logged at startup
             by the LightstreamerLogger.connections.ssl logger at DEBUG level.
             If not used, the <remove_cipher_suites> element is considered; hence, if
             <remove_cipher_suites> is also not used, all cipher suites enabled by
             the JVM settings will be available.
             The order in which the cipher suites are specified can be enforced as the
             server-side preference order (see <enforce_server_cipher_suite_preference>). -->
        <!--
        <allow_cipher_suite>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384</allow_cipher_suite>
        -->
        <!--
        <allow_cipher_suite>........</allow_cipher_suite>
        -->
        <!--
        <allow_cipher_suite>........</allow_cipher_suite>
        -->

        <!-- Optional and cumulative, but forbidden if <allow_cipher_suite> is used.
             Pattern to be matched against the names of the enabled cipher suites
             in order to remove the matching ones from the enabled cipher suites set.
             Any pattern in java.util.regex.Pattern format can be specified.
             This allows for customization of the choice of the cipher suite
             to be used for an incoming https connection (note that reducing
             the set of available cipher suites may cause some client requests
             to be refused).
             When this setting is used, the server-side preference order of the
             cipher suites is determined by the underlying JVM implementation.
             Note that the selection is operated on the default set of the
             cipher suites "enabled" by the JVM settings, not on the wider set of
             the "supported" cipher suites. The default set of the "enabled" cipher
             suites is logged at startup by the LightstreamerLogger.connections.ssl
             logger at DEBUG level. -->
        <remove_cipher_suites>_DHE_</remove_cipher_suites>
        <!--
        <remove_cipher_suites>TLS_RSA_</remove_cipher_suites>
        -->

        <!-- Optional. Determines which side should express the preference when
             multiple cipher suites are in common between server and client.
             Can be one of the following:
             - Y: The Server will choose the cipher suite based on its own preference
                  order. This is determined by the optional "order" attribute:
                  - if "JVM" (which is the default), the ordering is demanded
                    to the underlying JVM implementation, which, usually,
                    privileges the strongest suites;
                  - if "config" (which is allowed only if <allow_cipher_suite>
                    is used), the order in which the <allow_cipher_suite>
                    elements are specified determines the preference order.
             - N: The Server will get a cipher suite based on the preference order
                  specified by the client. For instance, the client might privilege
                  faster, but weaker, suites.
             Default: N. -->
        <enforce_server_cipher_suite_preference order="JVM">Y</enforce_server_cipher_suite_preference>

        <!-- Optional. If Y, causes any client-initiated TLS renegotiation request
             to be refused by closing the connection. This policy may be evaluated
             in a trade-off between encryption strength and performance risks.
             Note that a better way to achieve that at a global level is to set
             a dedicated JVM property (which is supported by most JVMs); just edit
             the launch script and add the following to the JVM command line:
             "-Djdk.tls.rejectClientInitiatedRenegotiation=true"
             Default: N. -->
        <!--
        <disable_TLS_renegotiation>Y</disable_TLS_renegotiation>
        -->

        <!-- Optional and cumulative, but forbidden if <remove_protocols> is used.
             Specifies one or more protocols allowed for the TLS/SSL interaction,
             among the ones supported by the underlying JVM implementation.
             For Oracle JVMs, the available names are the "SSLContext Algorithms"
             listed here:
             http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
             If not used, the <remove_protocols> element is considered; hence, if
             <remove_protocols> is also not used, all protocols enabled by the JVM
             settings will be available. -->
        <allow_protocol>TLSv1.2</allow_protocol>
        <!--
        <allow_protocol>TLSv1.1</allow_protocol>
        -->
        <!--
        <allow_protocol>TLSv1.3</allow_protocol>
        -->

        <!-- Optional and cumulative, but forbidden if <allow_protocol> is used.
             Pattern to be matched against the names of the enabled TLS/SSL protocols
             in order to remove the matching ones from the enabled protocols set.
             Any pattern in java.util.regex.Pattern format can be specified.
             This allows for customization of the choice of the TLS/SSL protocols
             to be used for an incoming https connection (note that reducing
             the set of available protocols may cause some client requests
             to be refused).
             Note that the selection is operated on the default set of the
             protocols "enabled" by the JVM settings, not on the wider set of
             the "supported" protocols. The default set of the "enabled" protocols
             is logged at startup by the LightstreamerLogger.connections.ssl
             logger at DEBUG level. -->
        <!--
        <remove_protocols>TLSv1$</remove_protocols>
        -->
        <!--
        <remove_protocols>TLSv1.1</remove_protocols>
        -->

        <!-- Optional. If Y, tries to improve the TLS session resumption feature
             by providing the underlying security provider with information on
             the client IPs and ports. This makes sense only if client IPs can be
             determined (see the <client_identification> block).
             Default: N. -->
        <!--
        <use_client_hints_for_TLS_session_resumption>Y</use_client_hints_for_TLS_session_resumption>
        -->

        <!-- Optional. Request to provide the Metadata Adapter with the
             "principal" included in the client TLS/SSL certificate, when available.
             Can be one of the following:
             - Y: Upon each client connection, the availability of a client TLS/SSL
                  certificate is checked. If available, the included
                  identification data will be supplied upon calls to notifyUser.
             - N: No certificate information is supplied to notifyUser and no
                  check is done on the client certificate.
             Note that a check on the client certificate can also be requested
             through <force_client_auth>.
             Default: N. -->
        <!--
        <use_client_auth>Y</use_client_auth>
        -->

        <!-- Optional. Request to only allow clients provided with a valid TLS/SSL
             certificate. Can be one of the following:
             - Y: Upon each client connection, a valid TLS/SSL certificate is
                  requested to the client in order to accept the connection.
             - N: No check is done on the client certificate.
             Note that a certificate can also be requested to the client as a
             consequence of <use_client_auth>.
             Default: N. -->
        <!--
        <force_client_auth>Y</force_client_auth>
        -->

        <!-- Optional and only used when at least one of <use_client_auth> and
             <force_client_auth> is set to Y. Reference to a keystore to be used
             by the HTTPS service to accept client certificates.
             It can be used to supply client certificates that should be
             accepted, in addition to those with a valid certificate chain,
             for instance while testing with self-signed certificates.
             See the <keystore> block above for general details on keystore
             configuration (although the subelement names are different).
             Note that the further constraints reported there with regard to
             accessing the certificates in a JKS keystore don't hold in this
             case, where the latter is used as a truststore.
             Moreover, the handling of keystore replacement doesn't apply here. -->
        <!--
        <truststore type="JKS">
            <truststore_file>./myserver.truststore</truststore_file>
            <truststore_password type="text">mypassword</truststore_password>
        </truststore>
        -->

    <!--
    </https_server>
    -->

    <!-- GLOBAL SOCKET SETTINGS -->

    <!-- Mandatory. Longest inactivity time accepted while waiting for a slow
         request to be received. If this value is exceeded, the socket is
         closed. Reusable HTTP connections are also closed if they are not
         reused for longer than this time.
         The time actually considered may be approximated and may be a few
         seconds higher, for internal performance reasons.
         A 0 value suppresses the check. -->
    <read_timeout_millis>20000</read_timeout_millis>

    <!-- Optional. Longest inactivity time accepted while waiting for a slow
         operation during a TLS/SSL handshake. This involves both reads,
         writes, and encryption tasks managed by the "TLS-SSL HANDSHAKE"
         or "TLS-SSL AUTHENTICATION" internal pools. If this value is
         exceeded, the socket is closed.
         The time actually considered may be approximated and may be a few
         seconds higher, for internal performance reasons.
         A 0 value suppresses the check.
         Default: 4000 ms. -->
    <!--
    <handshake_timeout_millis>2000</handshake_timeout_millis>
    -->

    <!-- Optional. Maximum length in bytes accepted for a request.
         For an HTTP GET request, the limit applies to the whole request,
         including the headers.
         For an HTTP POST request, the limit applies to the header part and the
         body part separately.
         For a request over a WebSocket, the limit applies to the request
         message payload. -->
    <request_limit>50000</request_limit>

    <!-- Optional. Longest operation time accepted while writing data on a
         socket. If this value is exceeded, the socket is closed. Note that
         this may also affect very slow clients.
         The time actually considered may be approximated and may be a few
         seconds higher, for internal performance reasons.
         If missing or 0, the check is suppressed. -->
    <write_timeout_millis>120000</write_timeout_millis>

    <!-- Optional. Enabling the use of the full HTTP 1.1 syntax for all the
         responses, upon HTTP 1.1 requests. Can be one of the following:
         - Y: HTTP 1.1 is always used, when possible.
         - N: HTTP 1.0 is always used; this is possible for all HTTP requests,
              but it will prevent WebSocket support.
         Default: HTTP 1.0 is used, unless HTTP 1.1 is required in order to
         support specific response features. -->
    <use_http_11>Y</use_http_11>

    <!-- Optional. WebSocket support configuration. The support is enabled
         by default. -->
    <websocket>

        <!-- Optional. Enabling of the WebSocket support.
             Can be one of the following:
             - Y: the Server accepts requests for initiating a WebSocket
                  interaction through a custom protocol;
             - N: the Server refuses requests for WebSocket interaction.
             Disabling WebSocket support may be needed when the local
             network infrastructure (for instance the Load Balancer) does
             not handle WebSocket communication correctly and the WebSocket
             transport is not already disabled on the client side through
             the Lightstreamer Client Library in use. The Client Library, upon the
             Server refusal, will resort to HTTP streaming without any
             additional delay to session establishment.
             Default: Y. -->
        <!--
        <enabled>N</enabled>
        -->

        <!-- Optional. Maximum time the Server is allowed to wait before
             answering to a client "ping" request. In case a client sends
             very frequent "ping" requests, only the "pong" associated to
             the most recent request received is sent, while the previous
             requests will be ignored.
             Note that the above is possible also when 0 is specified.
             Default: 0. -->
        <!--
        <max_pong_delay_millis>1000</max_pong_delay_millis>
        -->

        <!-- Optional. Maximum time the Server is allowed to wait for the
             client "close" frame, in case the Server is sending its own
             "close" frame first, in order to try to close the connection
             in a clean way.
             If not specified, no timeout is set and the global
             <read_timeout_millis> limit applies. -->
        <!--
        <max_closing_wait_millis>1000</max_closing_wait_millis>
        -->

        <!-- Optional. Maximum payload size allowed for an outbound frame.
             When larger updates have to be sent, the related WebSocket
             messages will be split into multiple frames.
             A lower limit for the setting may be enforced by the Server.
             Default: 16384. -->
        <!--
        <max_outbound_frame_size>4096</max_outbound_frame_size>
        -->

    </websocket>

<!--
  ======================
  SECURITY CONFIGURATION
  ======================
-->

    <!-- Optional. Disabling of the protection for JavaScript pages, supplied
         by the Server, that carry user data.
         JavaScript pages can be supplied upon requests by the Client Libraries.
         The protection prevents such pages from being imported in a <script> block
         and, as a consequence, from being directly executed within a hosting page
         regardless of its origin.
         This protection allows the Server to fully comply with the
         prescriptions to prevent the so-called "JavaScript Hijacking".
         Can be one of the following:
         - Y: the protection is enabled.
         - N: the protection is disabled.
              It can be set in order to support communication between the
              application front-end pages and MQTT.Cool in specific
              use cases.
              Note, however, that basic protection against JavaScript
              Hijacking can still be granted, simply by ensuring that request
              authorization is never based on information got from the request
              cookies. This already holds for any session-related request other
              than session-creation ones, for which the request URL is always
              checked against the Server-generated session ID.
              For session-creation requests, this depends on the Metadata
              Adapter implementation, but can be enforced by setting
              <forward_cookies> to N.
         Default: Y. -->
    <use_protected_js>N</use_protected_js>

    <!-- Optional. Use this setting to enable the forwarding of the cookies to
         the Metadata Adapter through the httpHeaders argument of the "notifyUser"
         method.
         Please note that in any case cookies should not be used to authenticate
         users, otherwise, having <use_protected_js> set to N and/or a too permissive
         policy in the <cross_domain_policy> will expose the server to CSRF attacks.
         Can be one of the following:
         - Y: cookies are forwarded to the Metadata Adapter.
         - N: cookies are hidden from the Metadata Adapter.
         Default: N. -->
    <forward_cookies>N</forward_cookies>

    <!-- Mandatory. List of origins to be allowed by the browsers to consume
         responses to requests sent to this Server through cross-origin XHR or
         through WebSockets; in fact, when a requesting page asks for streaming
         data in this way, the browser should specify the page origin through the
         "Origin" HTTP header, to give the Server a chance to accept or refuse
         the request.
         This is the most common way streaming data is requested by the
         Web Client Library.
         If a request origin is not matched against any of the configured rules,
         a Websocket initiation request will be refused, whereas a HTTP request
         will not be denied (i.e.: a 200 OK will be returned) but the response
         body will be left empty, in accordance with the CORS specifications.
         If no origin is specified by the user-agent, the request will always be
         accepted.
         Note that sending the Origin header is a client-side duty. In fact,
         most modern browsers, upon a request for a cross-origin XHR or WebSocket
         by a page, will send the Origin header, while older browsers will directly
         fail to send the request. Non-browser clients usually don't have to perform
         origin checks; so they don't send the Origin header and thus their requests
         are always authorized.
         In case the client wishes to send custom headers to the server, it requires
         an approval from the server itself. The accept_extra_headers attribute
         of this element permits to specify a comma separated list of extra headers
         to be allowed in the client requests. Note that a space is expected after
         each comma (e.g.: accept_extra_headers="custom-header1, custom-header2").
         The accept_credentials attribute can be used to specify if the server should
         authorize the client to send its credentials on a CORS request. This flag
         does not impact the user/password sent over the Lightstreamer protocol,
         but, if set to false, might prevent, or force a fallback connection, on
         clients sending CORS requests carrying cookies, http-basic-authentication or
         client-side certificates. Default is Y.
         In case an HTTP OPTIONS request is sent to authorize future requests,
         the server allows the client to store the result of such OPTIONS
         request for a number of seconds configured in the options_max_age
         attribute of this element (default is 3600). Thus a previously authorized
         client may not give up its authorization, even if the related origin is
         removed from the list and the server is restarted, until its authorization
         expires. -->
    <cross_domain_policy options_max_age="3600" accept_extra_headers="" accept_credentials="Y" >

        <!-- Optional and cumulative. Declaration of an Origin allowed
             to consume responses to cross-origin requests.
             Each <allow_access_from> element will define a rule against which
             Origin headers will be checked.
             Each rule must define a scheme, a host and a port in the following way:
             - scheme: it can be http, https or *, the latter enabling both http and
               https scheme to be accepted.
             - host: a valid host name, IPv4 or IPv6 representing an authorized Origin.
               Also a * is accepted with the meaning of "any host or IP".
               If a host name is specified it can be prefixed with a wildcard as long
               as at least the second level domain is explicitly specified (i.e.:
               *.my-domain.com and *.sites.my-domain.com are valid entries
               while *.com is not)
             - port: a valid port or * to specify any port.
             -->
        <allow_access_from scheme="*" host="*" port="*" />
        <!--
        <allow_access_from scheme="https" host="www.my-domain.com" port="443" />
        -->
        <!--
        <allow_access_from scheme="*" host="*.my-domain.com" port="*" />
        -->
        <!--
        <allow_access_from scheme="*" host="192.168.0.101" port="*" />
        -->
        <!--
        <allow_access_from scheme="*" host="2001:0db8:aaaa:0000:0000:dddd:eeee:0000" port="*" />
        -->
        <!--
        <allow_access_from scheme="*" host="2001:0db8:aaaa::dddd:eeee:0" port="*" />
        -->

    </cross_domain_policy>

    <!-- Optional and cumulative. Origin domain or subdomain to be allowed
         by the browsers to access data on HTML pages supplied by this Server.
         In this kind of requests, the requesting page should be allowed by
         the browser to access data contained in the Server-originated page
         only if both pages declare a common subdomain. So, the page should
         declare a subdomain as its "document.domain" property and will ask
         the Server to declare the same subdomain on the response page.
         In that case, the Server will be allowed to set the requested
         subdomain as the "document.domain" property of the data page only
         if configured here, otherwise the whole request will be refused.
         On the other hand, if no <allowed_domain> element is configured,
         then this check is disabled. Note that, in any case, the consistency
         of the declared subdomain with the url used to request the data page
         must be ensured by the browser.
         If the requesting page doesn't specify any subdomain for the response,
         the request will always be allowed; in this case, a same-domain access
         to the Server data page will be performed by the browser. -->
    <!--
    <allowed_domain>my-domain.com</allowed_domain>
    -->
    <!--
    <allowed_domain>my-alt-domain.com</allowed_domain>
    -->

    <!-- Optional. Server identification policy to be used for all server
         responses. Upon any HTTP request, the Server identifies itself
         through the "Server" HTTP response header. However, omitting version
         information may make external attacks more difficult.
         Can be one of the following:
         - FULL: the Server identifies itself as:
                 MQTT.Cool Server/X.Y.Z build BBBB EEEEEE edition
         - MINIMAL: the Server identifies itself, depending on the Edition:
             for Enterprise edition, as:
                 MQTT.Cool Server
             for Community edition, as:
                 MQTT.Cool Server COMMUNITY edition
         Default: FULL. -->
    <!--
    <server_tokens>MINIMAL</server_tokens>
    -->

<!--
  ====================================
  LOGGING AND MANAGEMENT CONFIGURATION
  ====================================
-->

    <!-- Mandatory. Path of the configuration file for the internal logback-based
         logging system. The file path is relative to the conf directory. -->
    <logback_properties>./log_configuration.xml</logback_properties>

    <!-- Optional. A set of Clients whose activity is not to be logged. -->
    <no_logging_ip>

        <!-- Cumulative. IP address of a Client to exclude from logging. -->
        <!--
        <ip_value>200.0.0.10</ip_value>
        -->

    </no_logging_ip>

    <!-- Optional. Enabling of the inclusion of the user password in the log
         of the client requests for new sessions, performed by the
         "LightstreamerLogger.requests" logger at INFO level.
         Can be one of the following:
         - Y: the whole request is logged;
         - N: the request is logged, but for the value of the LS_password
              request parameter.
         Note that the whole request may still be logged by some loggers,
         but only at DEBUG level, which is never enabled in the default
         configuration.
         Default: N. -->
    <!--
    <show_password_on_request_log>Y</show_password_on_request_log>
    -->

    <!-- Optional. Threshold time for long Adapter call alerts.
         All Data and Metadata Adapter calls should perform as fast
         as possible, to ensure that client requests are accomplished quickly.
         Slow methods may also require that proper thread pools are configured.
         Hence, all invocations to the Adapters (but for the initialization
         phase) are monitored and a warning is logged whenever their execution
         takes more than this time.
         A 0 value disables the check.
         Default: 1000. -->
    <unexpected_wait_threshold_millis>0</unexpected_wait_threshold_millis>

    <!-- Optional. Threshold wait time for a task enqueued for running on any
         of the internal thread pools.
         The current wait time is periodically sampled by the Server Monitor
         on each pool and, whenever it exceeds this threshold on a pool,
         a warning is logged. Note that warning messages can be issued
         repeatedly. A 0 value disables the check.
         Default: 10000. -->
    <!--
    <max_task_wait_millis>0</max_task_wait_millis>
    -->

    <!-- Mandatory. Sampling time for internal load statistics (Server
         Monitor). These statistics are available through the JMX interface;
         some of these statistics are logged bt the Internal Monitor log
         or can be subscribed to through the internal Monitoring Adapter Set. -->
    <collector_millis>2000</collector_millis>

    <!-- Mandatory (if you wish to use the provided "stop" script).
         JMX preferences and external access configuration. -->
    <jmx>

        <!-- Mandatory (if you wish to use the provided "stop" script).
             Enables the standard RMI connector.
             The remote MBean server will be accessible through this url:
             "service:jmx:rmi:///jndi/rmi://<host>:<port>/lsjmx".
             The JVM platform MBean server is also exposed and it is accessible
             through the url:
             "service:jmx:rmi:///jndi/rmi://<host>:<port>/jmxrmi".
             Note that the configuration of the connector applies to both cases;
             hence, access to the JVM platform MBean server from this connector
             is not configured through the "com.sun.management.jmxremote" JVM
             properties. -->
        <rmi_connector>

            <!-- Mandatory. TCP port on which the RMI connector will be
                 available. This is the port that has to be specified in the
                 client access url.
                 The optional "ssl" attribute, when set to "Y", enables TLS/SSL
                 communication. Note that this case is not managed by some JMX
                 clients, like jconsole. -->
            <port ssl="N">8888</port>

            <!-- Optional. TCP port that will be used by the RMI connector for
                 its own communication stuff. The port has not to be specified
                 in the client access url, but it may have to be considered for
                 firewall settings.
                 The optional "ssl" attribute, when set to "Y", enables TLS/SSL
                 communication by the connector; TLS/SSL at this level is supported
                 by some JMX clients, like jconsole. If omitted, the same setting
                 used for <port> is considered.
                 Default: the same as configured in <port>. -->
            <!--
            <data_port ssl="N">4444</data_port>
            -->

            <!-- Optional. A hostname by which the RMI Server can be reached from
                 all the clients. In fact, the RMI Connector, for its own
                 communication stuff, does not use the hostname specified in the
                 client access url, but needs an explicit server-side configuration.
                 Note that, if you wish to use the provided "stop" script, the
                 specified hostname has to be visible also from local clients.
                 Default: any setting provided to the "java.rmi.server.hostname"
                 JVM property. -->
            <!--
            <hostname>push.mycompany.com</hostname>
            -->

            <!-- Optional. Enabling of a preliminary test on the reachability
                 of the RMI Server through the configured hostname. Note that the
                 reachability is not needed for the Server itself, so the test is only
                 for the benefit of other clients, including the "stop" script;
                 but, since other clients may be run in different environments,
                 the outcome of this test may not be significant.
                 Can be one of the following:
                 - Y: Enables the test; if the test fails, the whole Server startup
                      will fail. If successful and the "stop" script is launched in
                      the same environment of the Server, the script should work.
                 - N: Disables the test.
                 Default: Y. -->
            <test_ports>Y</test_ports>

            <!-- Optional. Timeout to be posed on the connection attempts through
                 the RMI Connector. If 0, no timeout will be posed.
                 The setting affects:
                 - The reachability test (if enabled through <test_ports>).
                 - The connector setup operation; in fact this operation may involve
                   a connection attempt, whose failure, however, would not prevent
                   the setup from being successful. If the configured hostname were
                   not visible locally, the setup might take long time; by setting
                   a timeout, the operation would not block the whole Server startup.
                   However, the RMI Connector (and the "stop" script) might not be
                   available immediately after the startup, and any late failure
                   preventing the connector setup would be ignored.
                 On the other hand, the setting is ignored by the "stop" script.
                 Default: 0. -->
            <test_timeout_millis>5000</test_timeout_millis>

            <!-- Optional. Can be used on a multihomed host to specify the IP
                 address to bind the HTTP/HTTPS server sockets to, for all the
                 communication.
                 This setting is supported only if a <data_port> setting different
                 than the <port> setting is supplied.
                 Note that, when a listening interface is configured and depending
                 on the local network configuration, specifying a suitable
                 <hostname> setting may be needed to make the connector accessible,
                 even from local clients.
                 The default is to accept connections on any/all local addresses. -->
            <!--
            <listening_interface>200.0.0.1</listening_interface>
            -->

            <!-- Optional. Reference to the keystore to be used in case TLS/SSL
                 is enabled for part or all the communication.
                 See the <keystore> block inside <https_server> for general
                 details on keystore configuration. These include the runtime
                 replacement of the keystore, with one difference:
                 if the load of the new keystore fails, the RMI Connector
                 may be left unreachable.
                 Default: if the block is missing, any settings provided to the
                 "javax.net.ssl.keyStore" and "javax.net.ssl.keyStorePassword"
                 JVM properties will apply. -->
            <!--
            <keystore type="JKS">
                <keystore_file>./myserver.keystore</keystore_file>
                <keystore_password type="file">./myserver.keypass</keystore_password>
            </keystore>
            -->

            <!-- Optional and cumulative, but forbidden if <remove_cipher_suites> is used.
                 Specifies all the cipher suites allowed for the interaction, in case
                 TLS/SSL is enabled for part or all the communication.
                 See notes for <allow_cipher_suite> under <https_server>. -->
            <!--
            <allow_cipher_suite>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384</allow_cipher_suite>
            -->
            <!--
            <allow_cipher_suite>........</allow_cipher_suite>
            -->
            <!--
            <allow_cipher_suite>........</allow_cipher_suite>
            -->

            <!-- Optional and cumulative, but forbidden if <allow_cipher_suite> is used.
                 Pattern to be matched against the names of the enabled cipher suites
                 in order to remove the matching ones from the enabled cipher suites set
                 to be used in case TLS/SSL is enabled for part or all the communication.
                 See notes for <remove_cipher_suites> under <https_server>. -->
            <remove_cipher_suites>_DHE_</remove_cipher_suites>
            <!--
            <remove_cipher_suites>TLS_RSA_</remove_cipher_suites>
            -->

            <!-- Optional. Determines which side should express the preference when
                 multiple cipher suites are in common between server and client
                 (in case TLS/SSL is enabled for part or all the communication).
                 See notes for <enforce_server_cipher_suite_preference> under <https_server>.
                 Default: N. -->
            <enforce_server_cipher_suite_preference order="JVM">Y</enforce_server_cipher_suite_preference>

            <!-- Optional and cumulative, but forbidden if <remove_protocols> is used.
                 Specifies one or more protocols allowed for the TLS/SSL interaction,
                 in case TLS/SSL is enabled for part or all the communication.
                 See notes for <allow_protocol> under <https_server>. -->
            <allow_protocol>TLSv1.2</allow_protocol>
            <!--
            <allow_protocol>TLSv1.1</allow_protocol>
            -->
            <!--
            <allow_protocol>TLSv1.3</allow_protocol>
            -->

            <!-- Optional and cumulative, but forbidden if <allow_protocol> is used.
                 Pattern to be matched against the names of the enabled TLS/SSL
                 protocols in order to remove the matching ones from the enabled
                 protocols set to be used in case TLS/SSL is enabled for part
                 or all the communication.
                 See notes for <remove_protocols> under <https_server>. -->
            <!--
            <remove_protocols>TLSv1$</remove_protocols>
            -->
            <!--
            <remove_protocols>TLSv1.1</remove_protocols>
            -->

            <!-- Optional. Enabling of the RMI connector access without credentials.
                 Can be one of the following:
                 - Y: requests to the RMI connector are always allowed;
                 - N: requests to the RMI connector are subject to user authentication;
                      the allowed users are set in the "user" elements.
                 Default: N. -->
            <public>N</public>

            <!-- Optional and cumulative (but ineffective if "public" is set to "Y").
                 Credentials of the users enabled to access the RMI connector.
                 Both "id" and "password" attributes are mandatory.
                 If "public" is set to "N", at least one set of credentials should
                 be supplied in order to allow access through the connector.
                 This is also needed if you wish to use the provided "stop" script;
                 the script will always use the first user supplied. -->
            <user id="user_changeme" password="password_changeme" />
            <!--
            <user id="other_user" password="other_password" />
            -->

        </rmi_connector>

        <!-- Optional. Enables Sun/Oracle's JMXMP connector.
             The connector is supported by the Server only if Sun/Oracle's JMXMP
             implementation library is added to the Server classpath;
             see README.TXT in the JMX SDK for details.
             The remote server will be accessible through the url:
             "service:jmx:jmxmp://<host>:<port>". -->
        <!--
        <jmxmp_connector>
        -->

            <!-- Mandatory. TCP port on which Sun/Oracle's JMXMP connector will be
                 listening. This is the port that has to be specified in the
                 client access url. -->
            <!--
            <port>9999</port>
            -->

        <!--
        </jmxmp_connector>
        -->

        <!-- Optional. Disabling of the availability of session-related mbeans,
             the ones identified by type="Session". Can be one of the following:
             - Y: no mbeans of type "Session" are generated, but for a fake mbean
                  which acts as a reminder that the option can be enabled;
             - sampled_statistics_only: for each active session, a corresponding
                  mbean of type "Session" is available, but all the statistics
                  based on periodic sampling are disabled;
             - N: for each active session, a corresponding mbean of type "Session"
                  is available with full functionality.
             The support for session-related mbeans can pose a significant
             overload on the Server when many sessions are active and many of them
             are continuously created and closed. For this reason, the support is
             disabled by default.
             Default: Y. -->
        <!--
        <disable_session_mbeans>N</disable_session_mbeans>
        -->

    </jmx>

    <!-- Mandatory. Configuration of the Monitoring Dashboard.
         The dashboard is a webapp whose pages are embedded in Lightstreamer
         Server and supplied by the internal web server. The main page has
         several tabs, which provide basic monitoring statistics in graphical
         form; the last one shows the newly introduced JMX Tree,
         which enables JMX data view and management from the browser.
         The Dashboard leans on an internal Adapter Set, named "MONITOR".
         The following elements configure access restrictions to Monitoring
         Dashboard pages.
         *** IMPORTANT *** The Monitoring Dashboard enables data view and
         management, including the Server shutdown operation, from a remote
         browser. We recommend configuring the credentials and protecting them
         by making the Monitoring Dashboard only available on https server
         sockets through the settings below. Further restrictions can be
         applied to the JMX Tree only. See PRODUCTION_SECURITY_NOTES.TXT for
         a full check-list.
         Note that basic monitoring statistics are also available to any
         Lightstreamer application; in fact, an instance of a special internal
         monitoring Data Adapter can be embedded in any custom Adapter Set,
         by specifying "MONITOR" in place of the Data Adapter class name.
         For a listing of the supplied items, see the General Concepts document.
         The <enable_hostname_lookup> setting below also affects the monitoring
         Data Adapter. On the other hand, access restrictions to a monitoring
         Data Adapter instance embedded in a custom Adapter Set is only managed
         by the custom Metadata Adapter included. -->
    <dashboard>

        <!-- Optional. Enabling of the requests for the JMX Tree page, which is
             part of the Monitoring Dashboard.
             This page, whose implementation is based on the "jminix" library,
             enables JMX data view and management, including the Server shutdown
             operation, from the browser.
             Can be one of the following:
             - Y: the Server supports requests for JMX Tree pages, though further
                  fine-grained restrictions may also apply;
             - N: the Server ignores requests for JMX Tree pages, regardless of
                  the credentials supplied and the server socket in use; the
                  dashboard tab will just show a "disabled page" notification.
             Default: N. -->
        <jmxtree_enabled>Y</jmxtree_enabled>

        <!-- Optional. Enabling of the access to the Monitoring Dashboard
             pages without credentials.
             Can be one of the following:
             - Y: requests for the Monitoring Dashboard are always accepted.
             - N: requests for the Monitoring Dashboard are subject to a check
                  for credentials to be specified through the "user" elements;
                  hence, a user credential submission dialog may be presented
                  by the browser.
                  If no "user" elements are defined, the Monitoring Dashboard
                  will not be accessible in any way.
             Default: N. -->
        <public>Y</public>

        <!-- Optional and cumulative (but ineffective if "public" is set to "Y").
             Credentials of the users enabled to access the Monitoring Dashboard.
             Both "id" and "password" attributes are mandatory.
             The optional "jmxtree_visible" attribute (whose default is "Y")
             allows for restriction of the access to the JMX Tree on a user basis;
             it is only effective if <jmxtree_enabled> is set to "Y". -->
        <!--
        <user id="put_your_dashboard_user_here" password="put_your_dashboard_password_here" />
        -->
        <!--
        <user id="other_user" password="other_password" jmxtree_visible="N" />
        -->

        <!-- Optional. Enabling of the access to the Monitoring Dashboard pages
             through all server sockets. Can be one of the following:
             - Y: requests to the Monitoring Dashboard can be issued through
                  all the defined server sockets.
             - N: requests to the Monitoring Dashboard can be issued only
                  through the server sockets specified in the "available_on_server"
                  elements, if any; otherwise, requests to the dashboard url
                  will get a "page not found" error.
                  If no "available_on_server" elements are defined, requests to
                  the Monitoring Dashboard will not be possible in any way.
             Disabling the Dashboard on a server socket causes the internal "MONITOR"
             Adapter Set to also become unavailable from that socket. This does not
             affect in any way the special "MONITOR" Data Adapter.
             Default: N. -->
        <available_on_all_servers>Y</available_on_all_servers>

        <!-- Optional and cumulative (but ineffective if "available_on_all_servers"
             is set to "Y").
             Specific server sockets for which requests to the Monitoring Dashboard
             will be allowed, that can be identified through the mandatory "name"
             attribute; if the name has been assigned to more than one server
             socket, then the setting applies to all of them.
             The optional "jmxtree_visible" attribute (whose default is "Y")
             allows for restriction of the access to the JMX Tree on a TCP port
             basis; it is only effective if <jmxtree_enabled> is set to "Y". -->
        <!--
        <available_on_server name="MQTT.Cool HTTPS Server" />
        -->
        <!--
        <available_on_server name="MQTT.Cool HTTP Server" jmxtree_visible="N" />
        -->

        <!-- Optional. URL path to map the Monitoring Dashboard pages to.
             An absolute path must be specified.
             Default: /dashboard -->
        <!--
        <dashboard_url_path>/my_dashboard</dashboard_url_path>
        -->

        <!-- Optional. Enabling of the reverse lookup on Client IPs and inclusion
             of the Client hostnames while monitoring client activity.
             This setting affects the Monitor Console page and also affects
             any instance of the monitoring Data Adapter embedded in a custom
             Adapter Set.
             Can be one of the following:
             - Y: the Client hostname is determined on Client activity
                  monitoring; note that the determination of the client hostname
                  may be heavy for some systems;
             - N: no reverse lookup is performed and the Client hostname is not
                  included on Client activity monitoring.
             Default: N. -->
        <!--
        <enable_hostname_lookup>Y</enable_hostname_lookup>
        -->

    </dashboard>

    <!-- Optional. Configuration of the "/lightstreamer/healthcheck" request
         url, which allows a load balancer to test for Server responsiveness
         to external requests. The Server should always answer to the
         request with the "OK\r\n" content string. The Server may log
         further information to the dedicated "LightstreamerHealthCheck"
         logger.
         Support for clustering is an optional feature, available depending
         on Edition. -->
    <healthcheck>

        <!-- Optional. Enabling of the healthcheck url on all server sockets.
             Can be one of the following:
             - Y: healthcheck requests can be issued through all the defined
                  server sockets;
             - N: healthcheck requests can be issued only through the server
                  sockets specified in the "available_on_server" elements,
                  if any.
             Default: N. -->
        <available_on_all_servers>N</available_on_all_servers>

        <!-- Optional and cumulative (but ineffective if "available_on_all_servers"
             is set to "Y").
             Specific server sockets for which healthcheck requests can be issued,
             that can be identified through the mandatory "name" attribute
             (if the name has been assigned to more than one server socket,
             then the setting applies to all of them). -->
        <!--
        <available_on_server name="MQTT.Cool HTTP Server" />
        -->

    </healthcheck>

<!--
  ==========================
  PUSH SESSION CONFIGURATION
  ==========================
-->

    <!-- Optional. If set, defines an alternative url for all requests related
         to the streaming services. The specified path, which must be absolute,
         will be completed with the /lightstreamer suffix.
         Then it will be possible to instruct the Unified Client SDKs to use
         the new path by adding this prefix to the supplied Server address.
         Note that, despite defining this path, the standard path, which is
         /lightstreamer, will remain active.
         By using dedicated paths, it becomes possible to address different
         Server installations with the same hostname, by instructing an
         intermediate proxy to forward each client request to the proper place
         based on the prefix. However, this does not apply to the Internal
         Web Server and to the Monitoring Dashboard. -->
    <!--
    <service_url_prefix>/server1</service_url_prefix>
    -->

    <!-- Mandatory. Maximum size of HTTP streaming responses; when the maximum size is
         reached, the connection is closed but the session remains active and
         the Client can continue listening to the item update events by binding
         the session to another connection.
         This setting is also used as the maximum length allowed for poll
         responses; if more data were available, they would be kept for the next
         poll request.
         The Setting is not used for streaming responses over WebSockets.
         The optimal content-length for web clients (i.e. browser user agents)
         should not be too high, in order to reduce the maximum allocated memory
         on the client side. Also note that some browsers, in case of a very
         high content-length, may reduce streaming capabilities (noticed with
         IE8 and 4GB).
         This setting can be overridden by the Clients (some LS client libraries
         actually set their own default).
         The lowest possible value for the content-length is decided by the Server,
         so as to allow the connection to send a minimal amount of data. -->
    <content_length>

        <!-- Mandatory. Define the maximum size of HTTP streaming responses
             (and the upper limit for polling responses). -->
        <default>4000000</default>

        <!-- Optional and cumulative. Through the "value" attribute, defines the
             HTTP content-length to be used for stream/poll responses (overriding
             the setting in "default") when all the conditions specified through
             the subelements are met.
             Multiple occurrences of "special_case" are evaluated in sequence,
             until one is enabled. -->
        <!--
        <special_case value="100000">
        -->
            <!-- Mandatory and cumulative. Defines a condition on the user-agent
                 supplied with the request, which should include the string
                 specified through the "contains" attribute. -->
            <!--
            <user_agent contains="Symbian OS" />
            -->
        <!--
        </special_case>
        -->

    </content_length>

    <!-- Optional. Maximum lifetime allowed for single HTTP streaming responses;
         when this timeout expires, the connection is closed, though the
         session remains active and the Client can continue listening to the
         UpdateEvents by binding the session to another connection.
         Setting this timeout is not needed in normal cases; it is provided
         just in case any user agent or intermediary node turned out to be
         causing issues on very long-lasting HTTP responses.
         The Setting is not applied to polling responses and to streaming
         responses over WebSockets.
         If not specified, no limit is set; the streaming session duration
         will be limited only by the "content_length" setting and, at least,
         by the keep-alive message activity. -->
    <!--
    <max_streaming_millis>480000</max_streaming_millis>
    -->

    <!-- Optional. Enabling the use of the "chunked" transfer encoding,
         as defined by the HTTP 1.1 specifications, for sending the response
         body on HTTP streaming connections. Can be one of the following:
         - Y: The "chunked" transfer encoding will be used anytime an
              HTTP 1.1 response is allowed (see "use_http_11").
         - N: Causes no transfer encoding (that is, the "identity" transfer
              encoding) to be used for all kinds of responses.
         Though with "chunked" transfer encoding the content-length header
         is not needed on the HTTP response header, configuring a content
         length for the Server is still mandatory and the setting is obeyed
         in order to put a limit to the response length.
         Default: The "chunked" transfer encoding will be used only when
              an HTTP 1.1 response is being sent (see "use_http_11"). -->
    <use_chunked_encoding>Y</use_chunked_encoding>

    <!-- Optional. Enabling the use of the "gzip" content encoding,
         as defined by the HTTP 1.1 specifications, for sending the resource
         contents on HTTP responses; compression is currently not supported
         for responses over WebSockets. Can be one of the following:
         - Y: Gzip compression will be used anytime an HTTP 1.1 response
              is allowed (for streaming responses, the "chunked" transfer
              encoding should also be allowed), provided that the client has
              declared to accept it through the proper http request headers.
         - N: Causes no specific content encoding to be applied for all kinds
              of contents.
         Streaming responses are compressed incrementally.
         The use of compression may relieve the network level at the expense
         of the Server performance. Note that bandwidth control and output
         statistics are still based on the non-compressed content.
         Default: Gzip compression will not be used, unless using it is
              recommended in order to handle special cases (and provided that
              all the conditions for compression are met; see case Y above). -->
    <!--
    <use_compression>N</use_compression>
    -->

    <!-- Optional. Size of the response body below which compression is not
         applied, regardless of the "use_compression" setting, as we guess
         that no benefit would come. It is not applied to streaming responses,
         which are compressed incrementally.
         Default: 1024 bytes. -->
    <!--
    <compression_threshold>0</compression_threshold>
    -->

    <!-- Optional. Maximum size for any ItemEventBuffer. It applies to RAW and
         COMMAND mode and to any other case of unfiltered subscription.
         For filtered subscriptions, it poses an upper limit on the maximum
         buffer size that can be granted by the Metadata Adapter or requested
         through the subscription parameters. Similarly, it poses an upper
         limit to the length of the snapshot that can be sent in DISTINCT mode,
         regardless of the value returned by getDistinctSnapshotLength.
         See the General Concepts document for details on when these buffers
         are used. An excessive use of these buffers may give rise to a
         significant memory footprint; to prevent this, a lower size limit
         can be set.
         Note that the buffer size setting refers to the number of update
         events that can be kept in the buffer, hence the consequent memory
         usage also depends on the size of the values carried by the enqueued
         updates.
         As lost updates for unfiltered subscriptions are logged on the
         LightstreamerLogger.pump logger at INFO level, if a low buffer size
         limit is set, it is advisable also setting this logger at WARN level.
         Aggregate statistics on lost updates are also provided by the JMX
         interface (if available) and by the Internal Monitor. -->
    <max_buffer_size>1000</max_buffer_size>

    <!-- Mandatory. Longest time a disconnected session can be kept alive
         while waiting for the Client to rebind such session to another
         connection, in order to make up for client or network latencies.
         Note that the wait is not performed when the session is being closed
         because of an explicit disconnection by the client.
         If the client has requested an inactivity check on a streaming
         connection, the same timeout is also started when no control request
         (or reverse heartbeat) has been received for the agreed time (again,
         in order to make up for client or network latencies). If it expires,
         the current streaming connection will be ended and the client
         will be requested to rebind to the session (which triggers the
         previous case). -->
    <session_timeout_millis>10000</session_timeout_millis>

    <!-- Optional. Longest time a session can be kept alive, after the
         interruption of a connection at network level, waiting for the Client
         to attempt a recovery. Since a disconnection may affect the Client
         without affecting the Server, this also instructs the Server to keep
         track of the events already sent for this time duration, to support
         unexpected recovery requests.
         The client should try a recovery request immediately after detecting
         the interruption; but, the request may come later when, for instance,
         - there is a network outage of a few seconds and the client must retry,
         - the client detects the interruption because of the stalled timeout.
         Hence, the optimal value should be tuned according with client-side
         timeouts to ensure the better coverage of cases.
         Note that recovery is available only for some client versions; if any
         other version were involved, the session would be closed immediately.
         A 0 value also prevents any accumulation of memory.
         Default: 0. -->
    <session_recovery_millis>13000</session_recovery_millis>

    <!-- Optional. Maximum number of bytes of streaming data, already sent
         or being sent to the Client, that should be kept, in order to allow
         the Client to recover the session, in case a network issue should
         interrupt the streaming connection and prevent the client from
         receiving the latest packets.
         Note that recovery is available only for some client versions;
         if any other version were involved, no data would be kept.
         A 0 value also prevents any accumulation of memory.
         Default: the value configured for "sendbuf". -->
    <!--
    <max_recovery_length>5000</max_recovery_length>
    -->

    <!-- Optional. Maximum size supported for keeping a polling response,
         already sent or being sent to the Client, in order to allow the Client
         to recover the session, in case a network issue should interrupt
         the polling connection and prevent the client from receiving the
         latest response.
         Note that recovery is available only for some client versions;
         if any other version were involved, no data would be kept.
         A 0 value also prevents any accumulation of memory. On the other
         hand, a value of -1 relieves any limit.
         Default: -1. -->
    <!--
    <max_recovery_poll_length>0</max_recovery_poll_length>
    -->

    <!-- Optional. Longest time the subscriptions currently in place on a
         session can be kept active after the session has been closed,
         in order to prevent unsubscriptions from the Data Adapter that would
         be immediately followed by new subscriptions in case the client
         were just refreshing the page.
         As a consequence of this wait, some items might temporarily appear
         as being subscribed to, even if no session were using them.
         If a session is closed after being kept active because of the
         "session_timeout_millis" or "session_recovery_millis" setting,
         the accomplished wait is considered as valid also for the
         subscription wait purpose.
         Default: the time configured for "session_timeout_millis". -->
    <subscription_timeout_millis>5000</subscription_timeout_millis>

    <!-- Optional. Timeout used to ensure the proper ordering of client-sent
         messages, within the specified message sequence, before sending them
         to the Metadata Adapter through notifyUserMessage.
         In case a client request is late or does not reach the Server,
         the next request may be delayed until this timeout expires, while
         waiting for the late request to be received; then, the next request
         is forwarded and the missing one is discarded with no further recovery
         and the client application is notified.
         Message ordering does not concern the old synchronous interfaces for
         message submission. Ordering and delaying also does not apply to the
         special "UNORDERED_MESSAGES" sequence, although, in this case,
         discarding of late messages is still possible, in order to ensure
         that the client eventually gets a notification.
         A high timeout (as the default one) reduces the discarded messages,
         by allowing the client library to reissue requests that have got lost.
         A low timeout reduces the delays of subsequent messages in case
         a request has got lost and can be used if message dropping is
         acceptable.
         Default: 30000. -->
    <!--
    <missing_message_timeout_millis>1000</missing_message_timeout_millis>
    -->

    <!-- Optional. Configuration of the special handling of the unchanged
         values when sending updates to the clients.
         Can be one of the following:
         - Y: the Server is allowed to perform "delta delivery"; it will send
              special notifications to notify the clients of values that are
              unchanged with respect to the previous update for the same item;
         - N: the Server always sends to the clients the actual values in the
              updates; note that any missing field in an update for an item
              in MERGE mode will be filled with the old value before being sent,
              hence the old value will be resent anyway.
         Checking for unchanged values and sending special notifications for
         them is in general more efficient than always sending the values.
         On the other hand, checking for unchanged values puts heavier memory
         and processing requirements on the Server.
         Default: Y. -->
    <!--
    <delta_delivery>N</delta_delivery>
    -->

    <!--
         Optional. Policy to be adopted for the handling of session-related
         internal buffers.
         Can be one of the following:
         - Y: internal buffers used for composing and sending updates are kept
              among session-related data throughout the life of each session;
              this speeds up update management;
         - N: internal buffers used for composing and sending updates are
              allocated and deallocated on demand; this minimizes the
              requirements in terms of permanent per-session memory and may be
              needed in order to handle a very high number of concurrent
              sessions, provided that the per-session update activity is low.
         Default: The current setting of "delta_delivery" is used.
         In fact, setting "delta_delivery" as N may denote the need for
         reducing permanent per-session memory. -->
    <!--
    <reuse_pump_buffers>Y</reuse_pump_buffers>
    -->

    <!-- STREAMING MODE -->

    <!-- Optional. Size to be set for the socket TCP send buffer in case of
         streaming connections.
         The ideal setting should be a compromise between throughput, data aging,
         and memory usage. A large value may increase throughput, particularly
         in sessions with a high update activity and a high roundtrip time;
         however, in case of sudden network congestion, the queue of outbound
         updates would need longer to be cleared and these updates would reach
         the client with significant delays. On the other hand, with a small
         buffer, in case of sudden network congestion, most of the ready updates
         would not be enqueued in the TCP send buffer, but inside the Server,
         where there would be an opportunity to conflate them with newer updates.
         The main problem with a small buffer is when a single update is very
         big, or a big snapshot has to be sent, and the roundtrip time is high;
         in this case, the delivery could be slow. However, the Server tries
         to detect these cases and temporarily enlarge the buffer.
         Hence, the factory setting is very small and it is comparable with
         a typical packet size. There shouldn't be any need for an even smaller
         value; also note that the system may force a minimum size.
         Higher values should make sense only if the expected throughput is
         high and responsive updates are desired.
         Default: 1600. -->
    <!--
    <sendbuf>5000</sendbuf>
    -->

    <!-- Optional. Longest delay that the Server is allowed to apply to
         outgoing updates in order to collect more updates in the same
         packet. This value sets a trade-off between Server scalability
         and maximum data latency. It also sets an upper bound to the
         maximum update frequency for items not subscribed with unlimited
         or unfiltered frequency.
         Default: 0. -->
    <!--
    <max_delay_millis>30</max_delay_millis>
    -->

    <!-- Mandatory. Longest write inactivity time allowed on the socket.
         If no updates have been sent after this time, then a small
         keep-alive message is sent.
         Note that the Server also tries other types of checks of the
         availability of current sockets, which don't involve writing data
         to the sockets.
         This setting can be overridden by the Client.
         The optional "randomize" attribute, when set to Y, causes keepalives
         immediately following a data event to be sent after a random, shorter
         interval (possibly even shorter than the "min_keepalive_millis"
         setting). This can be useful if many sessions subscribe to the same
         items and updates for these items are rare, to avoid that also the
         keepalives for these sessions occur at the same times. -->
    <default_keepalive_millis randomize="N">5000</default_keepalive_millis>

    <!-- Mandatory. Lower bound to the keep-alive time requested by a Client.
         Must be lower than the "default_keepalive_millis" setting. -->
    <min_keepalive_millis>1000</min_keepalive_millis>

    <!-- Mandatory. Upper bound to the keep-alive time requested by a Client.
         Must be greater than the "default_keepalive_millis" setting. -->
    <max_keepalive_millis>30000</max_keepalive_millis>

    <!-- SMART-POLLING MODE -->

    <!-- Mandatory. Longest time a client is allowed to wait, after receiving
         a poll answer, before issuing the next poll request. Note that,
         on exit from a poll request, a session has to be kept active, while
         waiting for the next poll request.
         The session keeping time has to be requested by the Client within
         a poll request, but the Server, within the response, can notify a
         shorter time, if limited by this setting.
         The session keeping time for polling may cumulate with the keeping
         time upon disconnection, as set by "session_timeout_millis". -->
    <max_polling_millis>15000</max_polling_millis>

    <!-- Mandatory. Longest inactivity time allowed on the socket while waiting
         for updates to be sent to the client through the response to an
         asynchronous poll request.
         If this time elapses, the request is answered with no data, but the
         client can still rebind to the session with a new poll request.
         A shorter inactivity time limit can be requested by the client.
         The optional "randomize" attribute, when set to Y, causes polls
         immediately following a data event to wait for a random, shorter
         inactivity time. This can be useful if many sessions subscribe to
         the same items and updates for these items are rare, to avoid that
         also the following polls for these sessions occur at the same times. -->
    <max_idle_millis randomize="N">30000</max_idle_millis>

    <!-- Optional. Shortest time allowed between consecutive polls on a
         session. If the client issues a new polling request and less than
         this time has elapsed since the STARTING of the previous polling
         request, the polling connection is kept waiting until this time
         has elapsed.
         In fact, neither a "min_polling_millis" nor a "min_idle_millis"
         setting are provided, hence a client is allowed to request 0 for both,
         so that the real polling frequency will only be determined by
         roundtrip times.
         However, in order to avoid that a similar case causes too much load
         on the Server, this setting can be used as a protection, to limit the
         polling frequency.
         Default: 0. -->
    <!--
    <min_interpoll_millis>1000</min_interpoll_millis>
    -->

<!--
  ========================
  WEB SERVER CONFIGURATION
  ========================
-->

    <!-- Optional. Path of an HTML page to be returned upon unexpected request
         URLs. This applies to URLs in reserved ranges that have no meaning.
         If the Internal web server is not enabled, this also applies to all
         non-reserved URLs; otherwise, nonexisting non-reserved URLs will get the
         HTTP 404 error as usual. The file path is relative to the conf directory.
         Default: the proper page is provided by the Server. -->
    <error_page>./ErrorPage.html</error_page>

    <!-- Optional. Internal web server configuration.
         Note that some of the included settings may also apply to the
         Monitoring Dashboard pages, which are supplied through the internal
         web server. In particular, this holds for the <use_compression> and
         <compression_threshold> settings. Anyway, this does not hold for
         the <enabled> setting, as the Monitoring Dashboard accessibility
         is only configured through the <dashboard> block. -->
    <web_server>

        <!-- Optional. Enabling of the internal web server.
             Can be one of the following:
             - Y: the Server accepts requests for file resources;
             - N: the Server ignores requests for file resources.
             Default: N. -->
        <enabled>Y</enabled>

        <!-- Optional. Path of the file system directory to be used
             by the internal web server as the root for URL path mapping.
             The path is relative to the conf directory.
             Note that the /lightstreamer URL path (and any alternative
             path defined through <service_url_prefix>) is reserved,
             as well as the base URL path of the Monitoring Dashboard
             (see <dashboard_url_path> under the <dashboard> block);
             hence, subdirectories of the pages directory with conflicting
             names would be ignored.
             Default: ../pages -->
        <!--
        <pages_dir>../my_pages</pages_dir>
        -->

        <!-- Optional. Caching time, in minutes, to be allowed to the browser
             (through the "expires" HTTP header) for all the resources supplied
             by the internal web server.
             A zero value disables caching by the browser.
             Default: 0. -->
        <!--
        <persistency_minutes>1000000</persistency_minutes>
        -->

        <!-- Optional. Path of the MIME types configuration property file.
             The file path is relative to the conf directory.
             Default: ./mime_types.properties -->
        <!--
        <mime_types_config>./my_mime_types.properties</mime_types_config>
        -->

        <!-- Optional. Path of an HTML page to be returned as the body upon
             a "404 Not Found" answer caused by the request of a nonexistent URL.
             The file path is relative to the conf directory.
             Default: the proper page is provided by the Server. -->
        <!--
        <notfound_page>./404Page.html</notfound_page>
        -->

        <!-- Optional. Use of the "gzip" content encoding, as defined by the
             HTTP 1.1 specifications, for sending the resource contents.
             It is specified for various cases through the included rules.
             Note that the use of compression for static pages would benefit
             from an internal cache of compressed pages. However, no cache is
             provided, as the internal web server is not meant for production use.
             Default: The "gzip" content encoding is never used. -->
        <use_compression>

            <!-- Optional. Use of the "gzip" content encoding.
                 Can be one of the following:
                 - Y: Gzip compression will be used anytime an HTTP 1.1 response
                      is allowed, provided that the client has declared to support it
                      through the proper http request headers.
                 - N: Causes no specific content encoding to be applied for all kinds
                      of contents.
                 Default: N. -->
            <default>N</default>

            <!-- Optional and cumulative. Through the "value" attribute, specifies
                 whether or not to use the "gzip" content encoding (overriding the
                 setting in "default") when all the conditions specified through
                 the subelements are met.
                 Multiple occurrences of "special_case" are evaluated in sequence,
                 until one is enabled. -->
            <special_case value="Y">
                <!-- Mandatory and cumulative. Defines a condition on the content_type
                     to be used for the response, which should include the string
                     specified through the "contains" attribute. -->
                <content_type contains="text/" />
            </special_case>

        </use_compression>

        <!-- Optional. Size of the resource contents below which compression
             is not applied, regardless of the "use_compression" setting, as we
             guess that no overall benefit would be reached.
             Default: 8192 bytes. -->
        <!--
        <compression_threshold>0</compression_threshold>
        -->

    </web_server>

<!--
  ========================
  CLUSTERING CONFIGURATION
  ========================
-->

    <!-- Optional. Host address to be used for control/poll/rebind connections.
         A numeric IP address can be specified as well. The use of non standard,
         unicode names may not be supported yet by some Client SDKs.
         This setting can be used in case a cluster of Server instances is in
         place, to ensure that all client requests pertaining to the same session
         are issued against the same Server instance. If the Load Balancer can
         ensure that all requests coming from the same client are always routed
         to the same Server instance, then this setting is not needed.
         Note: When this setting is used, the clients should invoke
         ConnectionOptions.setEarlyWSOpenEnabled with false, to improve startup
         performances.
         In case a request comes from a web client and <control_link_machine_name>
         is also specified, the latter setting may be applied instead; see the
         comment for <control_link_machine_name> for details.
         Support for clustering is an optional feature, available depending
         on Edition. When not available, this setting is ignored. -->
    <!--
    <control_link_address>push1.mycompany.com</control_link_address>
    -->

    <!-- Optional. Host name to be used, in addition to the domain name specified
         on the front-end pages, for control/poll/rebind connections coming
         from web clients.
         This setting will override the <control_link_address> setting when the
         request comes from a web client and the access to Server data pages
         requires that the latter share a common subdomain with application pages.
         This option is useful if the subdomain-name part of the hostname is subject
         to changes or if the same machine needs to be addressed through multiple
         subdomain names (e.g. for multihosting purpose).
         The configured name should contain all the portions of the address except
         for the subdomain name. For example, assuming the "mycompany.com" subdomain
         is declared in the front-end pages:
         - If the full address is "push1.mycompany.com", the name should be "push1";
         - If the full address is "push.int2.cnt3.mycompany.com", the name
           should be "push.int2.cnt3".
         Note: When this setting is used, clients should invoke setEarlyWSOpenEnabled
         in the ConnectionOptions class with false, to improve startup performances.
         Support for clustering is an optional feature, available depending
         on Edition. When not available, this setting is ignored. -->
    <!--
    <control_link_machine_name>push1</control_link_machine_name>
    -->

    <!-- Optional. If set and positive, specifies a maximum duration to be enforced
         on each session. If the limit expires, the session is closed and the
         client can only establish a new session. This is useful when a cluster
         of Server instances is in place, as it leaves the Load Balancer the
         opportunity to migrate the new session to a different instance.
         See the Clustering document for details on this mechanism and on how
         rebalancing can be pursued. -->
    <!--
    <max_session_duration_minutes>5</max_session_duration_minutes>
    -->

<!--
  ==================
  LOAD CONFIGURATION
  ==================
-->

    <!-- Optional. Maximum number of concurrent client sessions allowed.
         Requests for new sessions received when this limit is currently
         exceeded will be refused; on the other hand, operation on sessions
         already established is not limited in any way.
         Note that closing and reopening a session on a client when this limit
         is currently met may cause the new session request to be refused.
         The limit can be set as a simple, heuristic protection from Server
         overload.
         Default: unlimited. -->
    <!--
    <max_sessions>1000</max_sessions>
    -->

    <!-- Optional. Limit to the overall size, in bytes, of the buffers
         devoted to I/O operations that can be kept allocated for reuse.
         If 0, removes any limit to the allocation (which should remain
         limited, based on the maximum concurrent buffer needs).
         If -1, disables buffer reuse at all and causes all allocated
         buffers to be released immediately.
         Default: 200000000 -->
    <!--
    <max_common_nio_buffer_allocation>0</max_common_nio_buffer_allocation>
    -->

    <!-- Optional. Limit to the overall size, in bytes, of the buffers
         used internally to compose update packets that can be kept
         allocated for reuse.
         If 0, removes any limit to the allocation (which should remain
         limited, based on the maximum concurrent buffer needs).
         If -1, disables buffer reuse at all and causes all allocated
         buffers to be released immediately.
         Default: 200000000 -->
    <!--
    <max_common_pump_buffer_allocation>0</max_common_pump_buffer_allocation>
    -->

    <!--
         Optional. Number of distinct NIO selectors (each one with its own
         thread) that will share the same operation. Different pools will be
         prepared for different I/O operations and server sockets, which may
         give rise to a significant overall number of selectors.
         Further selectors may be created because of the <selector_max_load>
         setting.
         Default: The number of available total cores, as detected by the JVM. -->
    <!--
    <selector_pool_size>1</selector_pool_size>
    -->

    <!-- Optional. Maximum number of keys allowed for a single NIO selector.
         If more keys have to be processed, new temporary selectors will be
         created. If the value is 0, then no limitations are applied and extra
         selectors will never be created.
         The base number of selectors is determined by the <selector_pool_size>
         setting.
         Default: 0. -->
    <!--
    <selector_max_load>1000</selector_max_load>
    -->

    <!--
         Optional. Number of threads used to parallelize the implementation
         of the internal timers.
         This task does not include blocking operations, but its computation
         may be heavy under high update activity; hence, on multiprocessor
         machines, allocating multiple threads for this task may be beneficial.
         Default: 1. -->
    <!--
    <timer_pool_size>2</timer_pool_size>
    -->

    <!--
         Optional. Size of the "EVENTS" internal thread pool, which is devoted
         to dispatching the update events received from a Data Adapter to the
         proper client sessions, according with each session subscriptions.
         This task does not include blocking operations; however, on
         multiprocessor machines, allocating multiple threads for this task
         may be beneficial.
         Default: The number of available total cores, as detected by the JVM. -->
    <!--
    <events_pool_size>10</events_pool_size>
    -->

    <!--
         Optional. Size of the "SNAPSHOT" internal thread pool, which is devoted
         to dispatching the snapshot events upon new subscriptions from client
         sessions.
         This task does not include blocking operations; however, on
         multiprocessor machines, allocating multiple threads for this task
         may be beneficial.
         Default: The number of available total cores, as detected by the JVM,
         or 10, if the number of cores is less. -->
    <!--
    <snapshot_pool_size>10</snapshot_pool_size>
    -->

    <!--
         Optional. Size of the "PUMP" internal thread pool, which is devoted
         to integrating the update events pertaining to each session and to
         creating the update commands for the client, whenever needed.
         This task does not include blocking operations; however, on
         multiprocessor machines, allocating multiple threads for this task
         may be beneficial.
         Default: The number of available total cores, as detected by the JVM. -->
    <!--
    <pump_pool_size>10</pump_pool_size>
    -->

    <!--
        Optional. Maximum number of tasks allowed to be queued to enter
        the "PUMP" thread pool before undertaking backpressure actions.
        In particular, the same actions associated to the
        <server_pool_max_queue> check will be performed (regardless
        that <server_pool_max_queue> itself is set).
        A steadily long queue on the PUMP pool may be the consequence of
        a CPU shortage due to a huge streaming activity.
        A negative value disables the check.
        Default: -1. -->
    <!--
    <pump_pool_max_queue>1000</pump_pool_max_queue>
    -->

    <!--
        Optional. Maximum number of threads allowed for the "SERVER" internal
        pool, which is devoted to the management of the client requests.
        This kind of tasks includes operations that are potentially blocking:
        - getHostName;
        - socket close;
        - calls to a Metadata Adapter that may need to access to some
          external resource (i.e. mainly notifyUser, getItems, getSchema;
          other methods should be implemented as nonblocking, by leaning
          on data cached by notifyUser);
        - calls to a Data Adapter that may need to access to some
          external resource (i.e. subscribe and unsubscribe, though it
          should always be possible to implement such calls asynchronously);
        - file access by the internal web server, though it should be used
          only in demo and test scenarios.
        Note that specific thread pools can optionally be defined in order
        to handle some of the tasks that, by default, are handled by the
        SERVER thread pool.
        A zero value means a potentially unlimited number of threads.
        Default: 1000. -->
    <!--
    <server_pool_max_size>100</server_pool_max_size>
    -->

    <!--
        Optional, but mandatory if "server_pool_max_size" is set to 0.
        Maximum number of idle threads allowed for the "SERVER" internal
        pool, which is devoted to the management of the client requests.
        Put in a different way, it is the minimum number of threads that can
        be present in the pool. To accomplish this setting, at pool
        initialization, suitable idle threads are created; then, each time
        a thread becomes idle, it is discarded only if enough threads are
        already in the pool.
        It must not be greater than "server_pool_max_size" (unless the latter
        is set to 0, i.e. unlimited); however, it may be lower, in case
        "server_pool_max_size" is kept high in order to face request bursts;
        a zero value means no idle threads allowed in the pool, though this
        is not recommended for performance reasons.
        Default: 10, if "server_pool_max_size" is not defined;
        otherwise, the same as "server_pool_max_size", unless the latter
        is set to 0, i.e. unlimited, in which case this setting is mandatory. -->
    <!--
    <server_pool_max_free>0</server_pool_max_free>
    -->

    <!--
        Optional. Maximum number of tasks allowed to be queued to enter
        the "SERVER" thread pool before undertaking backpressure actions.
        In particular, as long as the number is exceeded, the creation
        of new sessions will be refused and made to fail; additionally,
        the same action on the accept loops associated to the
        <accept_pool_max_queue> check will be performed (regardless
        that <accept_pool_max_queue> itself is set).
        A negative value disables the check.
        Default: 100. -->
    <!--
    <server_pool_max_queue>-1</server_pool_max_queue>
    -->

    <!--
        Optional. Maximum number of threads allowed for the "ACCEPT" internal
        pool, which is devoted to the parsing of the client requests.
        This task does not include blocking operations; however, on
        multiprocessor machines, allocating multiple threads for this task
        may be beneficial.
        Only in corner cases, it is possible that some operations turn
        out to be blocking; in particular:
        - getHostName, only if banned hostnames are configured;
        - socket close, only if banned hostnames are configured;
        - read from the "proxy protocol", only if configured;
        - service of requests on a "priority port", only available for
          internal use.
        A zero value means a potentially unlimited number of threads.
        Default: The number of available total cores, as detected by the JVM,
        which is also the minimum number of threads left in the pool. -->
    <!--
    <accept_pool_max_size>100</accept_pool_max_size>
    -->

    <!--
        Optional. Maximum number of tasks allowed to be queued to enter
        the "ACCEPT" thread pool before undertaking backpressure actions.
        The setting only affects the listening sockets with <port_type>
        configured as CREATE_ONLY. As long as the number is exceeded,
        the accept loops of these sockets will be kept waiting.
        By suspending the accept loop, some SYN packets from the clients may be
        discarded; the effect may vary depending on the backlog settings.
        Note that, in the absence of sockets configured as CREATE_ONLY,
        no backpressure action will take place.
        A long queue on the ACCEPT pool may be the consequence of a CPU
        shortage during (or caused by) a high client connection activity.
        A negative value disables the check.
        Default: -1. -->
    <!--
    <accept_pool_max_queue>100</accept_pool_max_queue>
    -->

    <!--
        Optional. Size of the "TLS-SSL HANDSHAKE" internal pool, which is
        devoted to the management of operations needed to accomplish TLS/SSL
        handshakes on the listening sockets specified through "https_server".
        In particular, this pool is only used when the socket is not configured
        to request the client certificate; in this case, the tasks are not
        expected to be blocking. Note that the operation may be CPU-intensive;
        hence, it is advisable to set a value smaller than the number of
        available cores.
        Default: Half the number of available total cores, as detected by the JVM
        (obviously, if there is only one core, the default will be 1). -->
    <!--
    <handshake_pool_size>10</handshake_pool_size>
    -->

    <!--
        Optional. Maximum number of tasks allowed to be queued to enter the
        "TLS-SSL HANDSHAKE" thread pool before undertaking backpressure actions.
        The setting only regards the listening sockets specified through
        "https_server" that are not configured to request the client certificate.
        More precisely:
        - If there are https sockets with <port_type> configured as CREATE_ONLY,
          then, as long as the number is exceeded, the accept loops of these
          sockets will be kept waiting.
          By suspending the accept loop, some SYN packets from the clients may be
          discarded; the effect may vary depending on the backlog settings.
        - Otherwise, if there are https sockets configured as CONTROL_ONLY and none
          is configured as the default GENERAL_PURPOSE, then, as long as the
          number is exceeded, the accept loops of these sockets will be kept
          waiting instead.
          Additionally, the same action on the accept loops associated to the
          <accept_pool_max_queue> check will be performed (regardless that
          <accept_pool_max_queue> itself is set). Note that the latter action
          may affect any kind of socket.
        Note that, in the absence of sockets configured as specified above,
        no backpressure action will take place.
        A negative value disables the check.
        Default: 100. -->
    <!--
    <handshake_pool_max_queue>-1</handshake_pool_max_queue>
    -->

    <!--
        Optional. Maximum number of threads allowed for the
        "TLS-SSL AUTHENTICATION" internal pool, which is used instead of the
        "TLS-SSL HANDSHAKE" pool for listening sockets that are configured
        to request the client certificate. This kind of task may exhibit
        a blocking behavior in some cases.
        A zero value means a potentially unlimited number of threads.
        Default: The same as configured for the SERVER thread pool. -->
    <!--
    <https_auth_pool_max_size>10</https_auth_pool_max_size>
    -->

    <!--
        Optional. Maximum number of idle threads allowed for the
        "TLS-SSL AUTHENTICATION" internal pool.
        It behaves in the same way as the "server_pool_max_free" setting.
        Default: The same as configured for the SERVER thread pool. -->
    <!--
    <https_auth_pool_max_free>0</https_auth_pool_max_free>
    -->

    <!--
        Optional. Maximum number of tasks allowed to be queued to enter
        the "TLS-SSL AUTHENTICATION" thread pool before undertaking
        backpressure actions.
        The effect is similar to the more common <handshake_pool_max_queue>,
        with the difference that it regards listening sockets specified through
        "https_server" that are configured to request the client certificate.
        A negative value disables the check.
        Default: 100. -->
    <!--
    <https_auth_pool_max_queue>-1</https_auth_pool_max_queue>
    -->

    <!--
        Optional. Maximum number of sessions that can be left in "prestarted"
        state, that is, waiting for the first bind or control operation.
        As long as the number is exceeded, the creation of new sessions
        will be refused and made to fail.
        The setting is meant to be used in configurations which define
        a CREATE_ONLY port in http and a CONTROL_ONLY port in https.
        In these cases, and when a massive client reconnection is occurring,
        the number of pending bind operations can grow so much that the
        needed TLS handshakes can take arbitrarily long and cause the
        clients to time-out and restart session establishment from scratch.
        However, consider that the presence of many clients that don't
        perform their bind in due time could keep other clients blocked.
        Note that, if defined, the setting will also inhibit
        <handshake_pool_max_queue> and <https_auth_pool_max_queue>
        from affecting the accept loop of CONTROL_ONLY ports in https. -->
    <!--
    <prestarted_max_queue>1000</prestarted_max_queue>
    -->

    <!--
        Optional. Policy to be adopted in order to manage the extraction
        of the field values from the item events and their conversion to
        a transferrable format.
        Can be one of the following:
        - Y: causes field conversion to be performed before the events
             are dispatched to the various sessions; this may lead to some
             wasted conversions, in case an event is filtered out later by all
             interested clients or in case a field is not subscribed to by any
             client.
             Note that events which don't provide an iterator (see the Data
             Adapter interface documentation) cannot be managed in this way.
        - N: causes field conversion to be performed only as soon as it is
             needed; in this case, as the same event object may be shared by
             many sessions, some synchronization logic is needed and this may
             lead to poor scaling in case many clients subscribe to the same
             item.
        Default: Y. -->
    <!--
    <force_early_conversions>N</force_early_conversions>
    -->

</mqttcool>
