Question

Effect of non-persistent entities used in scheduled events on memory usage?

2

We notice significant memory increase. The tenured generation space increase rapidly when a microflow is called by a scheduled event action. In the scheduled event (daily) there is a list of items for which a day report needs to be generated. For each day report, in a loop, a microflow is called. In this microflow, we retrieve 288 non-persistent entities via a rest call, do some processing (average, max, min) and store the results in another persistent data structure. Thereafter we delete the 288 non-persistent entities that have been retrieved via a rest call. Thereafter the microflow is called again and again till all day reports are generated. Does anyone know what the effect is of a delete action on a non-persistent entity in a schedule event? Is the effect of the delete action that de data of the non-persistent entity is moved to the survivor space, tenured generation space or directly completely removed from memory? Other question is how garbage collection works for scheduled events. Non-persistent entities on the client side are removed when the client side is closed. What happens when the scheduled event is finished, are non-persistent entities removed ? Or are the microflows that are used in a scheduled event not removed and kept in memory for the next call of the scheduled event ?

asked 2020-09-28

Robert Jan Gorter

1 answers

Sander Schaeffer · Answer 1 · 2020-10-01

Not really an answer, but have you have thought of moving the actions inside the scheduled event into separate tasks executed through the Process Queue widget or by using the Follow-Up widget?

For example, we’ve got an application that, on a daily basis, retrieves for each client in the system all new dossiers to process. Instead of retrieving all data simultaneously in a single scheduled event, the application creates a queued item for each client that gets executed separately. This way the amount of memory used is reduced by a lot. It also allows for error handling, i.e. when one client fails for a specific reason, another could still continue.