Nexus configuration

Nexus Delta service can be highly customized using configuration file(s). Many things can be adapted to your deployment needs: port where the service is running, timeouts, pagination defaults, etc.

There are 3 ways to modify the default configuration:

  • Setting the env variable DELTA_EXTERNAL_CONF which defines the path to a HOCON file. The configuration keys that are defined here can be overridden by the other methods.
  • Using JVM properties as arguments when running the service: -D{property}. For example: -Dapp.http.interface="127.0.0.1".
  • Using FORCE_CONFIG_{property} environment variables. In order to enable this style of configuration, the JVM property -Dconfig.override_with_env_vars=true needs to be set. Once set, a configuration flag can be overridden. For example: CONFIG_FORCE_app_http_interface="127.0.0.1".

In terms of JVM pool memory allocation, we recommend setting the following values to the JAVA_OPTS environment variable: -Xms4g -Xmx4g. The recommended values should be changed accordingly with the usage of Nexus Delta, the number of projects and the resources/schemas size.

In order to successfully run Nexus Delta there is a minimum set of configuration flags that need to be specified

Http configuration

The http section of the configuration defines the binding address and port where the service will be listening.

The configuration flag akka.http.server.parsing.max-content-length can be used to control the maximum payload size allowed for Nexus Delta resources. This value applies to all posted resources except for files.

Postgres configuration

The database section of the configuration defines the postgres specific configuration. As Nexus Delta uses three separate pools (‘read’, ‘write’, ‘streaming’), it is recommended to set the host, port, database name, username, and password via the app.defaults.database field, as it will apply to all pools. It is however possible to accommodate more advanced setups by configuring each pool separately by changing its respective app.database.{read|write|streaming} fields.

The pool size can be set using the app.defaults.database.access.pool-size setting for all pools, or individually for each pool (app.database.{read|write|streaming}.access.pool-size).

Note

A default Postgres deployment will limit the number of connections to 100, unless configured otherwise. See the Postgres Connection and Authentication documentation.

Before running Nexus Delta, the expected tables should be created.

It is possible to let Nexus Delta automatically create them using the following configuration parameters: app.database.tables-autocreate=true.

Note

Auto creation of tables is included as a development convenience and should be avoided in production.

RDF parser

The underlying Apache Jena parser used to validate incoming data is configurable using the json-ld-api field to enable different levels of strictness.

Service account configuration

Nexus Delta uses a service account to perform automatic tasks under the hood. Examples of it are:

  • Granting default ACLs to the user creating a project.
  • Creating default views on project creation.

The service-account section of the configuration defines the service account configuration.

Automatic project provisioning

Automatic project provisioning allows to create a dedicated project for users the first time they connect to Delta that is to say the first time, they query the project listing endpoints.

The generated project label will be:

  • The current username where only non-diacritic alphabetic characters ([a-zA-Z]), numbers, dashes and underscores will be preserved.
  • This resulting string is then truncated to 64 characters if needed.

This feature can be turned on via the flag app.automatic-provisioning.enabled.

The automatic-provisioning section of the configuration defines the project provisioning configuration.

Encryption configuration

Nexus Delta uses symmetric encryption to secure sensitive data information (tokens and passwords).

The encryption section of the configuration defines the encryption configuration.

Fusion configuration

When fetching a resource, Nexus Delta allows to return a redirection to its representation in Fusion by providing text/html in the Accept header.

The fusion section of the configuration defines the fusion configuration.

Projections configuration

Projections in Nexus Delta are asynchronous processes that can replay the event log and process this information. For more information on projections, please refer to the Architecture page.

The projections section of the configuration allows to configure the projections.

In case of failure in a projection, Nexus Delta records the failure information inside the public.failed_elem_logs PostgreSQL table, which can be used for analysis, and ultimately resolution of the failures. The configuration allows to set how long the failure information is stored for (app.projections.failed-elem-ttl), and how often the projection deleting the expired failures is awoken (app.projections.delete-expired-every).

Plugins configuration

Since 1.5.0, Nexus Delta supports plugins. Jar files present inside the local directory defined by the DELTA_PLUGINS environment variable are loaded as plugins into the Delta service.

Each plugin configuration is rooted under plugins.{plugin_name}. All plugins have a plugins.{plugin_name}.priority configuration flag used to determine the order in which the routes are handled in case of collisions.

For more information about plugins, please refer to the Plugins page.

Elasticsearch views plugin configuration

The elasticsearch plugin configuration can be found here.

The most important flags are: * plugins.elasticsearch.base which defines the endpoint where the Elasticsearch service is running. * plugins.elasticsearch.credentials.username and plugins.elasticsearch.credentials.password to allow to access to a secured Elasticsearch cluster. The user provided should have the privileges to create/delete indices and read/index from them.

Please refer to the Elasticsearch configuration which describes the different steps to achieve this.

Blazegraph views plugin configuration

The blazegraph plugin configuration can be found here.

The most important flag is plugins.blazegraph.base which defines the endpoint where the Blazegraph service is running.

The plugins.blazegraph.slow-queries section of the Blazegraph configuration defines what is considered a slow Blazegraph query, which will get logged in the public.blazegraph_queries PostgreSQL table. This can be used to understand which Blazegraph queries can be improved.

Composite views plugin configuration

The composite views plugin configuration can be found here.

There are several configuration flags related to tweaking the range of values allowed for sources, projections and rebuild interval.

Storage plugin configuration

The storage plugin configuration can be found here.

Nexus Delta supports 3 types of storages: ‘disk’, ‘amazon’ (s3 compatible) and ‘remote’.

  • For disk storages the most relevant configuration flag is plugins.storage.storages.disk.default-volume, which defines the default location in the Nexus Delta filesystem where the files using that storage are going to be saved.
  • For S3 compatible storages the most relevant configuration flags are the ones related to the S3 settings: plugins.storage.storages.amazon.default-endpoint, plugins.storage.storages.amazon.default-access-key and plugins.storage.storages.amazon.default-secret-key.
  • For remote disk storages the most relevant configuration flags are plugins.storage.storages.remote-disk.default-endpoint (the endpoint where the remote storage service is running) and plugins.storage.storages.remote-disk.default-credentials (the Bearer token to authenticate to the remote storage service).

Archive plugin configuration

The archive plugin configuration can be found here.

Jira plugin configuration

The Jira plugin configuration can be found here.

Setting up the Jira plugin needs to set up the endpoint of the Jira instance but also the consumer key, the consumer secret and the private key required to interact with Jira (more details including the configuration steps in Jira here).

Monitoring

For monitoring, Nexus Delta relies on Kamon.

Kamon can be disabled by passing the environment variable KAMON_ENABLED set to false.

Delta configuration for Kamon is provided in the monitoring section. For a more complete description on the different options available, please look at the Kamon website.

Instrumentation

Delta provides the Kamon instrumentation for:

Reporters

Kamon reporters are also available for: