[jira] [Comment Edited] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1683#comment-1683
]
Edward Ribeiro edited comment on CASSANDRA-14173 at 1/22/18 7:37 AM:
-
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break
Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
*update:* I have uploaded a couple of patches following the pattern
cassandra-14173..patch that apply to a single branch or a range of
branches.
was (Author: eribeiro):
Yes [~mshuler], the first cut of this patch *requires* >= 1.8u161 :(
OTOH, I have put together another version (see attachment) that compiles on
both 152 and 161. *_But_* *_I still need to verify if it doesn't break
Cassandra_ _at runtime, though!_*
(heh, changing jdk back and forth messed up my IDE so it dragged me down)
AFAIK, 161 build has both the legacy and the new constructor (the one with
_ObjectInputFilter_), so it should work as intended, but I am not sure about
152 yet. _Please_, let me know what you think, thanks.
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.36-37.patch, cassandra-14173.38.patch,
> cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.38.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.36-37.patch, cassandra-14173.38.patch,
> cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.36-37.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.36-37.patch,
> cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333945#comment-16333945
]
Abdulfattah Safa commented on CASSANDRA-14173:
--
161 has the same issue. I had to downgrade to 152 to get it working again.
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.39-trunk.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.39-trunk.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: (was: cassandra-14173.2.patch)
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: cassandra-14173.2.patch
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.2.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14173) JDK 8u162 breaks JMX integration
[
https://issues.apache.org/jira/browse/CASSANDRA-14173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated CASSANDRA-14173:
---
Attachment: (was: cassandra-14173.2.patch)
> JDK 8u162 breaks JMX integration
>
>
> Key: CASSANDRA-14173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14173
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Priority: Critical
> Fix For: 3.11.2
>
> Attachments: cassandra-14173.2.patch, cassandra-14173.patch
>
>
> {\{org.apache.cassandra.utils.JMXServerUtils}} which is used to
> programatically configure the JMX server and RMI registry (CASSANDRA-2967,
> CASSANDRA-10091) depends on some JDK internal classes/interfaces. A change to
> one of these, introduced in Oracle JDK 1.8.0_162 is incompatible, which means
> we cannot build using that JDK version. Upgrading the JVM on a node running
> 3.6+ will result in Cassandra being unable to start.
> {noformat}
> ERROR [main] 2018-01-18 07:33:18,804 CassandraDaemon.java:706 - Exception
> encountered during startup
> java.lang.AbstractMethodError:
> org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
> ~[na:1.8.0_162]
> at
> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
> ~[na:1.8.0_162]
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:104)
> ~[apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:143)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:188)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:600)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:689)
> [apache-cassandra-3.11.2-SNAPSHOT.jar:3.11.2-SNAPSHOT]{noformat}
> This is also a problem for CASSANDRA-9608, as the internals are completely
> re-organised in JDK9, so a more stable solution that can be applied to both
> JDK8 & JDK9 is required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8460) Make it possible to move non-compacting sstables to slow/big storage in DTCS
[
https://issues.apache.org/jira/browse/CASSANDRA-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333894#comment-16333894
]
Lerh Chuan Low commented on CASSANDRA-8460:
---
Thinking about this further, looks like this will be (reasonably) complex.
The main issue is that by introducing an archival directory, we now have
multiple data directories, which is like a JBOD setup.
https://issues.apache.org/jira/browse/CASSANDRA-6696 (Partition SSTables by
token range) seeks to prevent resurrected tombstones - the scenario where you
can have resurrected tombstones is described here:
https://www.datastax.com/dev/blog/improving-jbod.
However, with an archiving directory, we can no longer guarantee that a single
token range (or vnode) will live in one directory (unless I'm missing
something. Archiving is based on SSTable age; it doesn't know anything about
tokens)
High levelly, the situation goes like this:
1. You have a SSD and a HDD.
2. Key x is written into the SSD.
3. After some time, x passes the archive days, and ends up in the HDD.
4. For some reason not quite clear, the user decides to write a tombstone for x
(They shouldn't for TWCS). So we now have tomb(x) in the SSD.
At this point, we must keep in mind that there are 3 separate
{{CompactionStrategy}} (CS) instances running in both the SSD and HDD, each
managing repaired, unrepaired and pending repair SSTables. So there are 3 in
the SSD and 3 in the HDD. These CS instances cannot see each other's
candidates; when considering candidates for compaction, they see only the
SSTables in their own directories.
5. It passes gc_grace_second and tomb(x) is compacted away. So now x is
resurrected. In an actual JBOD setup, this can't happen because a single token
range or vnode can only live in one directory. This can't be guaranteed with an
archiving setup.
We can solve this issue by introducing a new flag. This flag will make it so
that a tombstone is only dropped if it lives in the archiving directory.
Enforcing {{gc_grace > archive_days}} is not sufficient because the node can
always be taken offline or compactions disabled or similar.
Consider the case where:
6. The SSD is corrupted and needs to be replaced. In this case, the fix would
be to replace the entire node, not just the SSD. This is to prevent tombstone
resurrection but also that the system tables are gone (system tables live in
the SSD), so a full replace is needed.
This is the high level design we came up with:
* In typical TTL use case TTL should always be greater than archive days
* Introduce a new YAML setting; call it cold_data_directories possibly. This is
to signal that 'archive' doesn't mean we can just forget it there; compactions
still need to happen in that directory, for joining nodes, streaming nodes, and
keeping the disk usage low.
* An option on TWCS to specify to use cold directory after a certain amount of
days.
* Need a new flag to handle the situation described - cannot drop tombstones
unless it’s in the cold directory. This also has the implication that we can’t
drop data using tombstones on the non-archived data. Pretty much means we can’t
use manual deletions on the table and we should only use this when TTLing
everything, writing once, and we should turn off read repair.
* Need a separate compaction throughput and concurrent compactors setting for
the cold directory
Caveats with changes to flags/properties:
* Removing cold flag from the yaml means we've lost the data in those
directories.
* Removing cold flag from table only means data will no longer be archived to
cold. Existing SSTables in the cold directory should be loaded in; however if
compacted moved back to hot storage.
* Reducing the archive time on the table will just cause more data to be moved
to the cold directory.
* Increasing the archive time means existing data that should no longer be
archived could go back to the live set if compacted, however will stay in cold
data with no negative impact.
* When promoting data to cold directory need to check that there’s not an
overlapping SSTable with a max timestamp greater than minimum timestamp, same
as TWCS expiry.
There will still be significant I/O when it comes to
compacting/repairing/streaming the SSTables in the cold directory, and it adds
reasonable complexity to the code base. It's not trivial to reason about
either, it took 3 hours between me and my colleagues. The only leftover
question we had was when changing the table level property will Cassandra need
to be restarted to take effect? Or is there a hook/property checked constantly?
Anybody notice anything we missed or have any thoughts on it so far on the
feature itself and the value it adds for the complexity introduced (if you have
time)? Before we go ahead with it. Will be really appreciated! [~krummas]
[~bdeggleston] [~jjirsa] [~stone]
> Make it
[jira] [Commented] (CASSANDRA-14159) Fix flaky test_drop_with_stopped_build
[
https://issues.apache.org/jira/browse/CASSANDRA-14159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333746#comment-16333746
]
Paulo Motta commented on CASSANDRA-14159:
-
The tests {{drop_while_building}} and {{drop_with_stopped_build}} added by
CASSANDRA-12245 slows down the view build to ensure it's dropped/stopped while
building. After the view is re-created, the new view build may take longer than
the maximum allowed time of 50 seconds due to the byteman slowdown, causing the
test to fail.
The fix reduces the number of base table rows from 10k to 5k to allow the
second view build to complete on time and also waits for the view to start
building before stopping or dropping it to make it more deterministic.
Simple cassandra-dtest patch
[here|https://github.com/pauloricardomg/cassandra-dtest/commit/79822e7aa176c4611e0ba87d746e1f29a2ee3c1e].
CI looks good, would you mind taking a look [~adelapena] ?
> Fix flaky test_drop_with_stopped_build
> --
>
> Key: CASSANDRA-14159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14159
> Project: Cassandra
> Issue Type: Test
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Major
>
> Test is failing with
> {noformat}
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/tools/decorators.py", line 48, in
> wrapped
> f(obj)
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 1129, in test_drop_with_stopped_build
> self._wait_for_view('ks', 't_by_v')
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 130, in _wait_for_view
> {noformat}
> test_drop_while_building is also failing with a similar stack trace:
> {noformat}
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/tools/decorators.py", line 48, in
> wrapped
> f(obj)
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 1073, in test_drop_while_building
> self._wait_for_view('ks', 't_by_v')
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 130, in _wait_for_view
> raise RuntimeError("View {}.{} build not finished after 50
> seconds.".format(ks, view))
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14159) Fix flaky test_drop_with_stopped_build
[
https://issues.apache.org/jira/browse/CASSANDRA-14159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14159:
Status: Patch Available (was: Open)
> Fix flaky test_drop_with_stopped_build
> --
>
> Key: CASSANDRA-14159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14159
> Project: Cassandra
> Issue Type: Test
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Major
>
> Test is failing with
> {noformat}
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/tools/decorators.py", line 48, in
> wrapped
> f(obj)
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 1129, in test_drop_with_stopped_build
> self._wait_for_view('ks', 't_by_v')
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 130, in _wait_for_view
> {noformat}
> test_drop_while_building is also failing with a similar stack trace:
> {noformat}
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/tools/decorators.py", line 48, in
> wrapped
> f(obj)
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 1073, in test_drop_while_building
> self._wait_for_view('ks', 't_by_v')
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 130, in _wait_for_view
> raise RuntimeError("View {}.{} build not finished after 50
> seconds.".format(ks, view))
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14181) RPM package has too many executable files
Troels Arvin created CASSANDRA-14181: Summary: RPM package has too many executable files Key: CASSANDRA-14181 URL: https://issues.apache.org/jira/browse/CASSANDRA-14181 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Troels Arvin Attachments: cassandra-permissions-fix.patch When installing using the RPM files: In /etc/cassandra/conf, the files should not be execuable, as they are either * properties-like files * readme-like files, or * files to be sourced by shell scripts I'm adding a patch (cassandra-permissions-fix.patch) to the cassandra.spec file which fixes this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14180) cassandra.spec needs to require ant-junit
Troels Arvin created CASSANDRA-14180:
Summary: cassandra.spec needs to require ant-junit
Key: CASSANDRA-14180
URL: https://issues.apache.org/jira/browse/CASSANDRA-14180
Project: Cassandra
Issue Type: Bug
Components: Packaging
Reporter: Troels Arvin
I tried rebuilding cassandra-3.11.1-1.src.rpm on a Centos 7 host which had ant
installed, but not the "ant-junit" package; that failed with a somewhat cryptic
error message. It turnout out I needed to have the "ant-junit" package
installed, as well. So for the cassandra.spec file, I suggest that the
following line be added just below the existing BuildRequires line:
{{BuildRequires: ant-junit >= 1.9}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14179) Corrections in native_protocol_v4.spec
[ https://issues.apache.org/jira/browse/CASSANDRA-14179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daragan Bogdan updated CASSANDRA-14179: --- Description: Fixing inaccuracy in documentation for native_protocol_v4.spec Pull reques [link|https://github.com/apache/cassandra/pull/185]. was:Fixing inaccuracy in documentation for native_protocol_v4.spec > Corrections in native_protocol_v4.spec > -- > > Key: CASSANDRA-14179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14179 > Project: Cassandra > Issue Type: Improvement >Reporter: Daragan Bogdan >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Fixing inaccuracy in documentation for native_protocol_v4.spec > Pull reques [link|https://github.com/apache/cassandra/pull/185]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14179) Corrections in native_protocol_v4.spec
[ https://issues.apache.org/jira/browse/CASSANDRA-14179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daragan Bogdan updated CASSANDRA-14179: --- Description: Fixing inaccuracy in documentation for native_protocol_v4.spec (was: Fixing inaccuracy in documentation for ) > Corrections in native_protocol_v4.spec > -- > > Key: CASSANDRA-14179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14179 > Project: Cassandra > Issue Type: Improvement >Reporter: Daragan Bogdan >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Fixing inaccuracy in documentation for native_protocol_v4.spec -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14179) Corrections in native_protocol_v4.spec
[ https://issues.apache.org/jira/browse/CASSANDRA-14179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daragan Bogdan updated CASSANDRA-14179: --- Description: Fixing inaccuracy in documentation for > Corrections in native_protocol_v4.spec > -- > > Key: CASSANDRA-14179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14179 > Project: Cassandra > Issue Type: Improvement >Reporter: Daragan Bogdan >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Fixing inaccuracy in documentation for -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14179) Corrections in native_protocol_v4.spec
Daragan Bogdan created CASSANDRA-14179: -- Summary: Corrections in native_protocol_v4.spec Key: CASSANDRA-14179 URL: https://issues.apache.org/jira/browse/CASSANDRA-14179 Project: Cassandra Issue Type: Improvement Reporter: Daragan Bogdan -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
