General Settings and Logging
The <general> configuration element specifies ObjectDB settings that are relevant to both the server side and the client side.
The default configuration file contains the following <general> element:
<general> <temp path="$temp/ObjectDB" threshold="64mb" /> <network inactivity-timeout="0" /> <url-history size="50" user="true" password="true" /> <log path="$objectdb/log/" max="8mb" stdout="false" stderr="false" /> <log-archive path="$objectdb/log/archive/" retain="90" /> <logger name="*" level="info" /> </general>
The <temp> element
<temp path="$temp/ObjectDB" threshold="64mb" />
To meet memory constraints ObjectDB can use temporary files in processing of large data, such as query results that contain millions of objects.
The <temp> element specifies temporary file settings:
- The path attribute specifies a directory in which the temporary files are generated. The $temp prefix can be used to represent the system default temporary path, as demonstrated above.
- Using RAM is much faster than using temporary files. Therefore, temporary files are only used for data that exceeds a limit size that is specified by the threshold attribute. The mb and kb suffixes represent megabytes and kilobytes (respectively).
The <network> element
<network inactivity-timeout="0" />
The <network> element has one attribute, inactivity-timeout, which specifies when network sockets become obsolete as a result of inactivity. The value is the timeout in seconds, where 0 indicates never (no inactivity timeout).
The inactivity timeout (when > 0) is applied on both the server side and the client side, when using client-server mode, and has no effect in embedded mode.
Specifying an inactivity timeout may solve firewall related issues. In general, if the firewall enforces its own inactivity timeout on sockets a more restrictive inactivity timeout has to be specified for ObjectDB to avoid using sockets that are expired by the firewall.
The <url-history> element
<url-history size="50" user="true" password="true" />
ObjectDB manages a list of the recently accessed database urls for use by the Explorer.
- The size attribute specifies the maximum size of this list. This feature can be disabled by specifying 0 as the maximum list size.
- The user attribute specifies if user names should be saved with urls (in client server mode).
- The password attribute specifies if passwords should also be saved with urls.
Saving username and password with the url makes accessing recently used databases in the Explorer easier.
The <log> element
<log path="$objectdb/log/" max="8mb" stdout="false" stderr="false" />
General logging settings are specified in the <log> element:
- The path attribute specifies a directory in which the log files are generated. The $objectdb prefix can be used to represent the ObjectDB installation directory, as demonstrated above. If the path is empty ("") logging to file is disabled.
- Every day a new log file is generated with the name odb<yyyymmdd>.log (where <yyyymmdd> represents the date). A new log file is also generated when the log file exceeds the maximum size, which is specified by the max attribute.
- The stdout and stderr attributes specify if log messages should also be written to the standard output and the standard error (respectively) in addition to writing to the log file.
The <log-archive> element
<log-archive path="$objectdb/log/archive/" retain="90" />
Old log files are moved to an archive directory.
The <log-archive> element specifies the logging archive settings:
- The path attribute specifies an archive directory.
- The retain attribute specifies how many days to keep the archived log files. After that period an archived log file is automatically deleted.
The <logger> elements
<logger name="*" level="info" />
<logger> elements specify logging levels. The "*" logger, which can be shown in the default configuration above, represents the entire ObjectDB system.
Additional <logger> elements can be added to override the default logging level for a specific ObjectDB subsystem. The names of the subsystem loggers are currently undocumented and can change at any time without notice.
The supported logging levels are: