Relating configuration and monitoring

[ccrouch]

I want to use this thread to begin discussion of the issues around how to associate configurable properties with monitorable properties (also I think referred to as runtime properties in previous discussions) e.g. the number of connections from a pool which are currently in use.

Right now we have the concept of a ManagedComponent which supports being listed, updated, removed, created and its configurable properties queried. This component represents a user/administrator oriented feature of the app server, for example a Datasource. Its not unreasonable that such components could have monitorable attributes just as they have configurable properties, e.g. An administrator wants to know how many connections this datasource has open to the DB.

Given this, some questions arise:

1) If there is a separate object, (call it a MonitoredComponent just to differentiate it) to hold these monitorable attributes then what will be the association between this new object and a ManagedComponent . How will you be able to find the one from the other.
2) Which of the two concepts will be authoritative for determining what is actually deployed to the server? Should one ask for a list of ManagedComponents or a list of MonitoredComponents in order to know how many DataSource's are available? If there is always a one to one mapping then I guess it doesn't matter.
3) Where will these MonitoredComponents be obtained from? Registered in an mbeanserver? Retrieved from some monitoring equivalent of the ProfileService?

Before we start trying to answer these questions, lets see if they first make sense and if there are other more fundamental questions which need to be answered.

[starksm64]

I would just view this as a quality/annotation of the existing ManagedProperty notion.

A configuration type of property has:
- Realtime, RequriesRestart in terms when it can be applied
- The edit information, min, max, allowed values, ...

A statistic type of property has:
- type, expected range?

The management interface of a component should include both configuration and statistics type properties.

[ccrouch]

Ok, given this, would you expect the JSR77 implementation to be based off these ManagedComponent's and ManagedProperty's?

[starksm64]

Yes, but I"m not sure what else might need to be updated to support this yet. I believe the existing jmx notification based stuff should map over to an aspect that exposes a ManagedDeployment and its ManagedComponents as the jsr77 mbeans.

[adrian.brock]

A statistic type of property has:
- type, expected range?

Actually, I was thinking that the ManagedObject interface would have
a seperate part of statistics. This avoids the users having to "weed"
the managed properties when displaying what the user can change.
And vice versa when displaying what can be monitored.

[adrian.brock]

Yes, but I"m not sure what else might need to be updated to support this yet. I believe the existing jmx notification based stuff should map over to an aspect that exposes a ManagedDeployment and its ManagedComponents as the jsr77 mbeans.

I think we should really be doing this on the ManagedObjects?

We already have a type, so once we have the notion of scope in the ManagedObjects
it should be relatively trivial to map them to the jsr77 tree/naming convention?

I think the only issue is whether we enforce that the POJOs/MBeans should implement
the jsr77 classes, e.g. the statistics classes or whether we do some adaption in the jsr77 facade?

I'd favour the latter simply because it allows the implementation to provide
custom extra statistics and seperate the invocation/pooling/caching stats
while still being able to map them to the standard classes for jsr77.

The downside is that it is going to require some knowledge (hard wiring)
of the real implementation in the jsr77 facade to make this work.

[starksm64]

I agree, that the management view from the deployer should be able to define the jsr77 view. We do need to be able to override this to bootstrap it and deal with the missing info and mismatches, as well as the jmx registration/naming conventions.