Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2922#discussion_r205885249
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3074,69 +3178,69 @@
nifi.provenance.repository.encryption.key=0123456789ABCDEFFEDCBA9876543210012345
The Component Status Repository contains the information for the Component
Status History tool in the User Interface. These
properties govern how that tool works.
-The buffer.size and snapshot.frequency work together to determine the
amount of historical data to retain. As an example to
+The `buffer.size` and `snapshot.frequency` work together to determine the
amount of historical data to retain. As an example to
configure two days worth of historical data with a data point snapshot
occurring every 5 minutes you would configure
snapshot.frequency to be "5 mins" and the buffer.size to be "576". To
further explain this example for every 60 minutes there
are 12 (60 / 5) snapshot windows for that time period. To keep that data
for 48 hours (12 * 48) you end up with a buffer size
of 576.
|====
|*Property*|*Description*
-|nifi.components.status.repository.implementation|The Component Status
Repository implementation. The default value is
`org.apache.nifi.controller.status.history.VolatileComponentStatusRepository`
and should not be changed.
-|nifi.components.status.repository.buffer.size|Specifies the buffer size
for the Component Status Repository. The default value is `1440`.
-|nifi.components.status.snapshot.frequency|This value indicates how often
to present a snapshot of the components' status history. The default value is
`1 min`.
+|`nifi.components.status.repository.implementation`|The Component Status
Repository implementation. The default value is
`org.apache.nifi.controller.status.history.VolatileComponentStatusRepository`
and should not be changed.
+|`nifi.components.status.repository.buffer.size`|Specifies the buffer size
for the Component Status Repository. The default value is `1440`.
+|`nifi.components.status.snapshot.frequency`|This value indicates how
often to present a snapshot of the components' status history. The default
value is `1 min`.
|====
[[site_to_site_properties]]
=== Site to Site Properties
These properties govern how this instance of NiFi communicates with remote
instances of NiFi when Remote Process Groups are configured in the dataflow.
-Remote Process Groups can choose transport protocol from RAW and HTTP.
Properties named with _nifi.remote.input.socket.*_ are RAW transport protocol
specific. Similarly, _nifi.remote.input.http.*_ are HTTP transport protocol
specific properties.
+Remote Process Groups can choose transport protocol from RAW and HTTP.
Properties named with `nifi.remote.input.socket.`* are RAW transport protocol
specific. Similarly, `nifi.remote.input.http.`* are HTTP transport protocol
specific properties.
|====
|*Property*|*Description*
-|nifi.remote.input.host|The host name that will be given out to clients to
connect to this NiFi instance for Site-to-Site communication. By default, it is
the value from InetAddress.getLocalHost().getHostName(). On UNIX-like operating
systems, this is typically the output from the `hostname` command.
-|nifi.remote.input.secure|This indicates whether communication between
this instance of NiFi and remote NiFi instances should be secure. By default,
it is set to `false`. In order for secure site-to-site to work, set the
property to `true`. Many other Security Properties (below) must also be
configured.
-|nifi.remote.input.socket.port|The remote input socket port for
Site-to-Site communication. By default, it is blank, but it must have a value
in order to use RAW socket as transport protocol for Site-to-Site.
-|nifi.remote.input.http.enabled|Specifies whether HTTP Site-to-Site should
be enabled on this host. By default, it is set to `true`. +
+|`nifi.remote.input.host`|The host name that will be given out to clients
to connect to this NiFi instance for Site-to-Site communication. By default, it
is the value from InetAddress.getLocalHost().getHostName(). On UNIX-like
operating systems, this is typically the output from the `hostname` command.
+|`nifi.remote.input.secure`|This indicates whether communication between
this instance of NiFi and remote NiFi instances should be secure. By default,
it is set to `false`. In order for secure site-to-site to work, set the
property to `true`. Many other Security Properties (below) must also be
configured.
+|`nifi.remote.input.socket.port`|The remote input socket port for
Site-to-Site communication. By default, it is blank, but it must have a value
in order to use RAW socket as transport protocol for Site-to-Site.
+|`nifi.remote.input.http.enabled`|Specifies whether HTTP Site-to-Site
should be enabled on this host. By default, it is set to `true`. +
Whether a Site-to-Site client uses HTTP or HTTPS is determined by
`nifi.remote.input.secure`. If it is set to `true`, then requests are sent as
HTTPS to `nifi.web.https.port`. If set to `false`, HTTP requests are sent to
`nifi.web.http.port`.
-|nifi.remote.input.http.transaction.ttl|Specifies how long a transaction
can stay alive on the server. By default, it is set to `30 secs`. +
+|`nifi.remote.input.http.transaction.ttl`|Specifies how long a transaction
can stay alive on the server. By default, it is set to `30 secs`. +
If a Site-to-Site client hasnât proceeded to the next action after this
period of time, the transaction is discarded from the remote NiFi instance. For
example, when a client creates a transaction but doesnât send or receive flow
files, or when a client sends or receives flow files but doesnât confirm that
transaction.
-|nifi.remote.contents.cache.expiration|Specifies how long NiFi should
cache information about a remote NiFi instance when communicating via
Site-to-Site. By default, NiFi will cache the +
+|`nifi.remote.contents.cache.expiration`|Specifies how long NiFi should
cache information about a remote NiFi instance when communicating via
Site-to-Site. By default, NiFi will cache the +
responses from the remote system for `30 secs`. This allows NiFi to avoid
constantly making HTTP requests to the remote system, which is particularly
important when this instance of NiFi +
has many instances of Remote Process Groups.
|====
[[site_to_site_reverse_proxy_properties]]
=== Site to Site Routing Properties for Reverse Proxies
-Site-to-Site requires peer-to-peer communication between a client and a
remote NiFi node. E.g. if a remote NiFi cluster has 3 nodes, nifi0, nifi1 and
nifi2, then a client requests have to be reachable to each of those remote node.
+Site-to-Site requires peer-to-peer communication between a client and a
remote NiFi node. E.g. if a remote NiFi cluster has 3 nodes (nifi0, nifi1 and
nifi2) then a client requests have to be reachable to each of those remote node.
If a NiFi cluster is planned to receive/transfer data from/to Site-to-Site
clients over the internet or a company firewall, a reverse proxy server can be
deployed in front of the NiFi cluster nodes as a gateway to route client
requests to upstream NiFi nodes, to reduce number of servers and ports those
have to be exposed.
In such environment, the same NiFi cluster would also be expected to be
accessed by Site-to-Site clients within the same network. Sending FlowFiles to
itself for load distribution among NiFi cluster nodes can be a typical example.
In this case, client requests should be routed directly to a node without going
through the reverse proxy.
-In order to support such deployments, remote NiFi clusters need to expose
its Site-to-Site endpoints dynamically based on client request contexts.
Following properties configure how peers should be exposed to clients. A
routing definition consists of 4 properties, 'when', 'hostname', 'port', and
'secure', grouped by 'protocol' and 'name'. Multiple routing definitions can be
configured. 'protocol' represents Site-to-Site transport protocol, i.e. raw or
http.
+In order to support such deployments, remote NiFi clusters need to expose
its Site-to-Site endpoints dynamically based on client request contexts.
Following properties configure how peers should be exposed to clients. A
routing definition consists of 4 properties, `when`, `hostname`, `port`, and
`secure`, grouped by `protocol` and `name`. Multiple routing definitions can be
configured. `protocol` represents Site-to-Site transport protocol, i.e. raw or
http.
--- End diff --
The values `raw` and `http` should be code formatted.
---
