[jboss-jira] [JBoss JIRA] (JGRP-2337) DiagnosticsHandler without reflection

Bela Ban (Jira) issues at jboss.org
Fri Apr 12 05:09:00 EDT 2019


    [ https://issues.jboss.org/browse/JGRP-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13721579#comment-13721579 ] 

Bela Ban commented on JGRP-2337:
--------------------------------

We may only need 2 additional ProbeHandlers, which are initialized and registered with TP (overwriting previously registered ProbeHandlers) for "jmx" and "op".
If these are initialized in a static initializer, then reflection _can_ be used. For "jmx", the initailization could for example grab all fields of a class annotated with {{@Property}} or {{@ManagedAttribute}} / {{@ManagedOperation}} and generate a {{Supplier<Object>}} lambda and add them to a hashmap.
At run time, the name of the attribute would be looked up and the associated lambda would get invoked.
A simple test is attached (bla.java).

> DiagnosticsHandler without reflection
> -------------------------------------
>
>                 Key: JGRP-2337
>                 URL: https://issues.jboss.org/browse/JGRP-2337
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Major
>             Fix For: 4.1.0
>
>         Attachments: bla.java
>
>
> Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
> However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
> Investigate creating a {{ProbeHandler}} for {{"jmx"}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
> * Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
> * Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)


More information about the jboss-jira mailing list