Hi Vladimir, I think that var 3. is OK. Currently `clusterStates` javadocs declares `IgniteCheckedException` but actually throws `IgniteException`. So this is a bug in any case, so I think we can just replace it with JMException.
I'd like to propose to use the same approach for other JMX methods too: `undeployTaskFromGrid`, `executeTask`, `pingNodeByAddress`. I think it's safe to use only String messages instead of full IgniteException as the cause. Don't think that JMX bean should return full stack trace of Ignite cluster exception. On Thu, Feb 3, 2022 at 9:54 PM Vladimir Steshin <vlads...@gmail.com> wrote: > Hi, Igniters. > > We've found that invocation results from some MX beans might not be > properly represented on clients like jconsole [1]. In the exception > cases. We pass Ignite exceptions or JMException with Ignite exception > causes to the client. And the client fails to unmarshal unknown > exceptions instead of showing failure reason. > > Examples: > > * /IgniteMXBean.clusterState()/ can throw /IgniteException/ > * /IgniteMXBean.executeTask()/ can throw /JMException/ holding > /IgniteException/ > * /IgniteClusterMXBean.tag()/ can throw /JMException/ holding > /IgniteException/ > > > Solutions might be: > > 1. For existing /JMExceptions/ let's keep only the error message and > hold no cause which can't be deserialized. > 2. #1 + Let's throw just /RuntimeException/ with the error message > instead of /IgniteException/ (for example in > /IgniteMXBean.clusterState()/). > 3. #1 + Let's use and declare similar /'throws JMException'/ at methods > like /IgniteMXBean.clusterState()/. But the user code that uses > mx-bean public API might not be compiled with this change. > 4. Deprecate these exception-throwing methods and bring new ones > returning string-result like "OK" or "failed: cause". But > /IgniteMXBean/ has already had several change-cluster-state methods > including deprecated. > > > My suggestion is #3. WDYT? > > > [1] https://issues.apache.org/jira/browse/IGNITE-16416 > >
