You can use custom server settings to configure the Runtime beyond the standard possibilities offered by the Modeler.

Only use this functionality if you know exactly what you are doing. Wrong values can prevent the Runtime from starting.

Each custom setting consists of a name and a value. For example, to enable persistent sessions you add a custom setting with name PersistentSessions and value true.

General settings

The following custom settings can be configured:

NameDescriptionDefault value
TempPathThe location of the temporary files.[deployment folder]\data\tmp
UploadedFilesPathThe location of the uploaded files. A valid path can be: \\FileServer\CustomerPortalFiles.[deployment folder]\data\files
ScheduledEventExecutionSpecify which scheduled events should be executed. Choices are 'ALL', 'NONE' or 'SPECIFIED'. In case of 'SPECIFIED' enumerate the scheduled events using the 'MyScheduledEvents' configuration option described below.NONE
MyScheduledEventsA comma-separated string with the names of the events. Please don't forget the name of the module. A name can be CRM.UpdateCustomerStatistics. 
PersistentSessionsDefines whether sessions will be persisted in the database or not. When sessions are persisted, statistics will be made about logged-in users. When the Runtime server restarts, sessions still exist and users don't have to log in again. However, making sessions persistent can have a negative influence on the speed of the application.
The value can be true or false.
false
TrackWebServiceUserLastLoginDefines whether to update the web service user's 'LastLogin' field on each login. When this happens a database update query has to be sent and this can have performance consequences on heavy load systems. When this setting is set to false, no database interaction is necesssary.true
ReadCommittedSnapshotDefines whether the READ_COMMITTED_SNAPSHOT option of Microsoft SQL Server must be enabled or not. See for more information: Using Snapshot Isolation.
The value can be true or false.
true
JavaKeyStorePasswordPassword for the default Java keystore.changeit
CACertificatesComma separated list of paths to Authority Certificates. 
ClientCertificates

Comma separated list of paths to Client Certificates.

Example:

D:\App\Mx1.pfx,
D:\App\Mx2.pfx,
D:\App\Mx3.pfx,
D:\App\Mx4.pfx
 
ClientCertificatePasswords

Comma separated list of passwords for Client Certificates (should match the "ClientCertificates" order).

Example:

pwd1, pwd2, pwd3, pwd4
 
WebServiceClientCertificates

Defines which web service must use which client certificate. The value of this setting must be a comma separated list of key/value items. A key/value item must be specified as [imported web service name:"path to certificate"] without brackets. Please note that any backslash in the path must be doubled. The whole value must be enclosed by braces.

Example:

{
    Module.WebService2: "D:\\App\\Mx2.pfx",
    Module.WebService3: "D:\\App\\Mx3.pfx"
} 
 
OracleServiceNameDefines the SERVICE_NAME when you have a connection with
an Oracle DBMS.
 
DatabaseJdbcUrlDefines the JDBC URL to use for the database connection (which overrides the other database connection settings). This feature is not supported for PostgreSQL databases. 
SessionTimeoutDefines after how much timea session becomes invalid. After that timeout a session becomes applicable for removal. The session won't be destroyed until the next time the cluster manager evaluates the active sessions.600000
ClusterManagerActionInterval

The interval (in miliseconds) used for performing all cluster manager actions. These actions include, unblocking users, and removing invalid sessions.

If nothing is specified the interval is half the SessionTimeout.

300000
DatabaseUseSslFor PostgreSQL databases, defines whether the connection will be made using SSL.false
ClientQueryTimeoutDefines the timeout in seconds for most of the database queries which are executed to load data into client widgets, like data grids. After the duration as specified here, a query will be canceled and an exception will be thrown. 
com.mendix.core.StorageServiceDefines which storage service module will be used. The storage service module takes care of storing the actual files asssociated with 'System.FileDocument' objects, such as uploaded files. Possible values are currently 'com.mendix.storage.localfilesystem' and 'com.mendix.storage.s3'.com.mendix.storage.localfilesystem
com.mendix.core.SessionIdCookieNameDefines the name of the cookie value which represents the session id. Can be useful to change when running in a container which assumes a certain name for the session cookie (e.g. Pivotal assumes 'JSESSIONID' as session cookie name).XASSESSIONID

Log file settings

The settings below influence the behavior of the log files. These settings can only be used on-premises. In the cloud these won’t result in a difference in behavior.

NameDescriptionDefault value
LogFileNameThe name of the log file. The log files (actual log file plus back-up files) will be placed in the folder specified by the setting Log Path.Application.log
MaxLogFileSizeThe maximum size per log file. When the log file has been reached this maximum size, the log file will be backed up and a new empty log file will be used.2097152 (2 MB)
MaxLogFileCountThe maximum count of log files preserved (actual file plus back-up files). When the maximum count has been reached, the oldest backup file will be removed.10
LogMinDurationQueryDefines whether database queries are logged via the ConnectionBus_Queries log node if they finished after the amount of milliseconds specified here.
By default, only the concerning SQL query will be logged. Set the log level of the ConnectionBus_Queries log node to TRACE to show more information about the form or the microflow which leads to this query.
 

Database settings

The settings below are used to define the database connection pooling behavior. The Runtime uses a pool of reusable database connections. You can for example define how many connections can be used. Connection pooling is implemented using the Apache Commons Object-pooling API .

