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

Investigate ability to run multiple Derby systems in same JVM with different sets of MBeans.

    Details

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

      Description

      One of the reasons for JMX was to move away from system properties (specifically derby.system.home) to allow multiple Derby systems running within the same virtual machine. It would be good to get some unique naming/attribute scheme in the ObjectNames up front rather than only have it in some later version.

      1. d3466_mbean_system_id.txt
        11 kB
        Daniel John Debrunner

        Activity

        Hide
        Daniel John Debrunner added a comment -

        A simple initial scheme could be to have a system attribute for each MBean registered by Derby. The JMXManagamentService could automatically add this to the ObjectName when MBeans are registered with it. Initially a newly created UUID could be used as the system identifier. I have some code that does this, I'll submit a patch soon.

        Future options could allow the application to provide a system identifier in derby.properties.

        Show
        Daniel John Debrunner added a comment - A simple initial scheme could be to have a system attribute for each MBean registered by Derby. The JMXManagamentService could automatically add this to the ObjectName when MBeans are registered with it. Initially a newly created UUID could be used as the system identifier. I have some code that does this, I'll submit a patch soon. Future options could allow the application to provide a system identifier in derby.properties.
        Hide
        Daniel John Debrunner added a comment -

        Patch that adds a runtime system identifier to the ObjectName Derby uses to register MBeans in the form of the key property system.

        ManagementMBean gains a getSystemIdentifier method which allows the application registered MBean to obtain the system identifier for the system it is monitoring.

        The tests are enhanced to have a utility method that returns a valid ObjectName for the system under test given a set of key properties.

        javadoc expanded to explain the system identifier.

        Show
        Daniel John Debrunner added a comment - Patch that adds a runtime system identifier to the ObjectName Derby uses to register MBeans in the form of the key property system. ManagementMBean gains a getSystemIdentifier method which allows the application registered MBean to obtain the system identifier for the system it is monitoring. The tests are enhanced to have a utility method that returns a valid ObjectName for the system under test given a set of key properties. javadoc expanded to explain the system identifier.
        Hide
        John H. Embretsen added a comment -

        My first impression was that the 128-bit identifier kind of clutters the MBean view in JConsole (et. al.), and seems to provide little value as of yet. I'm afraid users will ask themselves what the purpose of this number is. However, I agree it can be useful if a solution for DERBY-1228 is provided*, and that adding such mandatory key properties to all object names later might be more problematic than doing it now.

        Making it possible to set a custom identifier (e.g. "myDerbySystem2" instead of a default such as "c013800d-0118-8425-3abf-fffff03de2d0") as a property or something would provide users with an option to reduce the "clutter" somewhat, so I'm all for that.

        *)
        So the system identifiers that are now part of all of Derby MBeans' ObjectNames are there in case DERBY-1228 ("Make it possible to run multiple instances of Derby within the same VM") is resolved? Or is it possible to run multiple Derby systems in the same JVM today?

        Show
        John H. Embretsen added a comment - My first impression was that the 128-bit identifier kind of clutters the MBean view in JConsole (et. al.), and seems to provide little value as of yet. I'm afraid users will ask themselves what the purpose of this number is. However, I agree it can be useful if a solution for DERBY-1228 is provided*, and that adding such mandatory key properties to all object names later might be more problematic than doing it now. Making it possible to set a custom identifier (e.g. "myDerbySystem2" instead of a default such as "c013800d-0118-8425-3abf-fffff03de2d0") as a property or something would provide users with an option to reduce the "clutter" somewhat, so I'm all for that. *) So the system identifiers that are now part of all of Derby MBeans' ObjectNames are there in case DERBY-1228 ("Make it possible to run multiple instances of Derby within the same VM") is resolved? Or is it possible to run multiple Derby systems in the same JVM today?
        Hide
        Daniel John Debrunner added a comment -

        > So the system identifiers that are now part of all of Derby MBeans' ObjectNames are there in case DERBY-1228 ("Make it possible to run multiple instances of Derby within the same VM") is resolved? Or is it possible to run multiple Derby systems in the same JVM today?

        It's possible to run multiple Derby systems today in the same virtual machine using different classloaders. The upgrade test does it.

        The key point about DERBY-1228 is running in the same virtual machine with a different configuration, namely derby.system.home, not really the multiple classloader bit.

        Show
        Daniel John Debrunner added a comment - > So the system identifiers that are now part of all of Derby MBeans' ObjectNames are there in case DERBY-1228 ("Make it possible to run multiple instances of Derby within the same VM") is resolved? Or is it possible to run multiple Derby systems in the same JVM today? It's possible to run multiple Derby systems today in the same virtual machine using different classloaders. The upgrade test does it. The key point about DERBY-1228 is running in the same virtual machine with a different configuration, namely derby.system.home, not really the multiple classloader bit.
        Hide
        Daniel John Debrunner added a comment -

        > My first impression was that the 128-bit identifier kind of clutters the MBean view in JConsole (et. al.),

        We shouldn't lose sight of the fact that Derby's MBeans are there to provide a management and monitoring api for Derby through a standard mechanism (JMX).

        Jconsole is just one way of providing a GUI to manipulate these MBeans and is just a general purpose tool, so we shouldn't get too caught up on how they appear in it.

        Applications that using Derby are unlikely to show direct representations of the MBeans, instead just making calls to their api attributes and operations. Those applications do need a way of ensuring they are calling the MBean for the correct Derby system, that's really what the system identifier is for, especially in the future when it may be more typical to support multiple derby instances in a jvm, with the possibility of some of those being "old 10.4" versions.

        Show
        Daniel John Debrunner added a comment - > My first impression was that the 128-bit identifier kind of clutters the MBean view in JConsole (et. al.), We shouldn't lose sight of the fact that Derby's MBeans are there to provide a management and monitoring api for Derby through a standard mechanism (JMX). Jconsole is just one way of providing a GUI to manipulate these MBeans and is just a general purpose tool, so we shouldn't get too caught up on how they appear in it. Applications that using Derby are unlikely to show direct representations of the MBeans, instead just making calls to their api attributes and operations. Those applications do need a way of ensuring they are calling the MBean for the correct Derby system, that's really what the system identifier is for, especially in the future when it may be more typical to support multiple derby instances in a jvm, with the possibility of some of those being "old 10.4" versions.
        Hide
        Daniel John Debrunner added a comment -

        Simple newly created UUID scheme added as system identifier in the ObjectName for each MBean registered by Derby.
        Further improvements can be separate issues.

        Show
        Daniel John Debrunner added a comment - Simple newly created UUID scheme added as system identifier in the ObjectName for each MBean registered by Derby. Further improvements can be separate issues.
        Hide
        John H. Embretsen added a comment -

        I agree we should not put too much effort into how the presentation of Derby's MBeans will look in generic tools without an additional abstraction layer, although I'm sure a large portion of Derby's JMX users will access the beans directly this way, at least to begin with.

        One more question:
        Other than by accessing Derby's MBeans, how can a user determine the value of the system identifier? Is it being exposed by some other public API as well?

        Show
        John H. Embretsen added a comment - I agree we should not put too much effort into how the presentation of Derby's MBeans will look in generic tools without an additional abstraction layer, although I'm sure a large portion of Derby's JMX users will access the beans directly this way, at least to begin with. One more question: Other than by accessing Derby's MBeans, how can a user determine the value of the system identifier? Is it being exposed by some other public API as well?
        Hide
        Daniel John Debrunner added a comment -

        Currently the system identifier is only exposed through the ManagementMBean (see o.a.d.mbeans.package..html for info)

        Show
        Daniel John Debrunner added a comment - Currently the system identifier is only exposed through the ManagementMBean (see o.a.d.mbeans.package..html for info)

          People

          • Assignee:
            Unassigned
            Reporter:
            Daniel John Debrunner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development