db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
Date Wed, 05 Mar 2008 14:53:40 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575374#action_12575374

Daniel John Debrunner commented on DERBY-3435:

Thomas> Why not simply use: ActiveConnections 

I initially raised the concern that in the future there might be an attribute that returns
actual information about the active sessions, e.g. user name, time connected, last activity
etc. It seemed to me that a more natural name for that attribute would be ActiveConnections,
and be clearer for the user to have a different attribute ActiveConnectionCount.

Looking at the naming scheme for the JDK's MBeans (java.lang.management) it seems that Count
at the end of the attribute name is always used to represent an active count or a total count.
If required the word Total is used to indicated it's a "counter" in Bernt's terms.

  E.g. ClassLoadingMXBean
       LoadedClassCount  - current number of loaded classes
       TotalLoadedClassCount - total number of classes ever loaded
       UnloadedClassCount -  total number of classes ever unloaded (no need for Total since
there is no concept of current number of unloaded classes)

        ThreadCount - current live threads
        TotalStartedThreadCount - total number of threads started

I think we should follow established practice.

For "ActiveConnections/ActiveConnectionCount" what does the Active imply? Is it just the number
of current connections, in which case
the attribute should be "ConnectionCount", or is it the number of connections that are active
in some way. What way though? Have started
a transaction, executing a statement? If the latter then it would be useful to have a new
attribute "ConnectionCount".

PS. Bernt - any reason to start attaching small diffs in a zip format, makes it that many
more steps to get a quick look at the patch

> Add an MBean for monitoring and managing the Network Server
> -----------------------------------------------------------
>                 Key: DERBY-3435
>                 URL: https://issues.apache.org/jira/browse/DERBY-3435
>             Project: Derby
>          Issue Type: Sub-task
>          Components: JMX
>            Reporter: John H. Embretsen
>            Assignee: John H. Embretsen
>             Fix For:
>         Attachments: d3435_v01.diff, d3435_v01.stat, derby-3435-live-data-fix-v0.zip,
derby-3435-live-data-v0.diff, derby-3435-live-data-v0.stat, derby-3435-live-data-v1.zip, derby-3435-live-data-v2.zip
> Most functionality of and information about a running instance of the Network Server
is currently only available from the host running the Network Server, using the NetworkServerControl
> With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it
is possible to expose some of the Network Server functionality and information through an
MBean that is specific to the Network Server, to both local and remote users (JMX clients),
subject to security restrictions. Access to Derby libraries on the client side is not even
a requirement, potentially making a server administrator's job a lot easier.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message