Question

executeMicroflowInBackground and memory usage

1

Hi all, I have an issue with the executeMicroflowInBackground (Community Commons 4.3.1 for Mx 5.1.1. running in Mx 5.4.3) When using the executeMicroflowInBackground not all cached objects or memory is cleared. Resulting in the end in GC Overhead issues / Out of memory. I created a quick reproduction project containing: 1 Persistable object: Flag 1 Non persistable object: FlagTemp 1 SE event (running every 30 sec) calling a microflow: https://www.dropbox.com/s/a1zn3tao76twaw8/SS1.PNG?dl=0 The iteration is limited to 1000 counts per microflow run. 1 Java action executeMicroflowInBackground calling a microflow: https://www.dropbox.com/s/d5fe9sg4vgpeb35/SS2.PNG?dl=0 When I monitor the memory usage in Windows (running locally) each run increases the memory. After about 10 iterations of the scheduled event the memory is already at 500MB (instead of the usual 200MB-250MB) and encounting. I've eleminated the effect of persistable and non persistable objects (FlagTemp) by making this a persistable object and rerunning the scenario. When I replace the executeMicroflowInBackground with a Microflow Call the memory usage is still at 250MB after 20 iterations (with both the persistable and non persistable version). Which suggests that something of the executeMicroflowInBackground is kept in memory and can't be cleaned. Anyone familiar with this issue? Suggestions what might be the cause? With kind regards, Stephan Edit: problem also exists in Community Commons v5.3 Edit 2: In topic: https://community.mendix.com/questions/7120/Asynchronous-microflow-call-with-known-user another issue with executeMicroflowInBackground is discussed. Axel provides a piece of code in Misc.java which seems to fix the Memory leak (my issue) as well. However ticket 203785 suggesting this as a fix for CommunityCommons is closed without further information. Are there any drawbacks to this code and why wasn't it added to the CommunityCommons updates?

asked 2015-06-23

Stephan Bruijnis

1 answers

Jasper van der Hoek · Accepted Answer · 2015-06-23

Stephan, I see you are using 5.4? In the earlier Mx5 releases there were several memory related issues that could occur. In a later Mx5 release (5.12 if I remember correctly) there have been a significant amount of improvements to the memory usage. I prefer the 5.13.1 version myself, which seems to be the best performing Mx5 release so far.
I do recall several issues being solved regarding the garbage collection in combination with scheduled events. I would recommend to start with an upgrade to 5.13.1 because there isn't too much that you can do to influence the cache cleanup.

By looking at the code from the example, that might work in some scenario's. However the way that this code is setup, in case an exception occurs or if you ever choose to do anything with custom error handling in the async microflow you will mess up the transactions in all the other async microflows.

The way this action is setup they share a session, context, cache, and even the transaction. That would mean that if any action changes something in the transaction, cache etc. it will impact the other transactions too.

The microflows you posted won't provide any issues with the Java action, but I would not recommend using that action with more complicated microflows (read: microflows that use custom error handling or are likely to give exceptions such as integrations). So I hope that this solution will not make it into the community commons module.

To answer why this might solve your problem, the code uses the function session.retain and session.release those two functions tell the cache to keep the object until further notice. The release function instructs the cache that the object can be garbage collected.
The release function might trigger the cache to remove it proactively but I would not expect the release function to trigger the cleanup process though. In other words the release should only mark the object as applicable for removal, but should not proactively remove the object from cache (see also this new documentation page).