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

[Bela Ban (Jira)]

     [ https://issues.jboss.org/browse/JGRP-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2337:
---------------------------
    Description: 
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.

  was:
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.



> 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
>
>
> 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)