Bug 366235

Comment 1 Glyn Normington 2011-12-15 09:06:56 EST

Some design notes.

According to the JMX Management Model chapter of the OSGi Enterprise
Spec v4.2, there is a single ConfigurationAdminMBean which surfaces
config admin to JMX. This is published with object name
"osgi.compendium:service=cm,version=1.3" and contains operations on
specific PIDs.

So we need to decide how to support multiple instances of Config
Admin, for example when we run multiple instances of Config Admin
in distinct regions in Virgo. The same question also applies to
other services such as Permission Admin, the Provisioning Service,
and User Admin.

ConfigurationAdminMBean Identity
--------------------------------

The ConfigurationAdminMBean assumes that a PID uniquely identifies
a configuration which is not necessarily the case across multiple
instances of Config Admin. Furthermore, only one mbean may be
registered to a given mbean server with a specific object name.

The following alternatives cope with multiple instances of Config
Admin:

1. Use a single ConfigurationAdminMBean intance and change the
   interface.

   This is not acceptable for the normal use case of a single
   instance of Config Admin running alongside a single instance
   of Gemini Management in an OSGi framework with only one default
   region.

2. Build the region identifier, or some abstraction of that, into
   the object name and publish a distinct ConfigurationAdminMBean
   per instance of Config Admin.

   We need to determine how to make this consistent with the
   default behaviour which would not have a region identifier in
   the object name.

   This is the preferred alternative.

3. Run a mbean server per Config Admin instance and publish a
   distinct ConfigurationAdminMBean per instance of Config Admin
   into distinct mbean servers.

   This would complicate JMX client access considerably as well
   as increasing the overhead per region in the JVM.

Accessing Multiple Config Admin Instances
-----------------------------------------

Given that we need to manage multiple instances of Config Admin
from Gemini Management, the basic decision is how many instances
of Gemini Management to run. There are two alternatives:

A. Single Gemini Management Instance

   The single instance will be able to load at most one instance
   of the Config Admin types (otherwise there would be an
   inconsistent class space which is prevented by the JVM). So it
   would be necessary to make a cross-class space call to access
   Config Admin instances in incompatible class spaces. This
   would naturally be performed using reflection. Either there
   need to be specific reflective logic for Config Admin, and other
   such services, or we would need to use some general purpose
   cross-class space proxying mechanism, which is similar in
   essence to a remoting mechanism such as distributed OSGi.

   Specific reflective logic per service does not seem to be a
   scalable solution as a new set of logic would need to be
   provided for each service that is to be supported.

   Using some remoting mechanism such as distributed OSGi seems
   too high level for what appears to be a basic server management
   feature. The underlying remoting mechanism would be unmanageable
   from a JMX perspective unless some means was found for allowing
   the remoting mechanism to apply to itself, which sounds rather
   complex and error-prone.

B. Instance of Gemini Management per Config Admin instance

   Running multiple instances of Gemini Management avoids the
   cross-class space issue, but necessitates some coordination
   across Gemini Management instances so that their mbeans would
   not clash (i.e., have the same object name).

   So it would be necessary to configure each instance of Gemini
   Management to publish appropriate mbeans.

   A concern was raised that an instance of Gemini Management
   would be able to "see" some of the content of other regions.
   This is a downside, but would also apply in alternative A.
   Essentially, Gemini Management will need to cope with being
   able to see bundles and other artefacts which it could not
   find, e.g., by listing all bundles (which is subject to
   region filtering).

   This is the preferred alternative.

Solution
--------

The solution combines options 2 and B above. Each instance of
Gemini Management will be configured into a non-standard mode of
publishing its mbeans with the region identifier built into the
object names.

Gemini Management should provide a configuration mechanism to
allow it to be configured with an object name translator. The
default behaviour is to publish the standard object names.
If an object name translator is present, Gemini Management will
use it to translate each object name before registering each mbean
and will register the mbean with the translated object name.

A region-aware object name translator will simply append the
region name to the object name.

In the root region of Virgo, we have the option of running
without an object name translator for consistency with the
standard or with the region-aware object name translator for
consistency with the other regions. The latter seems preferable
from the perpsective of management clients such as the web admin
console as it will provide a more uniform perspective of the
various regions in the system.

Various mechanisms could be used to configure an object name
translator:

i.   Attach a fragment to Gemini Management and place a
     Gemini Management defined header in the fragment to
     name the object name translator class.

     This has the beauty of being relatively simple, avoiding
     visible externals in the Gemini Management bundle, and
     being strictly tied to the lifecycle of Gemini Management.

     This is the preferred solution.

ii.  Code an optional package import in Gemini Management
     and attempt to load the object name translator during
     activation of Gemini Management and react according to
     the presence or absence of the object name translator.

     This is similar to the fragment solution, but exposes
     a visible external in the optional import.

iii. Have Gemini Management look for an object name translator
     service during activation and react according to the
     presence or absence of an object name translator service.

     This would allow multiple object name translators to be
     provided. It would be complicated by the lifecyce of the
     object name translator being independent of that of
     Gemini Management.

Comment 2 Glyn Normington 2011-12-16 06:37:22 EST

I have prepared a contribution to implement this bug at https://github.com/glyn/Gemini-Management

The contribution consists of the following commits:

9e98b4069b3b636eeada4b59b7d6582ce4376806
a16cbc964250de290879fedc21d21808c0b57cfb
af1013f2c0b467dc17dcd655c7d86cf686c41581
7da7da265e843856331b5a4ab3340cca91f43bf7

The following commit merges the branch containing the contribution (366163-WiringState) into master:

dc2cb61a8332d86f6f3cf7bce220f9d986ad9c3a

I confirm that I wrote 100% of the code changes, I have the rights to contribute the code, and new Java files have suitable license headers.

Comment 3 Lazar Kirchev 2011-12-20 03:57:54 EST

Changes submitted to master.

Comment 4 Chris Frost 2012-01-11 11:15:10 EST

Fixed with patch from Glyn