Re: Cassandra 3.11 fails to start with JDK8u162

2018-01-21 Thread Edward Ribeiro
Hello,

I have uploaded a couple of patches (targeting 3.6 to trunk) to address
https://issues.apache.org/jira/browse/CASSANDRA-14173 so that C* compiles
and runs on both JDK8u152 and JDK8u162. This patch still lacks review and
throughfully testing! So it can be fundamentally flawed and the best option
is just to really  avoid migrating to JDK8u162, as Sam correctly pointed
out, or a better solution pops up in the meantime.

Please, whenever you have time, let me know if it's incorrect or flawed so
that I can remove the attachments from the JIRA issue asap. Finally,
quoting Sam again: "we should identify a more stable solution & apply that
to both 3.11 and 4.0." Therefore, even if the patches make any sense, it's
a temporary workaround.

Regards,
Edward

On Fri, Jan 19, 2018 at 4:08 AM, Steinmaurer, Thomas <
thomas.steinmau...@dynatrace.com> wrote:

> Ben,
>
>
>
> at least 3.0.14 starts up fine for me with 8u162.
>
>
>
> Regards,
>
> Thomas
>
>
>
> *From:* Ben Wood [mailto:bw...@mesosphere.io]
> *Sent:* Donnerstag, 18. Jänner 2018 23:24
>
> *To:* user@cassandra.apache.org
> *Subject:* Re: Cassandra 3.11 fails to start with JDK8u162
>
>
>
> I'm correct in assuming 10091 didn't go into 3.0?
>
>
>
> On Thu, Jan 18, 2018 at 2:32 AM, Steinmaurer, Thomas <
> thomas.steinmau...@dynatrace.com> wrote:
>
> Sam,
>
>
>
> thanks for the confirmation. Going back to u152 then.
>
>
>
> Thomas
>
>
>
> *From:* li...@beobal.com [mailto:li...@beobal.com] *On Behalf Of *Sam
> Tunnicliffe
> *Sent:* Donnerstag, 18. Jänner 2018 10:16
> *To:* user@cassandra.apache.org
> *Subject:* Re: Cassandra 3.11 fails to start with JDK8u162
>
>
>
> This isn't (wasn't) a known issue, but the way that CASSANDRA-10091 was
> implemented using internal JDK classes means it was always possible that a
> minor JVM version change could introduce incompatibilities (CASSANDRA-2967
> is also relevant).
>
> We did already know that we need to revisit the way this works in 4.0 for
> JDK9 support (CASSANDRA-9608), so we should identify a more stable solution
> & apply that to both 3.11 and 4.0.
>
> In the meantime, downgrading to 152 is the only real option.
>
>
>
> I've opened https://issues.apache.org/jira/browse/CASSANDRA-14173 for
> this.
>
>
>
> Thanks,
>
> Sam
>
>
>
>
>
> On 18 January 2018 at 08:43, Nicolas Guyomar 
> wrote:
>
> Thank you Thomas for starting this thread, I'm having exactly the same
> issue on AWS EC2 RHEL-7.4_HVM-20180103-x86_64-2-Hourly2-GP2
> (ami-dc13a4a1)  I was starting to bang my head on my desk !
>
>
>
> So I'll try to downgrade back to 152 then !
>
>
>
>
>
>
>
> On 18 January 2018 at 08:34, Steinmaurer, Thomas <
> thomas.steinmau...@dynatrace.com> wrote:
>
> Hello,
>
>
>
> after switching from JDK8u152 to JDK8u162, Cassandra fails with the
> following stack trace upon startup.
>
>
>
> 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]
>
>
>
> Is this a known issue?
>
>
>
>
>
> Thanks,
>
> Thomas
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
> disclose it to anyone else. If you received it in error please notify us
> immediately and then destroy it. Dynatrace Austria GmbH (registration
> number FN 91482h) is a company registered in Linz whose registered office
> is at 4040 Linz, Austria, Freist
> 
> ädterstra
> 

Re: Slender Cassandra Cluster Project

2018-01-21 Thread Anthony Grasso
Hi Kenneth,

Fantastic idea!

One thing that came to mind from my reading of the proposed setup was rack
awareness of each node. Given that the proposed setup contains three DCs, I
assume that each node will be made rack aware? If not, consider defining
three racks for each DC and placing two nodes in each rack. This will
ensure that all the nodes in a single rack contain at most one replica of
the data.

Regards,
Anthony

On 17 January 2018 at 11:24, Kenneth Brotman 
wrote:

> Sure.  That takes the project from awesome to 10X awesome.  I absolutely
> would be willing to do that.  Thanks Kurt!
>
>
>
> Regarding your comment on the keyspaces, I agree.  There should be a few
> simple examples one way or the other that can be duplicated and observed,
> and then an example to duplicate and play with that has a nice real world
> mix, with some keyspaces that replicate over only a subset of DC’s and some
> that replicate to all DC’s.
>
>
>
> Kenneth Brotman
>
>
>
> *From:* kurt greaves [mailto:k...@instaclustr.com]
> *Sent:* Tuesday, January 16, 2018 1:31 PM
> *To:* User
> *Subject:* Re: Slender Cassandra Cluster Project
>
>
>
> Sounds like a great idea. Probably would be valuable to add to the
> official docs as an example set up if you're willing.
>
>
>
> Only thing I'd add is that you should have keyspaces that replicate over
> only a subset of DC's, plus one/some replicated to all DC's
>
>
>
> On 17 Jan. 2018 03:26, "Kenneth Brotman" 
> wrote:
>
> I’ve begun working on a reference project intended to provide guidance on
> configuring and operating a modest Cassandra cluster of about 18 nodes
> suitable for the economic study, demonstration, experimentation and testing
> of a Cassandra cluster.
>
>
>
> The slender cluster would be designed to be as inexpensive as possible
> while still using real world hardware in order to lower the cost to those
> with limited initial resources. Sorry no Raspberry Pi’s for this project.
>
>
>
> There would be an on-premises version and a cloud version.  Guidance would
> be provided on configuring the cluster, on demonstrating key Cassandra
> behaviors, on files sizes, capacity to use with the Slender Cassandra
> Cluster, and so on.
>
>
>
> Why about eighteen nodes? I tried to figure out what the minimum number of
> nodes needed for Cassandra to be Cassandra is?  Here were my considerations:
>
>
>
> • A user wouldn’t run Cassandra in just one data center; so at
> least two datacenters.
>
> • A user probably would want a third data center available for
> analytics.
>
> • There needs to be enough nodes for enough parallelism to
> observe Cassandra’s distributed nature.
>
> • The cluster should have enough nodes that one gets a sense
> of the need for cluster wide management tools to do things like repairs,
> snapshots and cluster monitoring.
>
> • The cluster should be able to demonstrate a RF=3 with local
> quorum.  If replicated in all three data centers, one write would impact
> half the 18 nodes, 3 datacenters X 3 nodes per data center = 9 nodes of 18
> nodes.  If replicated in two of the data centers, one write would still
> impact one third of the 18 nodes, 2 DC’s X 3 nodes per DC = 6 of the 18
> nodes.
>
>
>
> So eighteen seems like the minimum number of nodes needed.  That’s six
> nodes in each of three data centers.
>
>
>
> Before I get too carried away with this project, I’m looking for some
> feedback on whether this project would indeed be helpful to others? Also,
> should the project be changed in any way?
>
>
>
> It’s always a pleasure to connect with the Cassandra users’ community.
> Thanks for all the hard work, the expertise, the civil dialog.
>
>
>
> Kenneth Brotman
>