This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata
  • 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