evQueue core process configuration
core.gid (numeric) : 33
core.uid (numeric) : 33
Numeric UID and GID of the process. If you want the process to change user or group, you must run evqueue as root. Use uid/gid of www-data if you want to use web board (or change apache uid/gid)
core.pidfile (string) : /var/run/evqueue/evqueue.pid
Filename of the pidfile created by evqueue at startup
IP which will be used to bind. Use "*" to bind on all interfaces.
network.bind.port (numeric) : 5000
Port to listen on.
network.bind.path : /var/run/evqueue/evqueue.socket
Path of the UNIX socket. This socket can be used in combination with the IP socket. Leave blank if not needed.
network.listen.backlog (numeric) : 64
Size of the listen backlog : this is the maximum number of pending connections.
network.rcv.timeout (numeric) : 30
Receive timeout in seconds
network.snd.timeout (numeric) : 30
Send timeout in seconds
processmanager.errlogs.enable (boolean) : no
Error logs are used when a process returns 0 (no error) but the XML is invalid. This is often caused by a task not detecting properly error cases. These logs are very useful to troubleshoot failed executions. It is normaly safe to enable this as very few logs should be created
processmanager.logs.directory (string) : /tmp
Where to store tasks outputs. These files are used to temporarily store stdout and stderr until task exit. They might be deleted on exit (this behaviour is controlled by processmanager.logs.delete).
processmanager.logs.delete (boolean) : yes
Delete logs at the end of task execution. It is strongly recommended to delete logs as the can quickly grow up
processmanager.monitor.path (string) : /usr/bin/evqueue_monitor
Path to the evqueue monitor. The monitor is installed by evQueue core package. It is used to control task execution and notify evQueue core engine.
processmanager.tasks.directory (string) : .
Path to prepend when task filename is relative. When a task is created with a relative filename (not beginning with a “/”), this path is prepended before execution. This is useful if you have custom developed tasks, stored on different locations on different environment. This prevents from storing hard coded paths into database. Using this trick you can dump databases from one environment to another, even if paths are different.
processmanager.monitor.ssh_path (string) : /usr/bin/ssh
SSH configuration is used for remote task execution. If no key is specified, default SSH key of the user running evQueue will be used. If you want to use the default key you must comment "processmanager.monitor.ssh_key"
workflowinstance.saveparameters (boolean) : yes
Save workflow parameters in database. This is required if you want to use search on parameters values within the web control interface. As on line is inserted for each parameter of each workflow instance, the table t_workflow_instance_parameters can grow quickly. You should be careful when using this option on high loaded platforms. If you disable this, you won't be able to filter workflow instances based on their input parameters. This however only impacts web control interface, and not the core engine.
workflowinstance.savepoint.level (numeric) : 2
The savepoint level determines how evQueue synchronizes with the database. This affects performance, as well as the web control interface.
Never store workflows in database. This has the best performance as no database is used for execution (database is the only used to read configuration). Choosing this option will disable all history in the web board. However, database will be used during engine restart to keep state of running instances. This setting is recommended only if performance is essential.
Save workflows on stop or when the engine is restarted. This is slightly less database intensive than mode 2. The only drawback of this setting is that in case of engine crash, no trace of running workflow will be kept, so it will be impossible to relaunch them.
Save workflows on start, stop or when the engine is restarted. This is the recommended setting and is a good compromise between between performance and history.
Save workflows on each state change. A state change occurs when each time a task starts or ends. This can be useful if you want to monitor workflows from database instead of accessing the core engine by the TCP socket. However, be aware that this can generate very high load on MySQL and that this will slow down the engine.
Note that the level 0 or 1 will also affect workflowinstance.saveparameters and disable it (whatever its value was).
workflowinstance.savepoint.retry.enable (boolean) : yes
workflowinstance.savepoint.retry.times (numeric) : 2
workflowinstance.savepoint.retry.wait (numeric) : 2
Retry controls what to do on database errors when saving workflows state (savepoint). If retry is disactivated, a database error will prevent the workflow instance from being archived into the database. However, this does not prevent correct execution of the workflows. The will not be shown in the web board as terminated workflows, also they have been well executed. If you enable retry, evQueue will try database requests “times” with a backup time of “wait” seconds. This prevents you from loosing data on tamporary database failure (for example restart).
logger.syslog.enable (boolean) : yes
Log errors to syslog. It is recommended to always keep this active.
logger.syslog.filter : LOG_NOTICE
Only log events with a priority greater or equels to this filter
logger.db.enable (boolean) : no
Log errors to database. This is required if you want to access logs from the web board. This can slow down the engine on busy systems and thus it is recommanded to keep the filter on LOG_WARNING in production.
logger.db.filter : LOG_WARNING
Only log events with a priority greater or equels to this filter
The garbage collector is used to reduce the size of the evQueue database. It will delete workflow instances after a period of time. Disabling garbage collector will give you an infinite history of terminated workflow instances. This can however cause serious slowdowns on web board (and on search particularily).
gc.enable (boolean) : yes
Whether or not to enable the garbage collector
gc.interval (numeric) : 43200
Interval in seconds between executions of the GC
gc.limit = 1000
If entries are to be removed, GC will not free more than this limit at once. You should really use this to avoid long locks on your database.
gc.delay = 2
If the limit is reached, GC will wait this interval (in seconds) before trying to free again up to gc.limit
gc.logs.retention = 7
Clean database logs older than (in days)
gc.workflowinstance.retention = 30
Clean terminated workflow instances older than (in days)