[
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(String)
{code}
The simplest solution could be just throwing RuntimeException with the error
message.
This ticked suggests another approach:
Let's wrap IgniteException/IgniteCheckedException into JMException so that
JMException keeps only the error message and holds no non-deserializable cause.
But would slightly change the API: several mxbean methods like
`IgniteMXBean.clusterState(*)` gets `throws JMException`. User code might not
be conpiled. 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 pach preparation. The error could look like:
{code:java}
{code}
See 'bad' picture. Same refuse on the deactivation, bad the error is
unreadable.
See 'good' picture. Some readable result.
Solution: let's convert the exception to a 'java-core' one.
> 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(String)
> {code}
> The simplest solution could be just throwing RuntimeException with the error
> message.
> This ticked suggests another approach:
> Let's wrap IgniteException/IgniteCheckedException into JMException so that
> JMException keeps only the error message and holds no non-deserializable
> cause. But would slightly change the API: several mxbean methods like
> `IgniteMXBean.clusterState(*)` gets `throws JMException`. User code might not
> be conpiled. But why using mx bean API?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
