.fi
&h1(Configuration and Control)
-With the assumption that most RMR based applications will be executed in a containerised
-environment, there are some underlying mechanics which the developer may need to know
-in order to properly provide a configuration specification to the container management
-system.
-The following paragraphs briefly discuss these.
+With the assumption that most RMR based applications will be executed
+in a containerised environment, there are some underlying mechanics
+which the developer may need to know in order to properly provide a
+configuration specification to the container management system. The
+following paragraphs briefly discuss these.
.sp .1
&h2(TCP Ports)
-RMR requires two (2) TCP listen ports: one for general application to application communications
-and one for route table updates.
-The general communication port is specified by the application at the time RMR is initialised.
-The port used to listen for route table updates is likely to be a constant port shared by all
-applications provided they are running in separate containers.
-To that end, the port number defaults to 4561, but can be configured with an environment variable
-(see later paragraph in this section).
+RMR requires two (2) TCP listen ports: one for general
+application-to-application communications and one for route-table
+updates. The general communication port is specified by the
+application at the time RMR is initialised. The port used to listen
+for route table updates is likely to be a constant port shared by all
+applications provided they are running in separate containers. To
+that end, the port number defaults to 4561, but can be configured with
+an environment variable (see later paragraph in this section).
&h2(Host Names)
-RMR is typically host name agnostic.
-Route table entries may contain endpoints defined either by host name or IP address.
-In the container world the concept of a &ital(service name) might exist, and likely is different
-than a host name.
-RMR's only requirement with respect to host names is that a name used on a route table entry must
-be resolvable via the &cw(gethostbyname) system call.
+RMR is typically host name agnostic. Route table entries may contain
+endpoints defined either by host name or IP address. In the container
+world the concept of a &ital(service name) might exist, and likely is
+different than a host name. RMR's only requirement with respect to
+host names is that a name used on a route table entry must be
+resolvable via the &cw(gethostbyname) system call.
&h2(Environment Variables)
-Several environment variables are recognised by RMR which,
-in general, are used to define interfaces and listen ports (e.g. the route table update
-listen port), or debugging information.
-Generally this information is system controlled and thus RMR expects this information to
-be defined in the environment rather than provided by the application.
-The following is a list of the environment variables which RMR recognises:
+Several environment variables are recognised by RMR which, in general,
+are used to define interfaces and listen ports (e.g. the route table
+update listen port), or debugging information. Generally this
+information is system controlled and thus RMR expects this information
+to be defined in the environment rather than provided by the
+application. The following is a list of the environment variables
+which RMR recognises:
&half_space
.st 8p
&di(RMR_SEED_RT) Where RMR expects to find the name of the seed (static) route table. If not defined no static table is read.
&half_space
- &di(RMR_RTG_ISRAW) If the value set to 0, RMR expects the route table manager messages to be messages with and RMR header.
+ &di(RMR_RTG_ISRAW) If the value set to 0, RMR expects the route table manager messages to be messages with and RMR header.
If this is not defined messages are assumed to be "raw" (without an RMR header.
&half_space
- &di(RMR_VCTL_FILE) Provides a file which is used to set the verbose level of the route table collection thread.
- The first line of the file is read and expected to contain an integer value to set the verbose level.
+ &di(RMR_VCTL_FILE) Provides a file which is used to set the verbose level of the route table collection thread.
+ The first line of the file is read and expected to contain an integer value to set the verbose level.
The value may be changed at any time and the route table thread will adjust accordingly.
&half_space
&space
&h2(Logging)
-RMR does &bold(not) use any logging libraries; any error or warning messages are written to standard error.
-.if false
+RMR does &bold(not) use any logging libraries; any error or warning messages are written to standard error.
+.if false
¬e .sm .
.cn l=&cn_line_len i=0 start &atbot Times-roman 8p .7i
This is standard practice for container based applications as it makes error output easily available to operations.
&half_space
&di(^[ERR]) The event is not expected and RMR is not able to handle it. There is a small chance that continued operation
- will be negatively impacted.
+ will be negatively impacted.
Eventual action to diagnose and correct the issue will be necessary.
&half_space
Code Review / ric-plt / lib / rmr.git / blobdiff