[ https://issues.apache.org/jira/browse/CASSANDRA-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539006#comment-17539006 ]
David Capwell commented on CASSANDRA-17580: ------------------------------------------- have a solution for java launching, and tested with {code} JVM_OPTS='-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.rmi.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=127.0.0.1' ./bin/cassandra -f {code} see that it worked fine > Clients using JMX are unable to handle non-standard java types but we leak > this into our Exceptions > --------------------------------------------------------------------------------------------------- > > Key: CASSANDRA-17580 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17580 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Observability, Observability/JMX > Reporter: David Capwell > Assignee: David Capwell > Priority: Normal > Fix For: 4.1-beta, 4.1.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > This is an extension of CASSANDRA-17527. > When we throw in JMX the exception gets serialized and sent over the wire, > and if the client doesn’t have the same class path it fails and the exception > is lost and replaced with a ClassNotFoundException. This is bad as the user > has no idea what the issue is so unable to resolve it. -- This message was sent by Atlassian Jira (v8.20.7#820007) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org