Fix or depreciate PROPAGATE...DELETE NONE

Hi Jeff, thanks for raising the idea and apologies for the delay in responding. On this occasion I'm afraid we don't intend to take this suggestion forward. We have reviewed the support case (TS016843219) that was mid-flight when the idea was initially created and from the record it looks like all parties were ultimately happy for the case to close and that the problem was successfully resolved.

For the benefit of other curious readers, the initial issue related to a message flow which was exhibiting large memory usage and on investigation this appeared related to an abnormally large number of parser objects being created and being allocated memory which was then not being cleared/reused. There are some possible circumstances where flow developers can accidentally create looping constructs within flow logic which cause memory growth that looks like a memory "leak" when observed externally. An example of this could be when using the PROPAGATE function in ESQL, especially if placed within a loop. When using PROPAGATE, the next statement in your ESQL is not executed until all the processing of the message in downstream nodes has completed. As noted, it is also possible to use the DELETE NONE clause on a PROPAGATE. If the DELETE clause is absent, then the output local environment, message, and exception list are all cleared and their memory is recovered immediately after propagation. However if DELETE is set to NONE, then nothing is cleared. You would typically only use DELETE NONE if you want each propagate to start with the content of the local environment and message trees to be what was created by the previous propagate rather than starting with empty trees. This situation can lead to large memory usage if each PROPAGATE essentially adds more to the in memory objects that were created by the previous PROPAGATE … and so on … many times over ... as you execute lots of loop iterations.

We acknowledge that this might look similar to a memory leak but is actually quite distinct. Given that a user has to explicitly choose the "DELETE NONE" clause as an active coding decision, we don't feel there is undue risk in allowing this option on the command for those users who choose to use it and derive benefit, as it can also be helpful in situations where looping is not necessarily involved, or when users take care not to let their tree structures grow out of control.