• Deprecate existing Admin API and JMX
  • Build new com.gemstone.gemfire.management API using Standard MBeans modeling MXBeans
    • New MBeans will be defined and stats will carefully selected to expose as Attributes
    • Design will emphasize use of JMX Notification to allow JMX clients to "listen" for changes instead of excessive polling
  • Every GemFire member will be "manageable"
    • GemFire MBeans for the local process will automatically be registered in the Platform MBeanServer
    • Scripts and launchers should be rewritten so that "cacheserver stop/status" uses a simple MBean in the member
      • This requires the script to specify the JMX port
    • A local MBean Filter will be designed which allows user to specify types of MBeans that will (or will not) auto-register (this requires a non-runtime configuration)
    • JMX Remote RMI Connector will be enabled by default and be modeled after the approach used in Virgo Server
  • Every GemFire member may optionally be configured to provide management and thus "manage" other GemFire members
    • The "managing" member's MBeanServer is the master which will connect to every other member's MBeanServer (subordinates)
    • See MBeanServer Federation Strategy
    • New Member Filter MBean will be created which allows user to limit which remote members are managed/federated
    • Managing members will register aggregate MBeans in addition to federated MBeans
      • These aggregate MBeans provide roll-up views of the entire GemFire system
    • New remote MBean Filter to specify types of federated MBeans that will be exposed via proxies
      • Same as the local MBean Filter but a "managing" member should be able to have both Filters configured differently
    • New Platform Delegate MBeans that extend or wrap selected Platform MXBeans will be added to the Management API
      • These are copies of Platform MBeans which add Member Id to the object name and can thus be federated to master MBeanServers
        • Example: MemoryMXBean with ObjectName "java.lang:type=Memory" is mirrored by:
          • Option 1: MemberMemoryMBean with ObjectName "GemFire:type=Platform,subDomain=java.lang,subType=Memory,id=server1"
          • Option 2: MemberMemoryMBean with ObjectName "GemFire:type=Member,id=server1,domain=Platform,subDomain=java.lang,subType=Memory"
  • Customers will be able to create and deploy custom MBeans (implementations of these may access other MBeans as well as GemFire APIs)
  • Customers desire non-transient MBeans. In order to support this we need a [Persisted Configuration]
  • Security requirement: MBean invocations must go through GemFire's security layer in the same way that cache client requests do. At a minimum this will likely require creating two new security operations: Management Read, Management Write. Anything reading would require the Management Read permission, while anything that modifies/creates/writes will require the Management Write permission.
  • No labels