[
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)
ThreadMXBean
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: 10.4.0.0
>
> 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 API.
> 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.
