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