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 on the ode-axis2.properties 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.
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);
Alternatively a custom dehydration policy can be used by implementing the DehydrationPolicy
interface.