Resolution:
Description:
===========
OutOfMemory Exception occurs when project uses ObjectManagement "In Memory" and Statemmachines with timeouts

Environment:
===========
TIBCO BusinessEvents 3.0.2/4.x/5.x
All Operating Systems


Symptoms:
=========
Exception:
java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap space
        at com.tibco.cep.kernel.core.rete.BeTransaction.execute(SourceFile:122)
        at com.tibco.cep.kernel.core.rete.ReteWM.executeRules(SourceFile:1392)
        at com.tibco.cep.runtime.session.impl.RuleSessionImpl$4.doTxnWork(RuleSessionImpl.java:1082)
        at com.tibco.cep.kernel.core.rete.BeTransaction.run(SourceFile:140)
        at com.tibco.cep.kernel.core.rete.BeTransaction.execute(SourceFile:100)
        at com.tibco.cep.runtime.session.impl.RuleSessionImpl.preprocessPassthru(RuleSessionImpl.java:1060)
        at com.tibco.cep.runtime.scheduler.impl.WorkerBasedControllerV2$2.doTxnWork(WorkerBasedControllerV2.java:427)
        at com.tibco.cep.kernel.core.rete.BeTransaction.run(SourceFile:155)
        at com.tibco.cep.kernel.core.rete.BeTransaction.execute(SourceFile:100)
        at com.tibco.cep.runtime.scheduler.impl.WorkerBasedControllerV2.executeTask(WorkerBasedControllerV2.java:421)
        at com.tibco.cep.runtime.scheduler.impl.WorkerBasedControllerV2$WorkerTask.run(WorkerBasedControllerV2.java:466)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
        at com.tibco.cep.runtime.util.CustomBEManagedThread.run(CustomBEManagedThread.java:24)
Caused by: java.lang.OutOfMemoryError: Java heap space


Cause:
======
Configuration issue.

Resolution:
========
Add the following properties to the CDD (Inference Agent-Class):

be.engine.statemachine.deleteStateTimeoutOnStateExit=true
be.engine.om.removeRefOnDeleteNonRepeatingTimeEvent=true

These properties have been indroduced in TIBCO BusinessEvents 3.0.2HF4

CR Notes: BE-4103
Children of composite states did not exit when the composite state timed out and had a specified timeout state. Now when the composite state times out, the child states are exited. Also, children of composite states did not have their timeouts reset when the composite state timed out, and the timeout state was set to "current." Now when the composite state times out to the current state, the timeout delays of the child states are also reset. Note that in a non-cache OM, the timeouts for the child states (now correctly exited) may fire unless the following property is set:
be.engine.statemachine.deleteStateTimeoutOnStateExit=true

When you use the above property it is also recommended that you also use the  following property:

be.engine.om.removeRefOnDeleteNonRepeatingTimeEvent=true