Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
722 lines (677 sloc) 31.3 KB
#
# This file documents configuration options that can be set in the m2ee
# configuration file.
#
# This file is in YAML format (see: http://yaml.org/), a simple but very
# effective data serialization format which is easily human readable/writable as
# well.
#
# Basic YAML constructs are:
#
# # this is a comment, the next line contains a simple key/value pair:
# key: value
#
# dictionary:
# key1: value1
# key2: value2
# key3: # this is a list
# - item1
# - item2
# - item3
# key4: [another, way, to, specify, a, list]
# key5: [
# also,
# a,
# list
# ]
# key6:
# - # a list containing dictionaries
# subkey: subvalue
# subkey2: subvalue2
# -
# subkeyinlistitem2: value
# anotherkeyinlistitem2: anothervalue
#
# The indentation level of one space is used a lot, as you can see. Most values
# don't need quotes around them in yaml, but it doesn't hurt to use them. A
# colon (:) for example, can't be used without quoting. Also, when text
# highlighting of your editor starts to get fancy, you might use some extra
# quotes. :-)
#
# By default, the m2ee program tries to load configuration from the locations
# /etc/m2ee/m2ee.yaml and ~/.m2ee/m2ee.yaml
#
# Instead of the above defaults, it is possible to specify one or more
# configuration files using the -c parameter when starting m2ee. If the -c
# option is used more than once, configuration file content will be deep-merged.
#
# The configuration in /etc/ can be used to set server-wide configuration
# options without having to specify them again for each user. (if you run
# multiple applications on a single operating system installation, which is
# perfectly possible).
#
# In configuration options explained below, the uncommented shown values are in
# most cases not default values, but just an example value. When an option has
# a default value, this is explained in the text.
#
mxnode:
# mxjar_repo can be a single location, or a list of locations which need to be
# searched for installed Mendix Runtime versions.
#
# It is highly recommended to not set this option, but let it default to the
# 'runtimes' directory under the app_base location, as specified in the m2ee
# section below, so the user can use the download_runtime command to install
# mendix runtime versions.
#
mxjar_repo: /usr/local/share/mendix/
# or, when specifying multiple locations:
#mxjar_repo: ["/opt/mendix/runtime/", "/usr/local/share/mendix/"]
#
# When starting an application that has been created using version 7.7.1 of
# the Mendix Business Modeler, the following location would be checked for
# existence: /usr/local/share/mendix/7.7.1/ when the first configuration
# example above is used.
#
# If a 'runtimes' directory exists under the app_base location, as specified
# in the m2ee section below, it will be inserted at the front of the
# mxjar_repo automatically, to facilitate runtime downloads on demand.
# The download_runtime_url configures the location on which releases of the
# Mendix Runtime are provided for downloading on demand. When this option is
# configured, the download_runtime command can be used to install a missing
# Runtime version onto the local system, into the first mxjar_repo location
# which is writable by the system user account that is executing the command.
#
# It is recommended to not set this option, so the built-in default will be
# used.
#
# default: "https://download.mendix.com/runtimes/"
download_runtime_url: "https://download.mendix.com/runtimes/"
# When using PostgreSQL as database, the m2ee program contains functionality to
# quickly dump or restore a database snapshot to the data/database directory of
# the project, or empty the complete database (e.g. before restoring an old
# dump). The following configuration options can override the specific programs
# that are used when executing these commands. During a transition when moving
# from e.g. PostgreSQL 8.4 to 9.2 this can be used to always dump databases
# using 8.4 and restore them using 9.2 client tools.
#
# Note: not all operating system distributions support running different
# PostgreSQL versions at the same time on a server, so YMMV.
#
# default: just search for the default programs on the current OS search path
pg_dump: /usr/lib/postgresql/8.4/bin/pg_dump
pg_restore: /usr/lib/postgresql/9.2/bin/pg_restore
psql: /usr/lib/postgresql/9.2/bin/psql
# The m2ee section defines configuration about a single application we're going
# to run.
m2ee:
# The project name, which will be displayed when you start the m2ee program
#
# no default, configuration is mandatory
app_name: My Project Name
# The base path of your project directory. This is the location that contains
# the data, model and web directories.
#
# no default, configuration is mandatory
app_base: /path/to/project/
# or, directly use a deployment directory on a windows machine running the
# Business Modeler remotely... The modeler deployment directory has the same
# directory structure setup.
#app_base: /home/example/mnt/windows/D/Projects/HelloWorld/deployment/
# The Mendix Runtime will listen on an 'administrative' TCP port after startup.
# The 'admin port' is used by m2ee-tools for administrative commands like
# sending configuration options, setting loglevels, requesting information
# about the current status of the application proces, version information,
# statistics about usage etc... This admin port only provides a simple custom
# json-rpc style API over HTTP, so there's no visual web-interface or the like
# present that can be used via a normal web browser. A user interface is
# provided by the m2ee command line tool you're configuring right now. Make
# sure access to this port is properly firewalled. Only local access is needed.
#
# no default, configuration is mandatory
admin_port: 9000
# Specify a comma separated list of addresses for the admin port to listen on
# or use "*" to bind the wildcard address (IPv4: 0.0.0.0, IPv6: ::)
#
# This option is available in Mendix >= 4.3.0. In earlier versions the wildcard
# option was always used.
#
# It is highly recommended to use the default value "127.0.0.1,::1" for the
# admin interface, since the m2ee program always has to be run on the server
# itself.
admin_listen_addresses: "127.0.0.1,::1"
# A password which protects the administrative interface, running on the admin
# TCP port. set this password to e.g. a long random string, it's not used
# manually anywhere. It's passed to the Mendix Runtime using an environment
# variable, to make it possible for m2ee-tools to connect when running.
#
# no default, configuration is mandatory
admin_pass: password
# The TCP port we want the application to present itself on for end users.
# When using a reverse proxy, only sub-urls presenting dynamic content, like
# /xas/, /ws/ and /file are proxied to this port, and end users connect to that
# reverse proxy instead of directly to this port.
#
# no default, configuration is mandatory
runtime_port: 8000
# Specify a comma separated list of addresses for the runtime port to listen on
# or use "*" to bind the wildcard address (IPv4: 0.0.0.0, IPv6: ::)
#
# This option is available in Mendix >= 4.3.0. In earlier versions the wildcard
# option was always used.
#
# When using a reverse http proxy on another host than where this application
# is running, you want to set this to * or the IP address of the interface on
# which the http traffic arrives.
#
# default: "127.0.0.1,::1"
runtime_listen_addresses: "127.0.0.1,::1"
# By default, a pid file containing the process id of the running Mendix
# Runtime JVM is stored into the m2ee.pid file into the .m2ee directory of the
# home directory of the user which runs this mendix application. Well, it is
# possible to override the location.
#
# default: .m2ee/m2ee.pid under the current users home directory
pidfile: /somwhere/else/m2ee.pid
# By default, the Mendix Runtime is started using an emptied environment map
# for security reasons. There may be situations in which it is desired to keep
# some specific environment variables, or set them to specific values. In this
# case, the preserve_environment and custom_environment options come to the
# rescue! Also see the next option, custom_environment, for inserting specific
# variables into the environment at startup.
#
# preserve_environment can be eiter:
# - true -> keep all environment variables when starting the JVM process
# - false -> keep none (default)
# - a list of env variable names to keep (e.g. [LOGNAME,LANG]), while ignoring
# all others
#
# default: false
preserve_environment: false
#preserve_environment: [LOGNAME,LANG]
# custom_environment can be used to add custom enviroment variables when
# starting the JVM process.
#
# default: empty
custom_environment:
PATH: "/opt/some/weird/jre/version/bin/:/bin:/usr/bin/"
# From Mendix 5 onwards, the JVM needs to support Java 7. Here you can specifiy
# the location of the java binary if you want to override the system default.
javabin: /usr/bin/java
# javaopts are custom command line options that will be inserted when starting
# the Mendix Runtime JVM process. Any command line option that is accepted by
# the JVM you are using can be inserted here. Options that are recommended to
# set here are dedicated heap size (always set Xms to the same value as Xmx),
# temporary files folder (to prevent using the system default /tmp) and default
# file encoding.
#
# default: no default, always configure this properly
javaopts: [
"-Dfile.encoding=UTF-8", "-XX:MaxPermSize=64M", "-Xmx256M", "-Xms256M",
"-Djava.io.tmpdir=/path/to/project/data/tmp",
]
# Using extend_classpath, a list of additional locations can be provided that
# will be added to the JVM classpath when starting the Mendix Runtime.
#
# Note: use this option with care. Realize that the JVM loads classes as soon
# as they're used for the first time. This means that changes at the locations
# you point at either won't be noticed, or oppose problems when the content of
# the classpath was changed while the application is running.
#
# Note 2: this option is immediately deprecated, and is not available in
# Mendix 5. If you need to have external libraries in your production
# environment that you do not want to maintain in the project itself, you
# might consider using a post_unpack_hook to copy them into your userlib
# project location server side.
extend_classpath: [
"/usr/local/share/java/greatstuff.jar",
"/opt/dirty/*"
]
# If symlink_mxclientsystem is set to true, try to symlink web/mxclientsystem
# to the mxclientsystem directory of the runtime distribution currently in use.
# This is useful for fixed web server configuration that followes symlinks, so
# auto-detection of Mendix Runtime versions on application startup will
# automatically update the /mxclientsystem/ url on which the javascript client
# will be loaded. When setting this to false, you will need to (re)configure
# your web server configuration to explicitely point the /mxclientsystem url to
# the file system path of mxclientsystem in the mendix runtime distribution
# every time the project team switches Mendix versions.
#
# default: true
symlink_mxclientsystem: true
# The 'post unpack hook' will be triggered right after a 'deployment archive'
# is unpacked. There might be reasons why you might want to execute specific
# actions to alter files or configuration that is contained in the deployment
# archive that just has been unpacked into the model/ and web/ locations of the
# project directory.
#
# default: undefined
post_unpack_hook: '/path/to/project/data/hooks/post-unpack.sh'
# When set to false, the allow_destroy_db option makes m2ee refuse to execute
# the restoredb and emptydb commands. This option is particularly useful for
# use in production environments, where you never ever want to have someone
# make a mistake, messing up terminal windows and remove all of your production
# data at once, instead of removing data in a test environment.
#
# Note: this only applies to the built-in PostgreSQL helper commands.
#
# default: true
allow_destroy_db: true
# This location is used for writing/reading database dumps and writing
# validation query logs.
#
# defaults to data/database under app_base path
database_dump_path: '/path/to/project/data/database'
# This location is used for reading deployment archive uploads (.mda)
#
# defaults to data/model-upload under app_base path
model_upload_path: '/path/to/project/data/model-upload'
# When using the log command in the m2ee shell, m2ee-tools will execute a tail
# -F on the log file of your Mendix Runtime. Unfortunately, it does not
# automagically know where this file is located. You might be logging via
# syslog to a file somewhere, or configure file based logging to some file
# directly. To be able to live follow the logging, you need to hint m2ee-tools
# about where the actual logfile will be located.
#
# default: no default
#logfile: /path/to/project/data/log/logfile.txt
logfile: /var/log/mendix/myproject.log
# The munin sub-section of m2ee defines some behaviour of the munin_config and
# munin_values commands that are provided to be used as munin plugin for
# monitoring the Mendix Runtime process.
munin:
# config_cache points to a little file that contains the response that should
# be sent when the munin config call is done. Providing the cached results of
# this call prevents graphs from disappearing when the actual monitoring data
# is not accessible (e.g. when the admin interface is crashed because of JVM
# out of memory errors or other causes of instability)
#
# defaults to .m2ee/munin-cache.json under the current users home directory
config_cache: /home/example/.m2ee/munin-cache.json
#
# The graph_total_named_users is a little hack that defines whether the total
# amount of named users available in the application database should be
# plotted into the graph of current user sessions. When the difference between
# registered named users and actual amount of concurrent users is really big,
# not displaying the total amount of registered users may make the graph look
# more interesting.
#
# default: true
graph_total_named_users: true
# The jetty sub section defines some configuration tweaks that can be done to
# the webserver which is listening on the Runtime port that serves the
# application itself. Under the hood, Jetty is used as HTTP server
# implementation.
jetty:
# runtime_min_threads defines the minimum amount of JVM threads that will be
# available at the runtime web server to handle requests
#
# default: 8
runtime_min_threads: 8
#
# runtime_max_threads effectively sets a cap on the maximum number of active
# requests that can be handled simultaneously at the same time.
#
# If you ever run into a situation where the active webserver threadpool size
# hits this maximum, you likely need to fix the behaviour of your application,
# to get requests to be completed in time instead of adjusting this value.
#
# Increasing the maximum amount of threads may only help an application to get
# overloaded with work more easily.
#
# default: 254
runtime_max_threads: 254
#
# request_header_size sets the buffer size that is allocated per request to
# store HTTP headers. By default, this is a 4kB buffer. If a request is
# received that has a header part which is bigger, you might see errors like
# this one: WARNING - Jetty: HttpException(413,FULL head,null) - null - null
#
# This issue was reported to happen in combination with using kerberos
# authentication which inserts long token headers into the request headers.
#
# This option was introduced in Mendix version 3.3.7 and 4.4.4
#
# default: 4096 (4kB)
request_header_size: 4096
#
# response_header_size sets the buffer size that is allocated per response to
# store HTTP headers, very much alike the request_header_size option above
#
# This option was introduced in Mendix version 3.3.7 and 4.4.4
#
# default: 4096 (4kB)
response_header_size: 4096
# The mimetypes section can be used to specify custom mime types to be used for
# file downloads.
#
# default: empty
mimetypes:
ext: mime/type
foo: mime/bar
# The logging section defines what sort of logging will be configured when
# starting the Mendix Runtime. Logging in the Mendix Runtime is done using a
# simple publish/ subscribe model. When logging messages from the application,
# they are published to log nodes, and we can subscribe to messages using
# loglevels on a log node.
#
# Use the loglevel command at the m2ee command line to alter log levels on the
# fly.
#
# The logging section uses a list of dictionaries to specify startup logging
# configuration. The two most important log subscriber implementations will log
# messages they receive directly to a file, or to the unix syslog over UDP.
#
# no default
logging:
-
# Example of Syslog Subscriber configuration. Using syslog is the recommended
# logging method on *nix. Standard available tools like logrotate can be used
# to rotate/compress logs. As a bonus, logs will be tamper-resistant because
# they can be written to a place where the application user does not have
# write permissions.
type: syslog
# Some unique name which will be used to refer to this log subscriber when
# setting log levels.
name: SysLogSubscriber
# If autosubscribe is set, this log subscriber will subscribe to messages on
# all new log nodes published having the specified log level or higher
# severity. Effectively this means that if you don't set it, you won't ever
# see no log message. :-) Available log levels are: NONE, CRITICAL, ERROR,
# WARNING, INFO, DEBUG, TRACE
autosubscribe: INFO
# Well-known syslog specific parameters:
host: localhost
port: 514
facility: LOCAL6
prefix: example
# In the Mendix Runtime, log nodes are created on the fly when a log message
# is published to them and they don't exist yet. However, since we cannot
# interactively change the log level for a node that does not exist yet,
# loglevel configuration in here allows to force create and set a loglevel
# for nodes even before any logging in the Mendix Runtime happens, to enable
# debugging right from the start. This also allows debugging of the early
# startup code of the Mendix Runtime.
#
# This functionality is available in Mendix >= 6
#
# Note that setting a log level on a single logsubscriber will also
# configure it on other log subscribers using their autosubscribe setting!
loglevel:
Core: DEBUG
Connector: WARNING
-
# Example of File Subscriber configuration. This log subscriber will output
# all log messages directly to a text file.
type: file
# Some unique name which will be used to refer to this log subscriber when
# setting log levels.
name: FileSubscriber
# If autosubscribe is set, this log subscriber will subscribe to messages on
# all new log nodes published having the specified log level or higher
# severity. Effectively this means that if you don't set it, you won't ever
# see no log message. :-) Available log levels are: NONE, CRITICAL, ERROR,
# WARNING, INFO, DEBUG, TRACE
autosubscribe: INFO
# File to log to.
filename: /home/knorrie/mnt/windoos_k/Projects/logging/out.log
# The file subscriber implements very simple rotate functionality, which
# stops writing a log file when the size of the file reaches max_size bytes.
# Sadly, there's no m2ee api call to make the Mendix Runtime re-open its
# logfile (yet), so directly using logrotate on these files (together with
# setting max_rotation 0 is not possible. When requiring more advanced log
# rotate and compression functionality, it is recommended to use logging via
# unix syslog. default: 2097152 bytes (2MB)
max_size: 10485760 # specify this value in bytes
# After opening a new log file, max_rotation amount of files will be kept,
# and will be renamed with a dot-number suffix like file.1, file.2, file.3
# etc. Set max_rotation to 0 to never rotate
# default: 10
max_rotation: 10
# The last section of this file contains the 'mxruntime' section, which contains
# configuration which will be sent to the Mendix Runtime when it's started.
#
mxruntime:
# Application root URL will be used when generating wsdl documentation on the
# fly at /ws-doc/
ApplicationRootUrl: https://example.mendix.com/
MicroflowConstants:
# put microflow constants in here
Module.Constant: text
AnotherModule.AnotherConstant: bla
# ScheduledEventExecution can be set to ALL, NONE (default) or SPECIFIED
ScheduledEventExecution: NONE
# When using ScheduledEventExecution SPECIFIED, provide a list of actions to
# enable:
MyScheduledEvents:
- Module1.Event1
- Module2.Event2
- Module3.Event3
# Database login credentials
DatabaseType: PostgreSQL
# The DatabaseHost contains the database hostname and optionally, also the TCP
# port number. It's possible to use a plain IPv6 address by enclosing it in
# brackets, like: "[::1]:5432"
DatabaseHost: "127.0.0.1:5432"
DatabaseName: database
DatabaseUserName: username
DatabasePassword: password
# Custom x509 CA Certificates: additional (private/custom) SSL Certificate
# Authorities for x509 chain validation.
#
# A list of files can be specified that contain a single PEM formatted
# certificate per file (additional certificates in a single file seem to be
# ignored). These CA certificates will be added to the trusted CA list of the
# JVM after loading the default truststore.
#
# Do not use a comma in any of the file names, as the list has to be sent to
# the mendix runtime as single comma separated string...
CACertificates:
- "/path/to/project/data/ssl/custom-ca.crt"
- "/path/to/project/data/ssl/foobar-ca.crt"
# Webservice Client Key/Certificates: secret keys and certificates for SSL
# client authentication can be used by creating a separate pfx (PKCS #12) file
# for each set of key/certificate and optional intermediate CAs to complete the
# validation chain at the remote web server.
#
# If a pfx contains a CA, the CA will not be automagically added to the trusted
# CA list. You can use the CACertificates option to add a CA.
#
# A pfx container requires a password, so besides the ClientCertificates
# option, a ClientCertificatePasswords option is used to specify the passwords
# used for reading the pfx files... The order of the pfx list has to match the
# order of the password list here...
#
# Do not use a comma in any of the file names or passwords, as the lists have
# to be sent to the mendix runtime as single simple comma separated string...
#
# Are you still with us? Have fun! Don't hesitate to file a support ticket at
# Mendix if you run into issues using these options. JVM exceptions and
# stacktraces related to certificates can be a real pain to debug and solve.
ClientCertificates:
- "/path/to/project/data/ssl/custom-client.pfx"
- "/path/to/project/data/ssl/foobar-client.pfx"
ClientCertificatePasswords:
- "1"
- "1"
# No, we're not done with the SSL business yet. By default, the JVM is not
# quite intelligent about choosing a client certificate to present to a remote
# web server. This means that, if you have two different client certificates
# which are signed by the same CA, and are using two different web service
# calls, requiring a certificate signed by this CA, you never know which
# certificate will be presented to the web server.
#
# In order to pin the use of key/certificate pairs to a specific web service,
# the WebServiceClientCertificates option is available, which allows to specify
# a mapping between web service names (as defined in the modeler) as key and
# one of the above listed pfx files as value. When this mapping is specified,
# Mendix will make sure the JVM will use the key/certificate pair from that
# specific pfx bundle.
#
WebServiceClientCertificates:
Module.Webservice: "/path/to/project/data/ssl/custom-client.pfx"
Module.FooBarWebservice: "/path/to/project/data/ssl/foobar-client.pfx"
# Advanced Database options...
#
# Enable DatabaseUseSsl to enable using SSL with PostgreSQL connections. Be
# sure to test this extensively in your setup before enabling this in
# production, to be sure you know the quircks about long living transactions,
# data transfer volumes and SSL renegotiation.
DatabaseUseSsl: False
# Defines the SERVICE_NAME when you have a connection with an Oracle DBMS.
OracleServiceName: MyServiceName
# Advanced Database connection pooling configuration
#
# The Mendix Runtime uses a pool of database connections to minimize the
# overhead of opening and closing connections. When queries are sent to the
# database an already opened connection can be borrowed from the pool and be
# returned after the query completes.
#
# Max Active sets the cap on the total number of active database connections.
# When the Max Active amount of connections is in use, the Runtime will throw
# an exception if no connection becomes available before the configured amount
# of time at the Max Wait setting has passed. Use this settings to set a
# safeguard to prevent runaway application behaviour from also hogging down
# your database server.
#
# default: 50
ConnectionPoolingMaxActive: 50
# default: 10000 milliseconds
ConnectionPoolingMaxWait: 10000
#
# Max Idle sets the cap on the number of "idle" instances in the pool.
# Best practice is to set this value equal to Max Active, and let the
# connection pool gradually shrink to the Min Idle amount if connections are
# not actually in use.
#
# default: 50 (Mendix >= 3.3), 20 (Mendix < 3.3)
ConnectionPoolingMaxIdle: 50
#
# Min Idle sets the minimum amount of idle connections that is held open to
# anticipate on new incoming requests.
#
# default: 0
ConnectionPoolingMinIdle: 5
#
# This setting with a very long name sets the amount of connections that will
# be inspected every few minutes to close idle connections. A negative value
# specifies the fraction of the total amount of connections that will be
# inspected.
#
# default: -3 (clean up about 1/3 of unneeded idle connections)
ConnectionPoolingNumTestsPerEvictionRun: "-10"
# Abort database SELECT queries that are started from a client XPath request,
# or XLS/CSV Export button and run for a configurable amount of time.
# The reverse http proxy in use might have a proxy gateway timeout set (which
# is by default 60 seconds when using Nginx for example), so continuing while
# nobody can receive the results anymore is a bit pointless...
#
# Setting this option prevents runaway database queries from eating up all
# of your database cpu cycles, while you're busy tracing down the source of
# the problem (using LogMinDurationQuery, see below)
#
# This option was introduced in Mendix version 2.5.6
# The value is specified in seconds.
#
# default: not set, no timeout
ClientQueryTimeout: 70
# Log all database queries that take more of the configured amount of time to
# deliver a result set.
#
# This option was introduced in Mendix 4.1.0
# The value is specified in milliseconds.
#
# default: not set, no logging
LogMinDurationQuery: 10000
# TrackWebServiceUserLastLogin defines whether to update the web service users
# 'LastLogin' field on each login. When this happens a database update query
# has to be sent and this can have performance consequences on heavy loaded
# systems. When this setting is set to false, no database interaction is
# necessary.
#
# This option was introduced in Mendix version 4.3.0
#
# default: True
TrackWebServiceUserLastLogin: True
# 'Session Fingerprinting' is a feature that was introduced in Mendix 3.2.0
# On login, a fingerprint of browser information is taken, which is compared to
# the same information on subsequent requests. Doing this slightly increases
# the difficulty of succesful interaction with an application after stealing
# session cookies from another user.
#
# An option to turn off fingerprinting was introduced in Mendix version 4.1.0
# Session Fingerprinting was completely removed in Mendix 4.3.0, as it causes
# more issues than it fixes.
#
# default: True
EnableSessionFingerprinting: False
# The Mendix Client (running in your browser) sends keepalive messages to the
# Mendix Runtime to let it know the user still has the browser window opened.
# In case someone closes his browser without logging out, the session will
# expire at the Mendix Runtime after no keepalives have been seen for longer
# than the SessionTimeout value.
#
# When disabling keepalive, the Mendix Runtime will update the server side
# timeout at every interaction with the client. If the client is inactive for a
# period longer than the SessionTimeout, the client session will be terminated.
#
# By default, the keepalive option is enabled. It can be disabled if you want
# to have user sessions being terminated if they do not create activity
# manually, regardless of still having the application opened in the browser.
#
# This option was introduced in Mendix version 4.1.0
#
# default: True
EnableKeepAlive: True
# The session timeout defines the maximum time a browser session can be
# inactive until the session is killed at the Mendix Runtime. With the
# EnableKeepAlive option enabled (which it is by default), the client will send
# keepalives to the Runtime at an interval of half the SessionTimeout. If
# EnableKeepAlive is disabled, user sessions will be terminated after no
# explicit user generated traffic has been seen for this amount of time.
#
# The SessionTimeout is specified in milliseconds, and defaults to 10 minutes.
SessionTimeout: 600000
# When enabling persistent sessions, information about logged in users will be
# stored in the database of your Mendix application, instead of only in the
# volatile application memory.
#
# Only login sessions will be stored in the database. Intermediate state of
# running microflows and objects that are being edited in the web client, but
# not yet committed, are not saved in the database.
#
# -- For Mendix versions before 7 --
#
# It is not desirable in any use case to enable persistent sessions in Mendix
# versions earlier than 7. It might be convenient that users do not seem to be
# logged out if you do a quick restart of the application, but all unsaved
# edit forms will generate errors or corrupt data.
#
# Moreover, never disable the EnableKeepAlive setting together with enabling
# PersistentSessions, because this will cause an extra database update to
# happen on the user object for every request the browser client issues, which
# has serious impact on the performance of the application.
#
# default: False # for Mendix < 7
PersistentSessions: False
#
# -- For Mendix 7 --
#
# In Mendix 7, optimizations were made to reduce the performance impact of
# enabling PersistentSessions and disabling the EnableKeepAlive option.
#
# When using multiple runtime instances for a single environment, this option
# needs to be enabled.
#
# default: True # Mendix 7
PersistentSessions: True
# By specifying file names in the include section, additional configuration
# will be read from those files, and will be deep-merged into the already read
# configuration.
#
# Including configuration is not recursive. It's done only once.
#
# When specifying multiple configuration files on the command line using -c,
# the includes from all of those configuration files will be handled.
include:
- /path/to/additional/configuration.yaml
- /please/also/consider/this.yaml