EVALUATION
This is indeed a bug.
The culprit seems to be:
sun/management/snmp/jvminstr/JvmMemPoolEntryImpl.java
This class uses the keys 'memoryTag', 'peakMemoryTag' and
'collectMemoryTag' to cache the memory Usage, memory PeakUsage,
and memory CollectionUsage in the request-contextual cache - but
these keys do not contain any instance (=line) identification.
As a result all the lines in the table will use the same key, which is wrong.
The fix is quite simple.
I believe the methods getMemoryUsage(), getPeakMemoryUsage(), and
getCollectMemoryUsage() should use a key composed of:
memoryTag+"."+jvmMemPoolIndex,
peakMemoryTag+"."+jvmMemPoolIndex,
collectMemoryTag+"."+jvmMemPoolIndex
instead.
What happens is that since the key doesn't contain the index id,
the first data which is put into the cache is returned for all
the lines, since all the lines are using the same keys.
Each line should use its own key, and the way it's done elsewhere
in the code is by appending "." + the value of the index to the common
root. If I'm not mistaken that's the root of the bug.
The only methods that should need to change are the method which use the
memoryTag, peakMemoryTag, and collectMemoryTag variables, and I believe
only the three methods getMemoryUsage(), getPeakMemoryUsage(), and
getCollectMemoryUsage() are concerned by this.
It would be good to check whether the other XXXXXEntryImpl classes
in the jvminstr package also have these bug.
I suspect that any table entry representing an MXBean exposing a
complex attribute (like MemoryUsage) will have this bug - they're
all built on the same model.
|
Java