HelloWe are developing our system using LS. It’s base on ower own LS classes. There is a problem - ls agent executes correctly till the end but hangs on terminating (it is still executing…).
I tink it’s because of forced memory clean that we are making (using command “Delete”) - if we will not clean mem server will down extremally fast.
Do you have any solutions of our problem / suggetions?
Thank you
Subject: some questions
Do you have an idea why it is necessary to use the Delete statement to avoid memory leaks? For example, are you accessing external binaries from your LS code (LS2J, some C code, some LSX, …), and could they be causing memory leaks? Or could cyclic object references (object A referencing B > referencing C > referencing A) be fooling LS memory management?
My personal experience has been that the built-in memory management of LS is usually quite stable and reliable. On the other hand, I have seen the Delete statement crashing the Agent Manager, which is why I try to stay away from it as much as possible.
Subject: answer
We don’t use any external libs, LS2J and so on. It’s quite possible that we have “cyclic object references”. In any case using statement “Delete” delays server crash for 15-20 days… It will be great if server will be stable without using “Delete”.
Subject: Do do Delete
My experience has been the opposite; explicit use of Delete can prevent problems, especially with custom objects. When I’ve had crashes, it was because I didn’t use enough Deletes.
Subject: interesting
So I’m trying to remember what exactly may have been the reason why my own experience with Delete was so negative. The only thing I can remember is that some of my custom classes had a Sub Delete, and if memory (mine 
serves well, I was able to avoid the crashes (occurring after calling explicit Delete) when I outcommented all my Sub Deletes.
I never got to know exactly why Delete was crashing my code, because in the meanwhile I had re-organized it, so out-of-memory problems were gone. Key was three things, in descending order of relevance: (a) avoid keeping many – more than a few dozens – NotesDocument instances in memory at the same time, (b) re-use objects whenever possible, instead of re-instantiating them, and (c) eliminate cyclic object references.
Anyway, I’ll certainly give Delete a closer look, next time I’ll have an opportunity (a need, that is) to.
P.S.
I just looked up my related thread in the Partner Forum 2004 (oh my, that long ago…) Julie Kadashevich responded “By doing a delete the object chain is put in a bad state. So, when the official clean up happens at agent termination LotusScript gets into an infinite loop.” I think her response was what ultimately made me stay away from using explicit Delete.
Subject: If you explicitly delete everything
then there’s not a problem. If you delete nothing, there may be a problem anyway. So the safe way is to delete everything.
It’s in the queue to fix; you really shouldn’t have to delete anything that’s not cached (like a NotesDocument) or have an outside component that has to be freed at a particular time, or is a cyclic reference (and even those should go away when your script terminates).
Subject: There is one issue with Delete…
Hope this helps…
Subject: *thanks for clarifying
Subject: Andre - “in the queue”? CRISPY
Can you be more specific on work in Delete/Recycle area, or a target release? I can ask in the DP RNext forum if that’s a more appropriate place.
Subject: No, I can’t…
…it’s SPR work, which can always get displaced if there are more urgent issues discovered that we need the same developer for. All I can say is it’ll get fixed when it’s fixed. If you think the priority needs to be higher, you can open a support incident. I personally think it should be a top priority, but I’m not a customer so my opinion doesn’t count for much.
Subject: Ok, thanks.
I was hoping when you said “in the queue” you meant slated for an upcoming release. Considering I’ve got a doozy of a 6-month PMR that in the end may turn out to simply be an LS memory leak, I’d definitely vote for this type of stuff to be cleaned up (no pun intended.) 
Subject: Erik, please send me the PMR number.
SPRs AGUD7VWQ5K, AGUD82SKP3, JGUO7XALNX seem like they might be related to this problem.
Subject: Andre, do you have an SPR# for Delete/Recycle?
Subject: Thanks, email sent.