NameValueDefault value
ConnectionPoolingMaxWaitWhen the maximum number of "active" objects has been reached, the pool is said to be 'exhausted'. The "when exhausted" action used by the Connection Bus is WHEN_EXHAUSTED_BLOCK
Sets the maximum amount of time (in milliseconds) the borrowObject() method should block before throwing an exception when the pool is exhausted. When less than or equal to 0, the borrowObject() method may block indefinitely. (!)
10000
ConnectionPoolingMaxActiveSets the cap on the total number of active instances from the pool.50
ConnectionPoolingMaxIdleSets the cap on the number of "idle" instances in the pool.50 (since Mendix 3.3, 20 before Mendix 3.3)
ConnectionPoolingMinIdleSets the minimum number of objects allowed in the pool before the evictor thread (if active) spawns new objects. Note that no objects are created when numActive + numIdle >= maxActive.  This setting has no effect if the idle object evictor is disabled (i.e. if timeBetweenEvictionRunsMillis <= 0).0
ConnectionPoolingTimeBetweenEvictionRunsMillisSets the number of milliseconds to sleep between runs of the idle object evictor thread. When non-positive, no idle object evictor thread will be run.300 000
(5 minutes)
ConnectionPoolingSoftMinEvictableIdleTimeMillisSets the minimum amount of time an object may sit idle in the pool before it is eligible for eviction by the idle object evictor (if any), with the extra condition that at least "minIdle" amount of object remain in the pool. When non-positive, no objects will be evicted from the pool due to idle time alone.300 000
(5 minutes)
ConnectionPoolingNumTestsPerEvictionRunSets the max number of objects to examine during each run of the idle object evictor thread (if any).
When a negative value is supplied, ceil(getNumIdle())/abs(getNumTestsPerEvictionRun()) tests will be run. I.e., when the value is -n, roughly one nth of the idle objects will be tested per run.
-3

Amazon S3 storage service settings

The following settings influence the behavior of the Amazon S3 Storage Service module.

NameDescriptionDefault value
com.mendix.storage.s3.AccessKeyIdActs as the username to authenticate with the Amazon S3 service. 
com.mendix.storage.s3.SecretAccessKeyActs as the password to authenticate with the Amazon S3 service. 
com.mendix.storage.s3.BucketNameName of the bucket where the files are stored on S3. 
com.mendix.storage.s3.ResourceNameSuffixSuffix for the keys under which objects are stored. This can be used when buckets are divided in different segments for different users with different credentials (e.g. store objects as "[key].customer1" for customer1 and as "[key].customer2" for customer2) 
com.mendix.storage.s3.PerformDeleteFromStorageDefines whether a delete of a Mendix File Document should result in an actual delete in the storage service. A reason to not perform an actual delete in the storage service can be when it's also used as a backup service.true
com.mendix.storage.s3.EndPointOverrides the default AWS endpoint. Use this setting when the storage service is on a non-AWS location. Both the endpoint (e.g. 's3.example.com') or the full URL, including the protocol, are supported (e.g. 'https://s3.example.com'). Note that when setting a custom endpoint path style access will be enabled. Click here for more information. 
com.mendix.storage.s3.UseV2AuthLet the authentication policy use 'Signature Version 2' instead of the default 'Signature Version 4'. Set this setting to 'true' when the endpoint does not support 'Signature Version 4'.false
com.mendix.storage.s3.EncryptionKeys

List of keys which can be used to encrypt and decrypt data at rest in S3\. The right key to decrypt the data with is automatically selected depending on with which key it was encrypted.
Each encryption key consists of a key id, the encryption algorithm and the actual key (Base64 encoded).

Example:

[
  { 
    keyID: "first", 
    algorithm: "AES256", 
    key: "MENDMTc1QjlDMEYxQjZBODMxQzM5OUUyNjk3NzI2NjFDRUM1MjBFQTUxRUEwQTQ3RTg3Mjk1RkEzMjQ1QTYwNQ=="
  },  
  { 
    keyID: "second", 
    algorithm: "DESede", 
    key: "MEVFQTE5QkQxNTEyRTFEMTJEODFEMTkwNzVDRTZERUVGRjIyMzRBQUI2MDI5QTA1"
  }
] 
 

Web client settings

The following settings influence the behavior of the Mendix web client.

NameDescriptionDefault value
EnableKeepAlive

Defines whether the web client sends a keep alive request every SessionTimeout/2 milliseconds, to prevent a session timeout.

Each click in the browser also acts as KeepAlive. Disabling this property will result in a user being logged out automatically after 10 minutes of inactivity, even if the browser remains open.

true
PhoneUserAgentRegExDefines the regular expression that is used to determine whether a user is visiting a Mendix application from a phone. The regular expression is matched against the User-Agent header sent by the client's web browser.Android.*Mobile|iPhone|iPod|BlackBerry
TabletUserAgentRegExDefines the regular expression that is used to determine whether a user is visiting a Mendix application from a tablet. The regular expression is matched against the User-Agent header sent by the client's web browser.Android|iPad

Parallelism settings

This setting is only relevant for Mendix 5.19 and higher. Adjusting parallelism setting parameters may drastically impact your system behaviour and performance. Only advanced users should modify these parameters.

Internally Mendix uses an actor system to dispatch and process requests. This actor system uses a thread pool to process these requests in parallel. The amount of parallelism / number of threads provided by this thread pool is configurable.

Configuring the parallelism can be done by specifying the following JVM parameter:

-Dmendix.action.parallelism=300

This parameter specifies the number of threads the thread pool can assign to execute requests concurrently. The default value is 300.

The default value should be more than enough for most use cases. If your application experiences extremely high load and it runs out of threads you can try to increase this number.

If you want to inspect the configuration being used, you can set the system or config property ‘akka.log-config-on-start’ to ‘on’. This will then print the complete configuration at INFO level when the actor system is started.