Rational
In most ODE deployments, processes are only used once in a while and the time between each solicitation can be pretty long with respect to the actual execution time. However the default behavior for the engine is to load all processes permanently in memory, including their definition. For environments where memory is scarce or where a large number of processes are deployed, this isn't suitable.
ODE implements two mechanisms in order to reduce the memory footprint of the engine to the strict minimum:
- Process definitions lazy-loading: processes are loaded in-memory bare, without their runtime definition (the compiled BPEL process). The definition will be loaded and associated to the in-memory process representation only when they are actually invoked. This mechanism is called hydration.
- Process definitions reaping: process definitions can be disassociated from their in-memory representation if they haven't been used for some time of if there are already too many definitions loaded in memory. This mechanism is called dehydration. A process will automatically rehydrate itself when necessary (when it receives a message for example).
Activating Dehydration Policy
In the Axis2 integration layer, activation of the policy can be done by setting the following property in the ode-axis2.properties file, which is located in the WEB-INF/conf directory of ODE's web application:
ode-axis2.process.dehydration=true
The default configuration is to dehydrate processes that haven't been used for 20mn or after the maximum of 1000 process definitions in memory is reached.
However, you may override the time that the process have to remain unused before they can be considered for dehydration by specifying a value, in milliseconds, for the following property in the ode-axis2.properties file:
# wait for 5 minutes instead of 20 minutes
ode-axis2.process.dehydration.maximum.age=300000
Similarly, you may override the maximum number of process definitions that may remain hydrated at any given point in time by specifying a value for the following property in the ode-axis2.properties file:
# allow not more than 500 processes to be in memory at once
ode-axis2.process.dehydration.maximum.count=500
Dehydration Policy at IL Level
If you're using your own interface layer or want to do some customization at this level, the default hydration policy is implemented in CountLRUDehydrationPolicy![]()
. It should be set on BpelServerImpl![]()
and can been configured by setting the process max age or max count (either one will not influence the dehydration if set to 0). For example:
CountLRUDehydrationPolicy dehy = new CountLRUDehydrationPolicy();
dehy.setProcessMaxAge(60000); dehy.setProcessMaxCount(100); _server.setDehydrationPolicy(dehy);
The dehydration policy is polled every 10s to see if some processes should be dehydrated so a process max age of less than 10 seconds will be effectively of 10 seconds. Alternatively a custom dehydration policy can be used by implementing the DehydrationPolicy![]()
interface.
