cluster manager / delete behaviour ( Cluster manager failed to destroy session5bc9782e-)

0
I'm getting this error a lot since we upgraded to Mendix 5 (serveral hundred times a day). The strange thing is that the errors comes with a delete behaviour message ("Deze rekening kan niet verwijderd worden omdat het ingebruik is bij bankdagboeken."). So it looks like delete behaviour is causing this... Any ideas? 2014-11-05 16:49:09.584 ERROR - Core: Cluster manager failed to destroy session'5bc9782e-d827-4cd6-b830-e29dfc409937', probably caused by a lock or running transaction on the database. 2014-11-05 16:49:09.584 ERROR - Core: com.mendix.core.CoreRuntimeException: com.mendix.core.CoreRuntimeException: com.mendix.systemwideinterfaces.core.UserException: Deze rekening kan niet verwijderd worden omdat het ingebruik is bij bankdagboeken. at com.mendix.core.actionmanagement.ActionManager.executeInTransactionSync(SourceFile:182) Caused by: com.mendix.core.CoreRuntimeException: com.mendix.systemwideinterfaces.core.UserException: Deze rekening kan niet verwijderd worden omdat het ingebruik is bij bankdagboeken. at com.mendix.core.actionmanagement.ActionManager.executeSync(SourceFile:216) Caused by: com.mendix.systemwideinterfaces.core.UserException: Deze rekening kan niet verwijderd worden omdat het ingebruik is bij bankdagboeken.
asked
1 answers
0

Older versions of Mx4 and Mx5 have experienced issues before with objects not being removed, or objects being removed to soon.

I have never done a memory test in Mx5, so I cannot tell for sure if there are still any of these issues present. But based on your message, it seems like you are experiencing the same problems we had before.

The mendix garbage collection can be started by 2 different triggers.
A microflow is completed, that doesn't mean a subflow. But from the moment the Context of the first microflow is initialized till the moment that context is closed. At that point the garbage collector starts.
Also when a session is being removed because of inactivity or because the user logs out. All objects in session memory will be destroyed. An important thing to keep in mind when analyzing the problem, the garbage collector does a 'Delete' and applies delete behavior on objects it removes.


The garbage collector is supposed to be smart enough to recognize when actions are still running and leave the objects related to that action intact.
It looks as if that isn't working in your situation in 5.7.0.1.

Something like this can happen if a microflow has been started by the user from that session. The microflow is still running and is in the process of creating a new object.
In your scenario either the 'Rekening' has been created but not yet committed. Or an object associated to 'Rekening' is being removed, and with delete behavior it also tries to remove 'Rekening'


Is this something you have been able to reproduce or what you see on a regular basis? If so you can use the lognode 'microflowengine' (trace) and 'connectionbus_retrieve' (debug) to find exactly which microlfows were running at a specific time. If it's not reproducible there are some Java actions you might be able to put in the before delete event that pull all objects from Memory and print them in the log. (like a Mendix Memory dump).
If you're interested in the Java action just shoot me an email, don't want to put it on the forum cause their not using the API functions and are thus Mx release specific.

answered