[ https://issues.apache.org/jira/browse/IGNITE-16416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vladimir Steshin updated IGNITE-16416: -------------------------------------- Description: Several MX bean methods throw IgniteException / JMException. Such exceptions or their causes cannot be deserialized on the client-side with class transfer or class path preparation. The error could look like: {code:java} java.rmi.UnmarshalException / java.lang.ClassNofFoundException {code} instead of the desired exception. See the pictures attached. They represent results on jconsole. The method examles: {code:java} IgniteMXBean.clusterState(...) IgniteMXBean.executeTask(...) IgniteClusterMXBean.tag(...) {code} The simplest solution could be just throwing RuntimeException with the error message (example on the pictures). Or we could deprecate exception-throwing deactivation methods and bring new ones returning a string like "Cluster deactivated." / "Cluster activated." or "Failed. Cause: ...". But IgniteClusterMXBean already has several deprecated cluster-state methods. +This ticket suggests another approach:+ Let's fix existing wrapping with JMException so that it keeps only the error message without non-deserializable causes. Let's wrap _IgniteException/IgniteCheckedException_ into such _JMException_ in other places. This would slightly change the API: several mx-bean methods like _IgniteMXBean.clusterState(...)_ will obtain _throws JMException_. User code might not be compiled. But why using mx bean API? was: Several MX bean methods throw IgniteException / JMException. Such exceptions or their causes cannot be deserialized on the client-side with class transfer or class path preparation. The error could look like: {code:java} java.rmi.UnmarshalException / java.lang.ClassNofFoundException {code} instead of the desired exception. See the pictures attached. They represent results on jconsole. The method examles: {code:java} IgniteMXBean.clusterState(...) IgniteMXBean.executeTask(...) IgniteClusterMXBean.tag(...) {code} The simplest solution could be just throwing RuntimeException with the error message. Or we could deprecate exception-throwing deactivation methods and bring new ones returning a string like "Cluster deactivated." / "Cluster activated." or "Failed. Cause: ...". But IgniteClusterMXBean already has several deprecated cluster-state methods. This ticked suggests another approach: Let's fix existing wrapping with JMException so that it keeps only the error message without non-deserializable causes. Let's wrap _IgniteException/IgniteCheckedException_ into such _JMException_ in other places. This would slightly change the API: several mx-bean methods like _IgniteMXBean.clusterState(...)_ will obtain _throws JMException_. User code might not be compiled. But why using mx bean API? > Unreadable result on cluster deactivation via IgniteMXBean > ---------------------------------------------------------- > > Key: IGNITE-16416 > URL: https://issues.apache.org/jira/browse/IGNITE-16416 > Project: Ignite > Issue Type: Bug > Affects Versions: 2.12 > Reporter: Vladimir Steshin > Assignee: Vladimir Steshin > Priority: Minor > Attachments: Scr_Bad.png, Scr_Good.png > > Time Spent: 20m > Remaining Estimate: 0h > > Several MX bean methods throw IgniteException / JMException. Such exceptions > or their causes cannot be deserialized on the client-side with class transfer > or class path preparation. The error could look like: > {code:java} > java.rmi.UnmarshalException / java.lang.ClassNofFoundException > {code} > instead of the desired exception. See the pictures attached. They represent > results on jconsole. > The method examles: > {code:java} > IgniteMXBean.clusterState(...) > IgniteMXBean.executeTask(...) > IgniteClusterMXBean.tag(...) > {code} > The simplest solution could be just throwing RuntimeException with the error > message (example on the pictures). > Or we could deprecate exception-throwing deactivation methods and bring new > ones returning a string like "Cluster deactivated." / "Cluster activated." or > "Failed. Cause: ...". But IgniteClusterMXBean already has several deprecated > cluster-state methods. > +This ticket suggests another approach:+ > Let's fix existing wrapping with JMException so that it keeps only the error > message without non-deserializable causes. Let's wrap > _IgniteException/IgniteCheckedException_ into such _JMException_ in other > places. This would slightly change the API: several mx-bean methods like > _IgniteMXBean.clusterState(...)_ will obtain _throws JMException_. User code > might not be compiled. But why using mx bean API? -- This message was sent by Atlassian Jira (v8.20.1#820001)