You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jon Hermes (JIRA)" <ji...@apache.org> on 2011/03/11 20:59:59 UTC

[jira] Created: (CASSANDRA-2314) Reorder JMX heirarchy and expose all exposable tunables via JMX

Reorder JMX heirarchy and expose all exposable tunables via JMX
---------------------------------------------------------------

                 Key: CASSANDRA-2314
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2314
             Project: Cassandra
          Issue Type: Improvement
            Reporter: Jon Hermes
            Assignee: Jon Hermes
            Priority: Minor
             Fix For: 0.8


For all per-node options:
- StorageService should have a JMX call to change any modifiable per-node config option at runtime.

For all per-CF options:
- Each KSMD needs to sit on its respective Table 
- Each CFMD needs to sit on its respective CFS (though SST{R,W} also needs to be able to access the CFMD in a tight loop)
- As before, all modifiable config opts should have a matching JMX call in Table/CFS
- Temporary changes are stronger than the schema and don't go away until reboot or...
- an unsetOption() per-option should be available to revert any local config changes.

Approx. MBean Hierarchy:
{noformat}
        o.a.c.db (tree root)
       /   |    |      |    \
      SS   CM   HHOM   CL   KEYSPACES
     /   (I/OM)             /     |   \
 Config                    K1    K2    ...
   |   \                  /  \\\  ...
(D)EPS <NodeOpts>     Table   |\\_
                     /       /  \  \
                <KSOpts>    /    |  ...
                          CF1   CF2
                         /  \   ...
                       CFS1  |
                      /    CACHES
                   <CFOpts>   |  \
                             key row 
{noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-2314) Reorder JMX heirarchy and expose all exposable tunables via JMX

Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CASSANDRA-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis resolved CASSANDRA-2314.
---------------------------------------

       Resolution: Won't Fix
    Fix Version/s:     (was: 1.0)
         Assignee:     (was: Jon Hermes)

> Reorder JMX heirarchy and expose all exposable tunables via JMX
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-2314
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2314
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jon Hermes
>            Priority: Minor
>
> For all per-node options:
> - StorageService should have a JMX call to change any modifiable per-node config option at runtime.
> For all per-CF options:
> - Each KSMD needs to sit on its respective Table 
> - Each CFMD needs to sit on its respective CFS (though SST{R,W} also needs to be able to access the CFMD in a tight loop)
> - As before, all modifiable config opts should have a matching JMX call in Table/CFS
> - Temporary changes are stronger than the schema and don't go away until reboot or...
> - an unsetOption() per-option should be available to revert any local config changes.
> Approx. MBean Hierarchy:
> {noformat}
>         o.a.c.db (tree root)
>        /   |    |      |    \
>       SS   CM   HHOM   CL   KEYSPACES
>      /   (I/OM)             /     |   \
>  Config                    K1    K2    ...
>    |   \                  /  \\\  ...
> (D)EPS <NodeOpts>     Table   |\\_
>                      /       /  \  \
>                 <KSOpts>    /    |  ...
>                           CF1   CF2
>                          /  \   ...
>                        CFS1  |
>                       /    CACHES
>                    <CFOpts>   |  \
>                              key row 
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira