Table of Contents
To configure Enduro/X you have to finish several steps.
In this chapter will be descirbed typical GNU/Linux system configuration required for Enduro/X. Server Posix queue paramters must be set-up:
Typical configuration would look like (normally you can put this in /etc/rc.local):
# Mount the /dev/mqueue mkdir /dev/mqueue mount -t mqueue none /dev/mqueue echo 32000 > /proc/sys/fs/mqueue/msg_max echo 10000 > /proc/sys/fs/mqueue/msgsize_max echo 10000 > /proc/sys/fs/mqueue/queues_max
Which means:
See [MQ_OVERVIEW] for more details about Posix queues on GNU/Linux.
Also do not remember to update Enduro/X environment variables to reflect these settings. Variables like:
See [EX_ENV] for more configuration flags.
Update also should be done to system security configuration. I.e. update to /etc/security/limits.conf is required, following lines must be added:
* soft msgqueue -1 * hard msgqueue -1
Enduro/X depends lot of Environment variables. See manpage of ex_env ([EX_ENV]) to see all paramters that must be setup. There is also sample configuration provided. Normally it is expected that seperate shell script file is setup containing all paramters. Then to load the environment, login with Enduro/X user in, and run following command in your app dir, for example:
$ cd /endurox/app/conf $ . setapp
Vital part of Enduro/X is ndrxdconfig.xml config. Full path to it is configured in NDRX_CONFIG environment variable. To see how to setup see manpage of it [NDRXCONFIG].
Environment variable NDRX_DEBUG_CONF contains full path to debug file. See [DEBUGCONF] for more details about debug.conf setup.
To start the Enduro/X application, login with Enduro/X instance user, and issue following command xadmin start, for example:
$ xadmin start -y ndrxd PID (from PID file): 25037 exec tpevsrv -k 0myWI5nu -i 14 -e /tmp/TPEVSRV -r -- : process id=26793 ... Started. exec tpbridge -k 0myWI5nu -i 101 -e /tmp/BRIDGE002 -r -- -n2 -r -i 0.0.0.0 -p 4433 -tP -z30 : process id=26794 ... Started. exec tpbridge -k 0myWI5nu -i 102 -e /tmp/BRIDGE012 -r -- -n12 -r -i 10.10.10.2 -p 14433 -tA -z30 : process id=26795 ... Started. Startup finished. 3 processes started.
To see all commands available by xadmin (xa) see manpage of it [XADMIN].
Enduro/X is capable to continue with out restart in case if ndrxd local ATMI monitor is crashed or contains invalid data structures for some reason. In this case administrator can do following:
To setup cluster see you have to setup bridge ATMI processes on each of the machines. See [TPBRIDGE] documentation to have understanding of clustering. Sample setup of cluster node which activetly connects to Node 2 and waits call from Node 12 could look like:
<?xml version="1.0" ?> <endurox> <appconfig> <sanity>10</sanity> <brrefresh>6</brrefresh> <restart_min>1</restart_min> <restart_step>1</restart_step> <restart_max>5</restart_max> <restart_to_check>20</restart_to_check> </appconfig> <defaults> <min>1</min> <max>2</max> <autokill>1</autokill> <respawn>1<respawn> <start_max>2</start_max> <pingtime>1</pingtime> <ping_max>4</ping_max> <end_max>3</end_max> <killtime>1</killtime> </defaults> <servers> <!-- Connect to cluster node 2, we will wait for call --> <server name="tpbridge"> <max>1</max> <srvid>101</srvid> <sysopt>-e /tmp/BRIDGE002 -r</sysopt> <appopt>-n2 -r -i 0.0.0.0 -p 4433 -tP -z30</appopt> </server> <!-- Connect to cluster node 12, we try to connect activetly to it --> <server name="tpbridge"> <max>1</max> <srvid>102</srvid> <sysopt>-e /tmp/BRIDGE012 -r</sysopt> <appopt>-n12 -r -i 195.122.24.13 -p 14433 -tA -z30</appopt> </server> </servers> </endurox>
Starting from Enduro/X version 5.1+, the max message size what can be transported over the XATMI sub-system is limited to the operating system’s queue settings. For example on Linux kernel 3.13 the message size limit (/proc/sys/fs/mqueue/msgsize_max) is around 10 MB. The message size is configured with NDRX_MSGMAX environment variable, see ex_env(5) man page.
Also what should be noted, as Enduro/X mostly uses stack allocation instead of heap allocation (for safer and faster code), then there are requirements against the stack size. The stack size (ulimit -s) must be at least size of message multiplied with 30. So for example if message size is set to 1 MegaByte, then stack size shall be set to 30 Mega bytes (ulimit -s 30720 KB). If the stack is not sufficient the following error will be print when attempting to run any Enduro/X based software:
Logging to ./ULOG.20171112 Failed to open [./ULOG.20171112] 9138:20171112:19144166:xadmin :LIMITS ERROR ! Please set stack (ulimit -s) size to: 1966080 bytes or 1920 kb (calculated by: NDRX_MSGSIZEMAX(65536)*NDRX_STACK_MSG_FACTOR(30)) LIMITS ERROR ! Please set stack (ulimit -s) size to: 1966080 bytes or 1920 kb (calculated by: NDRX_MSGSIZEMAX(65536)*NDRX_STACK_MSG_FACTOR(30)) Process is terminating with error...
In this case stack size needs to be increased, that could be done by in multiple ways:
Also regarding the buffer sizes, when NDRX_MSGMAX is set bellow 64K, the buffer size is fixed to 64K, this means that operations like network packet size when using tpbridge, is set to 64K.
As the message size is in the same time a internal buffer size, this means that not all space can be used by sending some data (for example CARRAY or UBF buffer). Some overhead is added by Enduro/X, message headers, for bridge protocol format extra data is added for TLV structure. Thus to be safe, for example if expected data size is 64K, then message size should be set to something like 80KB.
Enduro/X support SOA level cache. This means that administrator can configure system configuration, so that certain services are cached. Thus if some client process calls some service X, and it gets valid results back, then data key is built (specified in config) and for this key data is saved to Lightning Memory-Mapped Database (LMDB). Next time service is called, the cache is checked, again, key is built, and lookup to LMDB is made. If results are found in db, then actual service is X is not called, but instead saved buffer from cache is returned back to caller. Cache works for tpcall() function.
Cache supports different features:
The LMDB is build in such way that if write transaction on the database is open, then other writes will not be able to process it in meantime. While read only transactions are processed, while some other process holds write transaction. Also if process which is holding the lock is crashed (e.g. segfaul, kill, etc..), then lock is automatically made free. Thus for example is using hits or lru limitation caches, then this automatically means that during the tpcall() chaches needs to be updated, thus lock is needed, and this means that all callers will have to sync in that place - thus makes point of bottleneck.