Derby
  1. Derby
  2. DERBY-1387 Add JMX extensions to Derby
  3. DERBY-3435

Add an MBean for monitoring and managing the Network Server

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.4.1.3
    • Component/s: JMX
    • Labels:
      None

      Description

      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.

      1. derby-3435-live-data-v2.zip
        2 kB
        Bernt M. Johnsen
      2. derby-3435-live-data-v1.zip
        2 kB
        Bernt M. Johnsen
      3. derby-3435-live-data-v0.stat
        0.4 kB
        Bernt M. Johnsen
      4. derby-3435-live-data-v0.diff
        6 kB
        Bernt M. Johnsen
      5. derby-3435-live-data-fix-v0.zip
        1 kB
        Bernt M. Johnsen
      6. derby-3435-live-data-fix2-v0.diff
        3 kB
        Bernt M. Johnsen
      7. d3435_v01.stat
        0.3 kB
        John H. Embretsen
      8. d3435_v01.diff
        19 kB
        John H. Embretsen
      9. d3435_NetworkServerMBeanTest_v01.diff
        16 kB
        John H. Embretsen
      10. d3435_javadocUpdates.diff
        29 kB
        John H. Embretsen

        Activity

        Hide
        John H. Embretsen added a comment -

        The patch d3435_v01.diff defines and implements an MBean for monitoring
        and (future work) management of the Network Server.

        Although the MBean works, it is currently limited to exposing read-only
        attributes only (i.e. no management functionality), in addition to the
        ping() operation, so I consider this just to be a start of what could
        eventually become a very useful bean for server administrators.

        Patch contents:

        A java/engine/org/apache/derby/mbeans/drda

        New package for Network Server mbeans (included in derbynet.jar)

        A java/engine/org/apache/derby/mbeans/drda/NetworkServerMBean.java

        The defining interface of the MBean. The following read-only attributes are
        available:

        ([Attribute] - [associated server property])
        DrdaHost - derby.drda.host
        DrdaKeepAlive - derby.drda.keepAlive
        DrdaMaxThreads - derby.drda.maxThreads
        DrdaPortNumber - derby.drda.portNumber
        DrdaSecurityMechanism - derby.drda.securityMechanism
        DrdaSslMode - derby.drda.sslMode
        DrdaStreamOutBufferSize - derby.drda.streamOutBufferSize
        DrdaTimeSlice - derby.drda.timeSlice
        DrdaTraceAll - derby.drda.traceAll
        DrdaTraceDirectory - derby.drda.traceDirectory

        The ping() operation requires the permission

        permission java.net.SocketPermission "*", "connect,resolve";

        ("*" may be replaced, depending on the -h option of the server)
        granted to derbynet.jar in order to work, due to the way the network
        server is currently implemented.

        A java/drda/org/apache/derby/impl/drda/NetworkServerMBeanImpl.java

        The implementation of NetworkServerMBean. Instruments NetworkServerControlImpl.

        M java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java

        • removes some unused imports
        • registers the MBean at server startup
        • unregisters the MBean at server shutdown
        • relaxes the modifier of the method getPropertyValues() from private
          to package-private in order to allow access to server settings from the
          MBean impl. without having to use a network connection.

        M tools/javadoc/publishedapi.ant

        Adds org.apache.derby.mbeans.drda to the publishedAPI javadocs.

        The patch includes some commented code copied from patch 9 of DERBY-1387,
        as a temporary reminder of the functionality initially proposed as part of
        that Jira issue. This code should eventually be removed and/or replaced by
        real code once the community agrees on and implements a security model for
        Derby's JMX functionality.

        Show
        John H. Embretsen added a comment - The patch d3435_v01.diff defines and implements an MBean for monitoring and (future work) management of the Network Server. Although the MBean works, it is currently limited to exposing read-only attributes only (i.e. no management functionality), in addition to the ping() operation, so I consider this just to be a start of what could eventually become a very useful bean for server administrators. Patch contents: A java/engine/org/apache/derby/mbeans/drda New package for Network Server mbeans (included in derbynet.jar) A java/engine/org/apache/derby/mbeans/drda/NetworkServerMBean.java The defining interface of the MBean. The following read-only attributes are available: ( [Attribute] - [associated server property] ) DrdaHost - derby.drda.host DrdaKeepAlive - derby.drda.keepAlive DrdaMaxThreads - derby.drda.maxThreads DrdaPortNumber - derby.drda.portNumber DrdaSecurityMechanism - derby.drda.securityMechanism DrdaSslMode - derby.drda.sslMode DrdaStreamOutBufferSize - derby.drda.streamOutBufferSize DrdaTimeSlice - derby.drda.timeSlice DrdaTraceAll - derby.drda.traceAll DrdaTraceDirectory - derby.drda.traceDirectory The ping() operation requires the permission permission java.net.SocketPermission "*", "connect,resolve"; ("*" may be replaced, depending on the -h option of the server) granted to derbynet.jar in order to work, due to the way the network server is currently implemented. A java/drda/org/apache/derby/impl/drda/NetworkServerMBeanImpl.java The implementation of NetworkServerMBean. Instruments NetworkServerControlImpl. M java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java removes some unused imports registers the MBean at server startup unregisters the MBean at server shutdown relaxes the modifier of the method getPropertyValues() from private to package-private in order to allow access to server settings from the MBean impl. without having to use a network connection. M tools/javadoc/publishedapi.ant Adds org.apache.derby.mbeans.drda to the publishedAPI javadocs. The patch includes some commented code copied from patch 9 of DERBY-1387 , as a temporary reminder of the functionality initially proposed as part of that Jira issue. This code should eventually be removed and/or replaced by real code once the community agrees on and implements a security model for Derby's JMX functionality.
        Hide
        John H. Embretsen added a comment -

        Some suggestions for follow-up work:

        • add attributes for monitoring:
        • number of active sessions
        • total number of connections since server started (connNum)
        • replication status
        • size of queue of sessions waiting for a free thread (runQueue)
        • number of DRDAConnThreads waiting for something to do (freeThreads)
          (etc.)
        • add the rest of the NetworkServerControl functionality as operations and attribute setters (once we have adequate security mechanisms in place)
        Show
        John H. Embretsen added a comment - Some suggestions for follow-up work: add attributes for monitoring: number of active sessions total number of connections since server started (connNum) replication status size of queue of sessions waiting for a free thread (runQueue) number of DRDAConnThreads waiting for something to do (freeThreads) (etc.) add the rest of the NetworkServerControl functionality as operations and attribute setters (once we have adequate security mechanisms in place)
        Hide
        Daniel John Debrunner added a comment -

        I'll commit the patch in a few minutes with a minor change:

        changed the implementation of the bean to be package private.

        Minor comments.

        The ping command didn't work for me, maybe a permission issue.

        I also think the javadoc for the ping operation should clearly indicate it's a ping from the same machine as the network server.

        Exception handling for ping and the set methods (when added) may need changing. If the exception chain includes a class that is not present on the client. I hit this yesterday with a EmbedSQLException from a test MBean.

        Show
        Daniel John Debrunner added a comment - I'll commit the patch in a few minutes with a minor change: changed the implementation of the bean to be package private. Minor comments. The ping command didn't work for me, maybe a permission issue. I also think the javadoc for the ping operation should clearly indicate it's a ping from the same machine as the network server. Exception handling for ping and the set methods (when added) may need changing. If the exception chain includes a class that is not present on the client. I hit this yesterday with a EmbedSQLException from a test MBean.
        Hide
        Daniel John Debrunner added a comment -

        I think the o.a.d.mbeans.drda package should be under java/drda, not java/engine. Any reason it was added to java/engine?

        Show
        Daniel John Debrunner added a comment - I think the o.a.d.mbeans.drda package should be under java/drda, not java/engine. Any reason it was added to java/engine?
        Hide
        John H. Embretsen added a comment -

        Thanks for looking at the patch!

        Package placement: No reason, I just didn't think of placing it in java/drda, so feel free to move it.

        The Exception handling issue is known from DERBY-1387 - I did not provide a solution as part of this patch.

        Yes, the ping command requires a SocketPermission (as stated above). Even with the permission I'm not sure it will always work, since the NetworkServerControlImpl instance is not designed to ping itself. For example, if "-h 0.0.0.0" is specified, it pings the host 0.0.0.0 instead of localhost (which works, but there may be other values of -h that won't, I guess).

        I agree with the javadoc suggestion and that the implementation class should be package private.

        Show
        John H. Embretsen added a comment - Thanks for looking at the patch! Package placement: No reason, I just didn't think of placing it in java/drda, so feel free to move it. The Exception handling issue is known from DERBY-1387 - I did not provide a solution as part of this patch. Yes, the ping command requires a SocketPermission (as stated above). Even with the permission I'm not sure it will always work, since the NetworkServerControlImpl instance is not designed to ping itself. For example, if "-h 0.0.0.0" is specified, it pings the host 0.0.0.0 instead of localhost (which works, but there may be other values of -h that won't, I guess). I agree with the javadoc suggestion and that the implementation class should be package private.
        Hide
        Daniel John Debrunner added a comment -

        Commited slightly modified version of v01 patch with revisions Revision: 629536 & 629537.
        Make the MBean implemetation package private
        Put o.a.d.mbeans.drda under java/drda

        Thanks John.

        Show
        Daniel John Debrunner added a comment - Commited slightly modified version of v01 patch with revisions Revision: 629536 & 629537. Make the MBean implemetation package private Put o.a.d.mbeans.drda under java/drda Thanks John.
        Hide
        Daniel John Debrunner added a comment -

        Some potential javadoc improvements for NetworkServerMBean

        • add a package.html
        • Have the class javadoc define what type and other key properties are used (see the other MBeans)
        • Remove this vacuous sentence:
          This interface consists of getter and setter methods for attributes that may be read and/or modified, and methods representing operations that can be invoked.
          (it's adds no value, it's the definition of what an MBean is, it's like adding a comment to other classes "this interface consists of methods that can be called and fields that can be referenced").
        • Correct the comment for getDrdaHost related to 0.0.0.0, it indicates it affects which clients can connect, I think it means that the server listens on all network interfaces
        • For each attribute getXXX method add a summary of what the property does, just saying it gets derby.drda.XXX doesn't really help much.
        • Make the first javadoc sentence of the getXXX methods be the (English) summary of what the attribute represents and not just that it maps to derby.drda.XXX. This means the class summary in javadoc becomes more useful, e.g.

        Gets the host name for the network server

        instead of the current

        Gets the value of the derby.drda.host network server setting.

        Show
        Daniel John Debrunner added a comment - Some potential javadoc improvements for NetworkServerMBean add a package.html Have the class javadoc define what type and other key properties are used (see the other MBeans) Remove this vacuous sentence: This interface consists of getter and setter methods for attributes that may be read and/or modified, and methods representing operations that can be invoked. (it's adds no value, it's the definition of what an MBean is, it's like adding a comment to other classes "this interface consists of methods that can be called and fields that can be referenced"). Correct the comment for getDrdaHost related to 0.0.0.0, it indicates it affects which clients can connect, I think it means that the server listens on all network interfaces For each attribute getXXX method add a summary of what the property does, just saying it gets derby.drda.XXX doesn't really help much. Make the first javadoc sentence of the getXXX methods be the (English) summary of what the attribute represents and not just that it maps to derby.drda.XXX. This means the class summary in javadoc becomes more useful, e.g. Gets the host name for the network server instead of the current Gets the value of the derby.drda.host network server setting.
        Hide
        Daniel John Debrunner added a comment -

        To complete the last thought, I think the javadoc should continue to contain the reference to the derby.drda.XXX setting, just not as the primary sentence.

        Show
        Daniel John Debrunner added a comment - To complete the last thought, I think the javadoc should continue to contain the reference to the derby.drda.XXX setting, just not as the primary sentence.
        Hide
        John H. Embretsen added a comment -

        Thanks for the commit. Seems like you forgot to actually move the MBean interface to java/drda - now I see the org.apache.derby.mbeans.drda package in java/engine as well as in java/drda.

        The suggested javadoc comments seem valid to me.
        The host property is a bit tricky as always (probably because it should be called derby.drda.connectionInterface or some such instead). The suggested "0.0.0.0" description change is fine, although the first sentence of the javadoc should be something like

        "Gets the name of the network interface on which the network server is listening"

        instead of

        "Gets the host name for the network server"

        Show
        John H. Embretsen added a comment - Thanks for the commit. Seems like you forgot to actually move the MBean interface to java/drda - now I see the org.apache.derby.mbeans.drda package in java/engine as well as in java/drda. The suggested javadoc comments seem valid to me. The host property is a bit tricky as always (probably because it should be called derby.drda.connectionInterface or some such instead). The suggested "0.0.0.0" description change is fine, although the first sentence of the javadoc should be something like "Gets the name of the network interface on which the network server is listening" instead of "Gets the host name for the network server"
        Hide
        Daniel John Debrunner added a comment -

        Darn, I'll fix the up location of the mbeans.drda package, I think my ide got confused (or maybe I did).

        Show
        Daniel John Debrunner added a comment - Darn, I'll fix the up location of the mbeans.drda package, I think my ide got confused (or maybe I did).
        Hide
        Bernt M. Johnsen added a comment -

        I have started some work to enhance this bean with some dynamic data (like active sessions, waiting sessions, thread pool size etc.). It's only part time, so I'll have something ready next week.

        Show
        Bernt M. Johnsen added a comment - I have started some work to enhance this bean with some dynamic data (like active sessions, waiting sessions, thread pool size etc.). It's only part time, so I'll have something ready next week.
        Hide
        John H. Embretsen added a comment -

        Thanks for helping out adding some useful statistics to the MBean, Bernt! Feel free to reassign this issue if you don't plan on creating a separate one.

        I hope to fix the Javadoc issues (mentioned in previous comments) before the 10.4 release (unless someone else volunteers), but I'll be on vacation for about one week starting tomorrow, so I won't be able to do it just yet. I'll check the status of this issue when I get back.

        Show
        John H. Embretsen added a comment - Thanks for helping out adding some useful statistics to the MBean, Bernt! Feel free to reassign this issue if you don't plan on creating a separate one. I hope to fix the Javadoc issues (mentioned in previous comments) before the 10.4 release (unless someone else volunteers), but I'll be on vacation for about one week starting tomorrow, so I won't be able to do it just yet. I'll check the status of this issue when I get back.
        Hide
        Bernt M. Johnsen added a comment -

        Uploaded a patch that adds some live data to the network server MBean

        • Active sessions
        • Waiting sessions
        • No of connection threads
        • No of accepted connections
        • Bytes sent
        • Bytes received
        Show
        Bernt M. Johnsen added a comment - Uploaded a patch that adds some live data to the network server MBean Active sessions Waiting sessions No of connection threads No of accepted connections Bytes sent Bytes received
        Hide
        Bernt M. Johnsen added a comment -

        Added bytes sent per second and bytes received per second

        Show
        Bernt M. Johnsen added a comment - Added bytes sent per second and bytes received per second
        Hide
        Thomas Nielsen added a comment -

        v1 generally looks very nice!

        Copule of small nits though:

        • whitespace diff in java/drda/org/apache/derby/impl/drda/DDMWriter.java
        • no comments on any methods in java/drda/org/apache/derby/impl/drda/NetworkServerMBeanImpl.java. A "@see <interaceclass#method>" would be nice, although no veto on this.
        Show
        Thomas Nielsen added a comment - v1 generally looks very nice! Copule of small nits though: whitespace diff in java/drda/org/apache/derby/impl/drda/DDMWriter.java no comments on any methods in java/drda/org/apache/derby/impl/drda/NetworkServerMBeanImpl.java. A "@see <interaceclass#method>" would be nice, although no veto on this.
        Hide
        Bernt M. Johnsen added a comment -

        Fixed whitespace issues

        Show
        Bernt M. Johnsen added a comment - Fixed whitespace issues
        Hide
        Knut Anders Hatlen added a comment -

        Looks good. A couple of small comments:

        I think totalByteCount must be updated in DDMWriter.sendBytes() as well.

        The way getBytesReceivedPerSecond() and getBytesSentPerSecond() calculate the average is very vulnerable to loss of precision. If the time between two calls is 1999 ms, ((now - lastSentTime)/1000)) becomes 1999/1000 = 1. This means the returned value is twice as high as it should be. I think you can preserve maximum precision by rewriting it like this:

        sentResult = (int) ((count - lastSentBytes) * 1000 / (now - lastSentTime));

        Show
        Knut Anders Hatlen added a comment - Looks good. A couple of small comments: I think totalByteCount must be updated in DDMWriter.sendBytes() as well. The way getBytesReceivedPerSecond() and getBytesSentPerSecond() calculate the average is very vulnerable to loss of precision. If the time between two calls is 1999 ms, ((now - lastSentTime)/1000)) becomes 1999/1000 = 1. This means the returned value is twice as high as it should be. I think you can preserve maximum precision by rewriting it like this: sentResult = (int) ((count - lastSentBytes) * 1000 / (now - lastSentTime));
        Hide
        Daniel John Debrunner added a comment -

        Nice addition Bernt, can I suggest a few attribute name changes:

        ActiveSessions, WaitingSessions and ConnectionTheads all represent counts or number of of items but it's not clear from their names.
        One might imagine an MBean attribute that did return a information about the set of active sessions which would naturally be called ActiveSessions.

        How about

        ActiveSessionCount

        or

        NumberOfActiveSessions

        (etc.)

        I prefer the Count at the end, as then it's quicker when seeing the method name to determine what it is about, rather than having to mentally parse 'NumberOf'.

        --------------------------

        NumberOfConnections is as you say the number of accepted connections, but its name does not imply that. When just running the MBean I'd assumed it meant the number of current connections.

        (and of course if the attribute names are change the style should be consistent across the Mbean and all of derby's MBeans)

        Show
        Daniel John Debrunner added a comment - Nice addition Bernt, can I suggest a few attribute name changes: ActiveSessions, WaitingSessions and ConnectionTheads all represent counts or number of of items but it's not clear from their names. One might imagine an MBean attribute that did return a information about the set of active sessions which would naturally be called ActiveSessions. How about ActiveSessionCount or NumberOfActiveSessions (etc.) I prefer the Count at the end, as then it's quicker when seeing the method name to determine what it is about, rather than having to mentally parse 'NumberOf'. -------------------------- NumberOfConnections is as you say the number of accepted connections, but its name does not imply that. When just running the MBean I'd assumed it meant the number of current connections. (and of course if the attribute names are change the style should be consistent across the Mbean and all of derby's MBeans)
        Hide
        Daniel John Debrunner added a comment -

        One question though, from a user/management perspective, what's the difference between a session and a connection?

        Show
        Daniel John Debrunner added a comment - One question though, from a user/management perspective, what's the difference between a session and a connection?
        Hide
        Daniel John Debrunner added a comment -

        I think MBean's need to be thread safe, each jmx user can call methods on the same instance of the MBean, thus the methods that calculate the rates need to be thread safe, eg. getBytesReceivedPerSecond

        Show
        Daniel John Debrunner added a comment - I think MBean's need to be thread safe, each jmx user can call methods on the same instance of the MBean, thus the methods that calculate the rates need to be thread safe, eg. getBytesReceivedPerSecond
        Hide
        Bernt M. Johnsen added a comment -

        Dan & Knut: Thanks for the comments. I will fix the precision and threading issue with getBytesRecieved/sentPerSecond.
        I agree that adding "Count" or "NumberOf" to attributes adds to usability. Personally I prefer "NumberOf" since I associate "Count" with an monotonous increasing counter. Furthermore "Session" is an implementation detail and for all purposes it maps to an java.sql.Connection, so I think "Connection" is a better name.

        I suggest the following attributes:

        NumberOfActiveConnections
        NumberOfWaitingConnections
        SizeOfConnectionThreadPool
        ConnectionCounter

        Show
        Bernt M. Johnsen added a comment - Dan & Knut: Thanks for the comments. I will fix the precision and threading issue with getBytesRecieved/sentPerSecond. I agree that adding "Count" or "NumberOf" to attributes adds to usability. Personally I prefer "NumberOf" since I associate "Count" with an monotonous increasing counter. Furthermore "Session" is an implementation detail and for all purposes it maps to an java.sql.Connection, so I think "Connection" is a better name. I suggest the following attributes: NumberOfActiveConnections NumberOfWaitingConnections SizeOfConnectionThreadPool ConnectionCounter
        Hide
        Thomas Nielsen added a comment -

        Dan has a valid point in trying not to prefixing the names with "NumberOf".

        Why not simply use:
        ActiveConnections
        WaitingConnections
        ConnectionThreadPoolSize
        ConnectionCounter

        I agree that the last one should be "counter", as it refers to the accumulated number of connection and not the current number.

        Show
        Thomas Nielsen added a comment - Dan has a valid point in trying not to prefixing the names with "NumberOf". Why not simply use: ActiveConnections WaitingConnections ConnectionThreadPoolSize ConnectionCounter I agree that the last one should be "counter", as it refers to the accumulated number of connection and not the current number.
        Hide
        Bernt M. Johnsen added a comment -

        Fixed precision, threading issue and names. Chose Thomas' propsal for names.

        Show
        Bernt M. Johnsen added a comment - Fixed precision, threading issue and names. Chose Thomas' propsal for names.
        Hide
        Daniel John Debrunner added a comment -

        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

        Show
        Daniel John Debrunner added a comment - 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
        Hide
        Bernt M. Johnsen added a comment -

        Ok. So established practice would then be e.g.

        ActiveConnectionCount
        WaitingConnectionCount
        AccumulatedConnectionCount (I felt "total" might be interpreted as active+waiting, so I suggest "accumulated)

        "Active" means that it is not queued/waiting, and all connections will be active when derby.drda.maxThreads==0, if maxThreads>0 connections will be queued if the number of active connections reach this value. As long as derby.drda.timeSlice==0 the getConnection will return when the connection becomes active. If timeSlice > 0 (and the number of actual connections > msxThreads), the connections will alternate "active" and "waiting" according to the (somewhat primitive) timeslicing algortthm in the network server.

        Maybe
        ConnectionCount and
        WaitingConnectionCount?

        PS: Wrt ZIP, sorry about that. I have automated the patch generation in a script to avoid some netbeans quirks. Since it seems to be awkward for others, I'll stop using the script for small patches.

        Show
        Bernt M. Johnsen added a comment - Ok. So established practice would then be e.g. ActiveConnectionCount WaitingConnectionCount AccumulatedConnectionCount (I felt "total" might be interpreted as active+waiting, so I suggest "accumulated) "Active" means that it is not queued/waiting, and all connections will be active when derby.drda.maxThreads==0, if maxThreads>0 connections will be queued if the number of active connections reach this value. As long as derby.drda.timeSlice==0 the getConnection will return when the connection becomes active. If timeSlice > 0 (and the number of actual connections > msxThreads), the connections will alternate "active" and "waiting" according to the (somewhat primitive) timeslicing algortthm in the network server. Maybe ConnectionCount and WaitingConnectionCount? PS: Wrt ZIP, sorry about that. I have automated the patch generation in a script to avoid some netbeans quirks. Since it seems to be awkward for others, I'll stop using the script for small patches.
        Hide
        Daniel John Debrunner added a comment -

        If Active has a meaning (which according to the above it does) then it should be part of the name.
        There could be a third attribute ConnectionCount, & I think the relationship would be:

        ConnectionCount = ActiveConnectionCount + WaitingConnectionCount

        Right?

        Show
        Daniel John Debrunner added a comment - If Active has a meaning (which according to the above it does) then it should be part of the name. There could be a third attribute ConnectionCount, & I think the relationship would be: ConnectionCount = ActiveConnectionCount + WaitingConnectionCount Right?
        Hide
        Daniel John Debrunner added a comment -

        BTW - Since these attributes are part of the public api it would be good to expand their current javadoc entries with more information such as the explanation for active provided above.

        Show
        Daniel John Debrunner added a comment - BTW - Since these attributes are part of the public api it would be good to expand their current javadoc entries with more information such as the explanation for active provided above.
        Hide
        Bernt M. Johnsen added a comment -

        Atached patch which fixes the naming of attributes en NetworkServerMBean

        Show
        Bernt M. Johnsen added a comment - Atached patch which fixes the naming of attributes en NetworkServerMBean
        Hide
        John H. Embretsen added a comment -

        Attaching patch d3435_NetworkServerMBeanTest_v01.diff which implements a new test class for the NetworkServerMBean and adds it to the management test suite:

        M java/testing/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java
        A java/testing/org/apache/derbyTesting/functionTests/tests/management/NetworkServerMBeanTest.java
        M java/testing/org/apache/derbyTesting/functionTests/tests/management/_Suite.java

        All attributes are tested, although testing of the actual attribute values could be improved (see code comments). Attribute names and return types are always tested.

        I ran into some issues when testing the ping() operation, so I ended up including it as a test case, but the operation will only be invoked when running with classes (not when running with jars). This is due to security manager issues, and is explained in code comments. I hope this can be fixed at some later point in time.

        Please review - it would be great to get this in before a new branch is cut.

        Show
        John H. Embretsen added a comment - Attaching patch d3435_NetworkServerMBeanTest_v01.diff which implements a new test class for the NetworkServerMBean and adds it to the management test suite: M java/testing/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java A java/testing/org/apache/derbyTesting/functionTests/tests/management/NetworkServerMBeanTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/management/_Suite.java All attributes are tested, although testing of the actual attribute values could be improved (see code comments). Attribute names and return types are always tested. I ran into some issues when testing the ping() operation, so I ended up including it as a test case, but the operation will only be invoked when running with classes (not when running with jars). This is due to security manager issues, and is explained in code comments. I hope this can be fixed at some later point in time. Please review - it would be great to get this in before a new branch is cut.
        Hide
        Daniel John Debrunner added a comment -

        NetworkServerMBean test patch applied: Revision: 635115

        Show
        Daniel John Debrunner added a comment - NetworkServerMBean test patch applied: Revision: 635115
        Hide
        John H. Embretsen added a comment -

        Attaching a patch d3435_javadocUpdates.diff improving the Javadoc comments of the NetworkServerMBean, and adds a package overview to the org.apache.derby.mbeans.drda package.

        Details regarding JMX/NetworkServer security (SystemPermissions etc.) should be added to the package description later. Since I was not sure of all the details, I chose to leave it out for now.

        M java/drda/org/apache/derby/mbeans/drda/NetworkServerMBean.java
        A java/drda/org/apache/derby/mbeans/drda/package.html

        Please review...

        Show
        John H. Embretsen added a comment - Attaching a patch d3435_javadocUpdates.diff improving the Javadoc comments of the NetworkServerMBean, and adds a package overview to the org.apache.derby.mbeans.drda package. Details regarding JMX/NetworkServer security (SystemPermissions etc.) should be added to the package description later. Since I was not sure of all the details, I chose to leave it out for now. M java/drda/org/apache/derby/mbeans/drda/NetworkServerMBean.java A java/drda/org/apache/derby/mbeans/drda/package.html Please review...
        Hide
        John H. Embretsen added a comment -

        Forgot to set the patch available flag for the patch d3435_javadocUpdates.diff. Patch applies to both trunk and 10.4, so I am hoping for review and (double) commit. The patch addresses previous comments to this issue and touches Javadocs only.

        Show
        John H. Embretsen added a comment - Forgot to set the patch available flag for the patch d3435_javadocUpdates.diff. Patch applies to both trunk and 10.4, so I am hoping for review and (double) commit. The patch addresses previous comments to this issue and touches Javadocs only.
        Hide
        Bernt M. Johnsen added a comment -

        Committed revision 641762 on trunk

        Show
        Bernt M. Johnsen added a comment - Committed revision 641762 on trunk
        Hide
        Bernt M. Johnsen added a comment -

        Committed revision 641765 on 10.4 branch

        Show
        Bernt M. Johnsen added a comment - Committed revision 641765 on 10.4 branch
        Hide
        John H. Embretsen added a comment -

        Thanks for committing, Bernt!
        I intend to close this issue within the end of this week unless I hear objections. Additional improvements or fixes should be tracked by new Jira issues.

        Show
        John H. Embretsen added a comment - Thanks for committing, Bernt! I intend to close this issue within the end of this week unless I hear objections. Additional improvements or fixes should be tracked by new Jira issues.
        Hide
        John H. Embretsen added a comment -

        MBean and tests in place in trunk and 10.4 branch. Closing this issue.

        Show
        John H. Embretsen added a comment - MBean and tests in place in trunk and 10.4 branch. Closing this issue.

          People

          • Assignee:
            John H. Embretsen
            Reporter:
            John H. Embretsen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development