D
dbeavon
Guest
Ok thanks. Your first paragraph above answers most of my concerns. I opened a support case for a problem where memory usage continues to grow at an uncontrolled pace, despite the fact that we only have about five abl sessions ever running at a time in an msagent process. And even those few sessions are trimmed hourly and recreated on demand. I suspect that our code may be using some type of abl handle or object or persistent procedure that isn't very well-behaved in the context of a passenger agent. (It may be a xml-dom-related handles, or file streams, or perhaps the jms adapter, if I had to guess.). I will assume that the expected behavior is that ALL of these types of things (and related memory) are supposed to be cleaned once the abl session is trimmed from the agent. In other words the trimming of a session should serve the purpose of releasing memory, without requiring us to micro-manage every handle, object, or procedure. To mitigate against ongoing memory leaks, I think it would be really nice if you guys did some additional/automatic housekeeping when the number of sessions in an agent went all the way down to ZERO. This happens multiple times a day in our environment, given that we are trimming inactive sessions so frequently. It seems like you could essentially reset the entire agent process back to it's original state (as it was at the moment it started). This would allow you to free up every possible resource that might have been orphaned along the way (and can't be attributed to any particular session).
Continue reading...
Continue reading...