Memory Management

Oracle Health Insurance applications consist of a cluster of nodes to which requests are distributed. A single node is processing multiple user requests on different execution threads. Those threads share a single memory space. A single thread could start using too much memory, impacting the other threads on that same node.

On the extreme, if a node runs out of memory, the node can crash with an out-of-memory error, resulting in service loss. An out-of-memory of a single node can even impact the stability of the complete cluster.

Before the actual out-of-memory, the performance of the node is going down considerably.

Because of the severe impact, a node must always have sufficient free memory.

Oracle Health Insurance applications have built-in guardruals that prevent an out-of-memory from happening.

Memory State

Every node is monitoring its own memory state. The memory state can have those 4 values:

Table 1. Memory State

State	Meaning	Application HealthCheck Status	Restrictions
Normal	Sufficient free memory is available	200	None
Low	The free memory is below the threshold set by system property ohi.system.memory.threshold.low	429, informating the load-balancer or clients programs that no new requests should be sent anymore.	No new tasks for background processing are started.
Lower	The free memory is below the threshold set by system property ohi.system.memory.threshold.lower	429, informating the load-balancer or clients programs that no new requests should be sent anymore.	Same as for Low plus: New HTTP IP/API requests are rejected with status 429
Critical	The free memory is below the threshold set by system property ohi.system.memory.threshold.critical The system is now approaching an out-of-memory.	429, informating the load-balancer or clients programs that no new requests should be sent anymore.	Same as for Lower plus existing requests are being terminated.

In a correctly configured cluster with proper work distribution, the Critical memory state should never be encountered.