Skip to content

Configuration

Overview

RSB is configured with a unique JSON file named rsb-configuration.json, which must be located either in /etc/rsb or at the root of the JVM classpath (for example, in Tomcat's lib directory).

Samples

Here are a few examples of configuration files:

Default Configuration

If RSB can't locate a configuration file, it will try to generate one (named rsb-configuration.json, as above) and store it either in /etc/rsb or in WEB-INF/classes. Here is the content of the default configuration:

In this configuration, $RSB_HOME$ is replaced by either, and in order of preference:

  • The user's home directory, if it exists and is writeable,
  • The rsb.war WEB-INF directory, if it is writeable,
  • The operating system temporary directory

If RSB generates such a default configuration file in WEB-INF/classes, it is recommended to review it so it uses the desired values and move it to /etc/rsb, as discussed in the previous section.

Full Reference

nodeName

administratorEmail

catalogRootDirectory

activeMqWorkDirectory

checkHealthOnStart

defaultRserviPoolUri

applicationSpecificRserviPoolUris

For a single pool dedicated to a single app, use

"applicationSpecificRserviPoolUris": {
    "great_application": "rmi://127.0.0.1/other-pool"
}

For multiple pools for a single app, use:

"applicationSpecificRserviPoolUris": {
    "great_application": ["rmi://127.0.0.1/other-pool", "rmi://127.0.0.1/yet-another-pool"]
}

The strategy for picking up one RServi pool among the configured simply uses a circular buffer to cycle through the configured RMI addresses per app.

jobTimeOut

A job submitted by RSB to RPooli will timeout after the number of milliseconds specified in jobTimeout. The default value is 600000 or 10 minutes.

numberOfConcurrentJobWorkersPerQueue

resultsDirectory

smtpConfiguration

jmxConfiguration

depositRootDirectories

depositEmailAccounts

jobStatisticsHandlerConfiguration

dataDirectories

rServiClientPoolConfig

rServiClientPoolValidationStrategy

RSB will validate nodes on take and on return from the RPooli pool. It is possible, though, to reduce the level of validation in order to gain speed in performance-critical environments. This validation uses a combination of Commons Pool validation features and RSB proper validations. Three options are available:

  • NONE: no validation whatsoever,
  • ADAPTIVE: validate nodes on take and return with isOpen, validate with 1+1 nodes on return that have experienced any exception,
  • FULL: validate on take and return with 1+1.

applicationSecurityConfiguration

rsbSecurityConfiguration

application level security

The following demonstrates how to configure RSB application level security:

    "applicationSecurityConfiguration": {
      "secure_app_1": {
        "userPrincipals":["bob","dan"]
      },
      "secure_app_2": {
        "userRoles":["ROLE_SCIENTIST","ROLE_ANALYST"]
      },
      "secure_app_3": {
        "userPrincipals":["bob","dan"],
        "userRoles":["ROLE_SCIENTIST","ROLE_ANALYST"]
      },
      "secure_app_4": {
        "userPrincipals":["bob","dan"],
        "userRoles":["ROLE_SCIENTIST","ROLE_ANALYST"],
        "functionCallAllowed": true,
        "scriptSubmissionAllowed": true
      },
      "secure_app_5": {
        "userPrincipals":["bob","dan"],
        "userRoles":["ROLE_SCIENTIST","ROLE_ANALYST"],
        "adminPrincipals":["jack"],
        "adminRoles":["ROLE_ADMIN"]
      }
    }

Application admins, declared with adminPrincipals and adminRoles are de-facto users of the concerned application.

Notice how the functionCallAllowed and scriptSubmissionAllowed attributes are used to explicitly allow the users of secure_app_4 to execute jobs that can potentially impact the environment where R executes. This is disabled by default. Application admins are not affected by these flags.

RSB admin security

The following demonstrates how to configure the optional RSB admin roles roles:

    "rsbSecurityConfiguration": {
        "adminPrincipals":["joe"],
        "adminRoles":["ROLE_ADMIN"]
    }

Note:

  • RSB admins are de-facto users and admins of all the applications.

applicationAwareCatalog

In a secure environment, it can be desirable to partition the catalog per application name. This prevents one application or one application admin to read or write files in another application.

This option, which is off by default, is activated with the following configuration setting:

    "applicationAwareCatalog" : true

propagateSecurityContext