5:15 p.m.
TL;DR - I propose to simplify subsystem development by moving some of the validation logic
from the resource definitions to the management resource registration. The goal is to
provide a static representation of the resources and let the MMR dynamically pick the
“meaningful” parts.
Last week an user complains that the messaging-activemq subsystem’s statistics were not
updated in domain mode.
It turned out that he was reading the metrics on the DC
(/profile=full/subsytem=messaging-activemq/…) instead of reading on the server
(/host=master/server=server-one/subsystem=messaging-activemq/…)
It is a bug[1] in the messaging-activemq because its resources register their metrics
without checking whether that makes sense. The correct check is to look at
context.isRuntimeOnlyRegistrationValid() to check whether a resource can register its
metrics (the same check applies also for runtime attributes/operations).
I looked at other subsystems and undertow has the same issue.
This check does not work well with the PersistentResourceDefinition that is used
throughout the messaging-activemq and undertow subsystems. This API works best when the
definition of the resources uses a bunch of static instances for the resource itself, its
attributes, metrics, etc. These static instances are also used by the companion
PersistentResourceXMLDescription to provide a static XML representation of the subsystem.
If I have to pass this context.isRuntimeOnlyRegistrationValid() boolean to every resources
in the subsystem, I get rid of the static representations used by the
PersistentResourceDefinition and PersistentResourceXMLDescription and I have to add a lot
of simple but boilerplate code in all my resource definitions.
The datasources subsystem does not exhibit this issue. It works around it by installing a
Service at RUNTIME step to register (resp. unregister) statistics resource definitions
when the service is started (res. stopped). Since services are only installed when runtime
is supported, it ensures that the datasources metrics are available only on server and not
on the DC.
It looks correct but I’m not a big fan of this solution. It makes the subsystem definition
more complex to understand and it also involves boilerplate code that every subsystem
providing runtime should write.
I was wondering if we could simplify the development of the subsystems by moving some of
the logic dealing with that use case in the ManagementResourceRegistration instead.
My proposal would be to have the resource definitions be “complete”. The resource always
defines its attributes/metrics/operations.
When the MMR takes this definition and registers the different parts, it would only
register the “meaningful” one depending on the ProcessType and RunningMode. E.g. the MRR
of the DC or a admin-only server would not register metrics & runtime
attributes/operations while the MMR on a normal server would register everything.
This increase the complexity of the MMR which has to figure out whether to actually
register something or discard it but it makes writing subsystem simpler and more robust.
Brian told me there might some exceptions (e.g. a runtime op that could be invoked on the
DC) but these case could be handled by adding metadata to the resource definitions.
This approach segues quite well with the idea to generate subsystem using annotations. All
the subsystem developers has to do is describe extensively the subsystem resources (using
static objects now, annotations in a future version) and let the MMR decides which parts
of the resources are actually registered.
To sum up, the definition of a resource is static, while its registration is dynamic.
Do you see any issue with that proposal?
As a first step, I’ll start by creating the corresponding WFCORE issue to fix WFLY-6546
issue by ensuring the MMR does not register metric if the runtime registration is not
valid. This should not have any API impact (but the behaviour will certainly change).
jeff
[1] https://issues.jboss.org/browse/WFLY-6546
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/