0N/A#==============================================================================
0N/A# JVM Management MIB - Instrumentation Classes
0N/A#==============================================================================
0N/A that I have used to generate & compile all the
0N/A stuff. Probably only valid in my own environment.
0N/A*.java: utility and custom classes for the JVM Management MIB.
0N/A These classes show how to provide instrumentation for
0N/A a mibgen generated MIB, how to simulate virtual tables,
0N/A and how to make use of the SnmpUserDataFactory.
0N/A Only the jvmMemory group and its tables are instrumented.
0N/A Tiger SNMP Runtime : SNMP Runtime classes for Tiger. We assume these
0N/A classes could be part of the JMX delivery
0N/A to start mibgen. By default mibgen generates code that can
0N/A integrate with JDMK SNMP runtime. In order to generate
0N/A code that integrate with Tiger SNMP runtime, you need to
0N/A start mibgen with a non-default resource file.
0N/A JDMK 5.1 workspace contains a mibgen resource file
0N/A Custom Instrumentation Code: the files in this directory.
0N/AGet mibgen from JDMK 5.1. Start mibgen with mibgen resource file for
0N/Aon the Java command line.
0N/Athe custom classes provided in this directory are all in the
0N/AIf this package name does not suit you, simply change it to something else,
0N/Aboth in the custom classes below (you might use 'sed' or do it manually)
0N/Aand in the -tp option that you will pass to mibgen.
0N/AIt is recommended to generate all classes in a different directory (if
0N/Ain a "custom" directory, and the generated classes in a "parsed"
0N/Adirectory. This makes it easier to cleanup the mib. You can safely
0N/Ado a rm -rf <parsed> and call mibgen again.
0N/AThen compile the generated classes - you will need JMX and Tiger SNMP
0N/Aruntime classes in your classpath - if you compile with a tiger build that
0N/Aalready have them then you don't need to specify anything special.
0N/AThen make your classpath point to the compiled generated classes, and
0N/Acompile the custom code in this directory.
0N/AThen you can use the SnmpDaemonTest class to start a JVM with the
0N/Aintsrumented MIB, and you can use
e.g. the easymanager contrib of
0N/AJDMK to view the MIB through SNMP.
0N/A#==============================================================================
0N/A#==============================================================================
0N/AUtility Classes developped for the JVM Management MIB:
0N/A------------------------------------------------------
0N/A serves as request contextual cache.
0N/A Values obtained from JSR 163 API can be
0N/A cached in this object.
0N/A A request contextual cache is allocated
0N/A each time a request is being processed,
0N/A and is released at the end of processing.
0N/A Object: 1) preserve atomicity
0N/A 2) minimize API calls
0N/A 3) ensure consistency of the
0N/A various pieces of data returned.
0N/A of the data contained in a table.
0N/A computed on demand and cached in a
0N/A weakreference. Makes it possible to specify
0N/A a validity period for the cache data.
0N/A data is returned in a List object.
0N/A elements can be named by a unique string.
0N/A the JVM Managemnt MIB in Tiger's SNMP
0N/A adaptor. This is the "main". Note that
0N/A this not the class that will be used to
0N/A start the adaptor in the final Tiger - it is
0N/A just a dummy test main.
0N/A Object: overriding factory method in order
0N/A to instantiate custom code instead
0N/A group. Replaces the generated JvmMemory class,
0N/A which is not used and can be thrown away.
0N/A Implements the generated JvmMemoryMBean
0N/A interface (which was also implemented by
0N/A the generated JvmMemory skeleton class)
0N/A Use the request contextual cache
0N/A in order to ensure consistency when
0N/A returning MemoryUsage datas. Note that all
0N/A tables in this group have been implemented
0N/A as virtual tables. As a consequence, the
0N/A Subclasses the generated JvmMemoryMeta class.
0N/A Object: overrides the factory methods in order
0N/A to instantiate custom meta data classes
0N/A for the jvmMemManagerTable,
0N/A jvmMemMgrPoolRelTable.
0N/AJVM Memory Manager Table
0N/A------------------------
0N/A jvmMemManagerTable. This MetaData traps
0N/A all the SNMP Runtime calls made to the
0N/A table - in order to make the Memory Manager
0N/A table virtual:
i.e. the table does not have
0N/A to be maintained permanently in memory.
0N/A Instead, the table is computed "on demand",
0N/A and the data is cached in a weak cache
0N/A (see SnmpNamedListTableCache) which remains
0N/A valid for a few ms. If the data is found
0N/A to be obsolete, or was garbage collected,
0N/A the table is recomputed.
0N/A Entries are created on the fly when it
0N/A becomes necessary to get data from a
0N/A Memory Managers. They are temporary objects
0N/A that wrap the MemoryManager just for the
0N/A call duration - and are released just after.
0N/A jvmMemGCTable. This MetaData traps
0N/A all the SNMP Runtime calls made to the
0N/A table - in order to make the GC
0N/A table virtual: the GC table reuses the
0N/A cached data computed for the
0N/A jvmMemManagerTable - simply acting as a
0N/A filter that only shows those elements that
0N/A are instance of GarbageCollectorMetrics.
0N/A In other words it implements a fitered view
0N/A of the jvmMemManagerTable.
0N/A GarbageCollectorMetrics objects. Objects
0N/A of this classes are created on the fly,
0N/A when data needs to be returned from a
0N/A GarbageCollectorMetrics object, and are
0N/A released just after. They are not kept in
0N/AJVM Memory Pool Table
0N/A---------------------
0N/A This is quite similar to what was done for
0N/A the jvmMemManagerTable in
0N/A JvmMemManagerTableMetaImpl. Most of the code
0N/A here was obtain by cut&paste-ing from
0N/A JvmMemManagerTableMetaImpl and replacing
0N/A "Manager" with "Pool".
0N/A MemoryPoolMetrics objects. Objects
0N/A of this classes are created on the fly,
0N/A when data needs to be returned from a
0N/A MemoryPoolMetrics object, and are
0N/A released just after. They are not kept in
0N/A memory. Use the request contextual cache
0N/A in order to ensure consistency when
0N/A returning MemoryUsage datas.
0N/AJVM Memory Manager / Memory Pool Relation Table
0N/A------------------------------------------------
0N/A jvmMemMgrPoolRelTable. This meta data
0N/A uses the JvmMemManagerTableMetaImpl and
0N/A JvmMemPoolTableMetaImpl in order to
0N/A find out the content of the
0N/A jvmMemManagerTable and the mapping between
0N/A Memory Pool Name and Memory Pool Index.
0N/A For each element of the jvmMemManagerTable
0N/A it calls the JSR 163 APIs to find the
0N/A related Memory Pool, then finds out their
0N/A index, and then creates the corresponding
0N/A row in the jvmMemMgrPoolRelTable cached data.
0N/A Like all the other tables, this table is
0N/A virtual: the data is kept on a weak cache
0N/A and recomputed on demand, if its validity
0N/A as expired or if it has been gc'ed.
0N/A Models a row in the jvmMemMgrPoolRelTable.
0N/A Objects of this type are cached in the
0N/A jvmMemMgrPoolRelTable cached data.
0N/A#==============================================================================
0N/A#==============================================================================