You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In munin.py:get_stats_from_runtime the Java JVM memory values are retrieved from the runtime statistics. The response on Mendix 8 (with Java 11) is this:
The methods make a decision based on the existence of memory.memorypools which exists and then retrieves values from the response. But, comparing the variable names with the assignment we see a mismatch.
Issue mendix#52
For Java 11, use memory pool names as returned by runtime to
extract values instead of relying on their specific order.
m2ee used to take Compressed Class Space as permanent type.
However, according to http://performantcode.com/jvm/permgen-and-metaspace/,
permanent (PermGen) was renamed to metaspace. And according to
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html,
which says "The MaxMetaspaceSize applies to the sum of the
committed compressed class space and the space for the other
class metadata.", compressed class space seems to be part of
metaspace. Thus, there is a significant difference in what
is considered 'permanent' in this new code.
This could also be applicable for older Java versions but for
now let's keep old behavior as it is not sufficiently tested.
It would, however, be great to clean this up a bit, so we can
consider this a TODO.
In munin.py:get_stats_from_runtime the Java JVM memory values are retrieved from the runtime statistics. The response on Mendix 8 (with Java 11) is this:
The methods make a decision based on the existence of memory.memorypools which exists and then retrieves values from the response. But, comparing the variable names with the assignment we see a mismatch.
This results in internal ticket DEP-2484.
The text was updated successfully, but these errors were encountered: