D
dbeavon
Guest
I have a support case open with Progress at the moment regarding a memory leak in the _mproapsv. I can give you more details if you need them; I think the SP will be available in 11.7.5. Your issue may not be the same as ours. It would be helpful if you gave us a lot more explanation about your problem. How fast is the leak? Can you quantify it? What process name is actually leaking (_mproapsv.exe? java.exe? tomcat.exe?) One thing I would suggest doing is create a reproducible that you can play with *outside* of production. You can run your repro at high speed to amplify the problem. That may also allow you to isolate the portion of your code that leaks. In the end you might be left with something that you can send over to Progress tech support. Are you running on windows or linux? If windows then I would recommend a sysinternals tool: docs.microsoft.com/.../vmmap This tool is easy to use. And should help isolate the memory leak to a certain degree, and also quantify it. I suspect your leak will be seen as allocations in the native heap. Another thing I would do ... especially since your question hasn't been resolved after a month ... is to approach the PASOE problem from another angle. You can install the "oemanager" API and use a REST interface to trim your inactive ABL sessions on a recurring schedule (eg. on the hour or half hour). This is a very safe operation and could be enough to resolve a wide range of so-called "leaks". (Depending on the definition of "leak".) In the very least it will give you additional information to add to everything else that you know about your "leak". Trimming inactive ABL sessions can be accomplished via the OE manager rest interface. Here is a powershell script that shows how to trim inactive sessions from an ms-agent process: community.progress.com/.../36461 (Posted by me on 26 Dec 2017 14:04, with lots of help from Irfan) When an inactive session is trimmed, PASOE will clear out all the memory that is directly associated with the session. That may be half the battle. When new PASOE client requests arrive, PASOE will create fresh new sessions to replace the ones that were trimmed. Yet another thing you may want to look at is the tomcat manager console: httt://localhost:8810/manager/html The console may help in your troubleshooting, and may show when HTTP sessions are open for long periods of time. I don't know about SOAP, but where APSV is concerned sometimes the HTTP sessions can become orphaned for long periods of time and hold onto resources in the MSagent, thereby causing "leaks". This can be resolved administratively in the tomcat manager console by explicitly forcing the expiration of the HTTP sessions. Good luck isolating the leaks. As a side, I will point out that even Java and .Net code can have "leaks" when items on the heap are rooted in memory and the garbage collector is unable to clear everything out. It would be nice if PASOE had an operation that was analogous to forcing a GC.Collect() operation, which is something to help determine when there is truly a leak. The closest thing I've found to this (in the world of PASOE) is to trim inactive ABL sessions via the OE manager REST api.
Continue reading...
Continue reading...