[ 
https://issues.apache.org/jira/browse/IGNITE-16416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515334#comment-17515334
 ] 

Amelchev Nikita commented on IGNITE-16416:
------------------------------------------

Cherry-picked to the 2.13.

> 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
>             Fix For: 2.13
>
>         Attachments: Scr_Bad.png, Scr_Good.png
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> Several MX bean methods throw _IgniteException / JMException_. Such 
> exceptions or their causes cannot be deserialized on the client-side without 
> 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 examples:
> {code:java}
> IgniteMXBean.clusterState(...)
> IgniteMXBean.executeTask(...)
> IgniteClusterMXBean.tag(...)
> {code}
> The simplest solution could be just throwing RuntimeException with the error 
> message (example on the picture "Good"). 
> 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)

Reply via email to