[wildfly-dev] Proposal to improve resource description and registration

Mon Apr 25 12:46:28 EDT 2016

There was already discussion to change PeristentResourceDefinition and
others to behave the way you describe.
One part of that was related to https://issues.jboss.org/browse/WFCORE-831
as Brian pointed out already.
The other part was potential breaking / change in APIs and was the reason
why it was postponed to after EAP7.

In short, lets do this.

--
tomaz

On Mon, Apr 25, 2016 at 5:46 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> I think it's the right direction. It will just take some care to not
> break stuff by not registering stuff that really should be registered.
>
> Good news is I had the same concern about
> https://issues.jboss.org/browse/WFCORE-831 but it seems there wasn't
> much of a problem.
>
> Twists to think about in this:
>
> 1) The "runtime-only but ok on the DC" case I mentioned, but I think
> that's solvable with more metadata, and we don't support it now so you
> won't break anything.
>
> 2) Subsystems running on the HC. I don't have any good reason why these
> would be an issue; I'm just pointing them out as something to remember
> as pretty much no one but Kabir has dealt with them. The
> context.isRuntimeOnlyRegistrationValid() provides the correct response
> for those.
>
> 3) Definitions of runtime-only child resources. This one is a bit more
> tricky. To be consistent they should be handled similarly to how you
> propose dealing with metrics. But they are different -- the code that
> registers the runtime-only ResourceDef may then go on and try to use the
> returned MRR, or may even come back later and look it up. But really the
> MRR shouldn't end up in the tree at all.
>
> Good news about 3) is code that is doing what I describe is probably
> already guarding that work with
> context.isRuntimeOnlyRegistrationValid(). So changing something probably
> won't break that code.
>
> 4) API change. Doing this is going to introduce management API changes,
> by removing stuff that should have never been there. So we need to
> account for that (probably bump API versions, check for console breakage.)
>
>
> BTW, the datasource subsystem thing is a bit of a different beast. The
> actual list of metrics is not known until runtime, because they vary
> based on the driver. That's why the registration is done that way.
>
> - Brian
>
> On 4/25/16 10:15 AM, Jeff Mesnil wrote:
> > 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
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160425/08626f95/attachment-0001.html 