The JADE 2022 release meets tomorrow’s business demands.
Please add info into Monitor to assist with finding memory leaks.
Presumably a base size can be calculated based on object cache sizes, method cache sizes, number of users, etc. Without memory leaks, the actual memory size would be a little larger than that. With memory leaks, the actual size could be a lot larger.
This would presumably be a new sheet, perhaps combined with the CPU Consumption metrics requested in JAD-I-512.
Please document the calculation used in the knowledge base.
John Porter
To confirm, this request is for info that could help a user to identify nodes that may have memory leaks.
The essence of this is to show what the actual memory usage is, compared to what JADE knows about. The user can then investigate the difference.
If the heaps etc can be broken out and identified, so much the better.
We can do fully automatic leak identification and repair later. :-)
Are there documented ini file settings that would help the user with this?
What you say is true, but "assist with finding memory leaks" isn't the same as determining something has leaked.
The memory use information available today in Monitor is very limited, well buried, and poorly explained if at all.
Raising the profile of Memory, perhaps with an entry in the Navigator pane, could be helpful.
A windows process can query and access information about the allocated heaps. JADE knows the heaps it has specifically allocated, and what they are used for. This usage information would be helpful.
Information about the default process heap, and any other heaps allocated in the process, would be helpful, and could assist in identifying 3rd party product issues.
A number of difficulties surround this:
3rd party components may use as much memory as they like, and JADE won't know anything about them.
If you are doing things like string concatenation in JADE code, we will let you use an unbounded amount of memory.
It's quite difficult to determine that something is "leaked" while tasks are still running. We can only sensibly determine that a leak has occurred if we attempt to clean up and find things left over- hence the existing ini file settings.