D
dbeavon
Guest
>> PASOE agents are the longest-lived OE processes we have ever worked with ... On that note I think there could be a solution to memory issues that is tailored to the design of PASOE as a whole. For example, I think as a reasonable and fix, there should be an upper limit on the MSagent's memory usage. If the _mproapsv process grows above some mind-blowing value like 5 GB, then the ABL application should gracefully abandon that original _mproapsv process and just start a new one. The original _mproapsv process could just be flagged for deletion after it goes idle. Unless tech support can prioritize the analysis of a memory dump, my plan at this point is to wait for another large customer to start reporting leaks in PASOE (maybe QAD will start adopting this soon)? And I can benefit from their efforts. I've already worked on a few PASOE tech support issues myself. ... and I would spend more time on this too if I could do it productively. But coming up with a repro is very challenging when the leak is "only" a few MB per hour, and is in native memory that is outside the boundaries of the AVM sessions. If someone could tell me what is contained in the process memory dump, then it might give me the hint I need to create a repro. It seems like it has to be a collaborative process, and I cannot build a repro on my own, as things stand right now. Another thing I'm hoping Progress might do is to eventually enable _mproapsv inactivity timeouts in the PASOE product by *default*. (It is hard to trust the way we specify this resource timeout configuration in PASOE today, and I suspect that few people are actually using it to cycle their _mproapsv processes .)
Continue reading...
Continue reading...