The main responsibility of process managers is executing commands on microservices through its management interfaces including the examination of proper environmental condition of each command execution (ex. the amount needed resources). In case of application microservices execution is performed through TRANSMISSION port by PROCESS MANAGER, in case of technical microserivces implementation of command execution depends on the API provided by technical microserice and is performed by TECHNICAL PROCESS MANAGER.
The process manager takes care of application microservices, it monitors their availability on the OS level, detects JVM error and takes action in order to restore microservice availability.
Technical process manager
The process manager takes care of technical microservices, it monitors their availability on the OS level, responsiveness and takes action in order to restore microservice availability. Its implementation differs depending the type of technical microservice.
Configuration of process managers is a part of main config and consists of the following sections:
The default configuration:
PROCESS_MANAGER: isCheckAvailableOSMemoryOnMicroservicesStart: true microservicesPortOffset: 20000 OS_PROCESSES_KEEPER: isCheckOSProcessAlive: true howOftenCheckingProcessInMillis: 5000 # logPath: ../logs/process_manager JVM_MEMORY_ERRORS_KEEPER: isCheckMemoryErrors: true howOftenCheckingProcessInMillis: 5000 # heapDumpPath: ../logs/memory_manager/errors # logPath: ../logs/memory_manager/restart # archiveLogPath: ../logs/memory_manager/archive # restartLogPath: ../logs/memory_manager/restart
|isCheckAvailableOSMemoryOnMicroservicesStart||The switch that determines whether there is enough memory for the starting microservice. If the process manager finds that there is not enaugh memory for a new microservice, it won't start.|
|microservicesPortOffset||Main Server needs port sets to establish communication to microservices. These sets are managed automatically by default which means that ports in the set is assigned dynamically. Main Server starts this dynamic allocation from offset port number, so the first dynamically chosen port will equal to offset.|
Additionally, the process manager implements recovery mechanisms for microservices that constantly check if something is wrong with a microservice. The more precise information about this mechanisms including its configuration is provide in the following sections.
The OS process keeper checks the existence of the microservice's process in the operating system (it knows the PID of the microservice). If it finds that the process doesn't exists and this state doesn't result from administrative tasks (ex.
microservice stop) it automatically starts the microservice.
|isCheckOSProcessAlive||The switch that determines whether OS process keeper is active.|
|howOftenCheckingProcessInMillis||The checking period of OS process keeper, expressed in milliseconds.|
|logPath||Location of log files from start, stop and restart process. The default value is: $JLUPIN_HOME/server/logs/process_manager|
Memory process keeper is a process of controlling the occurrence of errors related to the JVM memory. It periodically checks if any error occurs, if it does the recovery actions are taken to restore the microservice availability, which are described in servlet microservice configuration and native microservice configuration.
|isCheckMemoryErrors||The switch that determines whether memory process keeper is active.|
|howOftenCheckingProcessInMillis||The checking period of memory process keeper, expressed in milliseconds.|
|heapDumpPath||The location of the heap dump collected from the microservice during memory error handling. After the dump is finished, it is moved to the archive location. The default value is: $JLUPIN_HOME/server/logs/memory_manager/errors|
|logPath||The log file that contains the error stack trace which describes the class where memory error occurs. The default value is: $JLUPIN_HOME/server/logs/memory_manager/restart|
|archiveLogPath||The archive of data collected during memory errors handling (dumps, logs).|
|restartLogPath||The location of log files collected from the restart process of the microservice during memory errors handling. After the process of memory handling is finished the log file is moved to archive location.|
Technical OS process manager is responsible for availability of technical microservices, it periodically checks their processes, if they are not present or unresponsive the proper action are taken to roster the availability of technical microservice.
The default configuration:
TECHNICAL_PROCESS_MANAGER: isCheckOSProcessAlive: true howOftenCheckingProcessInMillis: 5000 responseOSTimeToCheckProcessAliveInMillis: 2000
|isCheckOSProcessAlive||The switch that determines whether technical OS process keeper is active.|
|howOftenCheckingProcessInMillis||The checking period of technical OS process keeper, expressed in milliseconds.|
|responseOSTimeToCheckProcessAliveInMillis||The maximum response time of the technical process, beyond which the mechanism recognizes that the process is unavailable and performs its restart.|