RE: Cassandra 3.11 fails to start with JDK8u162

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?

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

Re: AbstractMethodError from JMXServerUtils after update from Java 1.8.0_112 to 1.8.0_162

https://issues.apache.org/jira/browse/CASSANDRA-14173 On 01/18/2018 03:29 PM, Stephen Rosenthal wrote: > Hi, > >   > > I got the following error after updating my Cassandra system from Java > 1.8.0_112 to 1.8.0_162: > >   > > java.lang.AbstractMethodError: >

AbstractMethodError from JMXServerUtils after update from Java 1.8.0_112 to 1.8.0_162

Hi, I got the following error after updating my Cassandra system from Java 1.8.0_112 to 1.8.0_162: java.lang.AbstractMethodError:

Re: ALTER default_time_to_live

Hi, thanks for answer! I've read article about TWCS, and I don't understand how claim "When rows reach their TTL (10 minutes here), they turn into tombstones. Our table defines that tombstones can be purged 1 minute after they were created.If all rows are created with the same TTL, SSTables

Re: Repair giving error

Hi alain Thanks for the response. I'm using cassandra 3.10 nodetool status shows all the nodes up No schema disaggrement port 7000 is open Regards Akshit Jain 9891724697 On Thu, Jan 18, 2018 at 4:53 PM, Alain RODRIGUEZ wrote: > Hello, > > I looks like a communication

Re: High read rate on hard-disk

Hy Alain, Thank you for your response. > - Other than the 'lock', Counters perform an implicit read before the write > operation. >From what I know there is one counter cache[1], that is used to read the old values of the counters. According to [2], it is used only for UPDATE requests > I

Re: Best compaction strategy for counters tables

Hi Alain, Thank you for your response. In my case, counter is the main table, having almost 40% of all data. Thank you for the recommendation about testing on one node. 2018-01-18 13:02 GMT+02:00 Alain RODRIGUEZ : > Hello, > > I believe there is not a really specifically

Re: Alter composite column

Compact storage only allows one column outside of the primary key so you'll definitely need to recreate your table if you want to add columns. Le jeu. 18 janv. 2018 à 12:18, Nicolas Guyomar a écrit : > Well it should be as easy as following this : >

Re: Is it recommended to enable debug log in production

+1 on removing 'DEBUG' level. I would stay at 'INFO' level, for the same reason, unless you are really debugging something ;-). C*heers, --- Alain Rodriguez - @arodream - al...@thelastpickle.com France / Spain The Last Pickle - Apache Cassandra Consulting

Re: Alter composite column

Yeah, I want column4 to appear in each cell name (rather than just once) which I think would be the same as altering the primary key. 2018-01-18 12:18 GMT+01:00 Nicolas Guyomar : > Well it should be as easy as following this : https://docs.datastax.com/ >

Re: ALTER default_time_to_live

> > I set default_time_to_live for existing table. Does it affect existing > data? No, it sets a default TTL for the future writes (that is no guarantee, as it can be overwritten in any specific query). It seems data to be deleted, but after compaction, I don't see any disk > space freed as

Re: Repair giving error

Hello, I looks like a communication issue. What Cassandra version are you using? What's the result of 'nodetool status '? Any schema disagreement 'nodetool describecluster'? Is the port 7000 opened and the nodes communicating with each other?(Ping is not proving connection is up, even though it

Re: Alter composite column

Well it should be as easy as following this : https://docs.datastax.com/en/cql/3.1/cql/cql_using/use_alter_add.html But I'm worried that your initial requirement was to change the clustering key, as Alexander stated, you need to create a new table and transfer your data in it On 18 January 2018

ALTER default_time_to_live

Hi, I set  default_time_to_live for existing table. Does it affect existing data? It seems data to be deleted, but after compaction, I don't see any disk space freed as expected. Database has data for almost year, GC time is ten days, and TTL is also ten days on one table and 100 days on other.

Re: Alter composite column

It was indeed created with C* 1.X Do you have any links or otherwise on how I would add the column4? I don't want to risk destroying my data. Best regards, Joel 2018-01-18 11:18 GMT+01:00 Nicolas Guyomar : > Hi Joel, > > You cannot alter a table primary key. > > You

Re: Best compaction strategy for counters tables

Hello, I believe there is not a really specifically good strategy for counters. Often counter tables size is relatively low (compared to events / raw data). So depending on the workload you might want to pick one or the other. Given the high number of reads the table will have to face (during

Re: High read rate on hard-disk

Hello Octavian, > I have a counter table(RF=1) SELECT vs UPDATE requests ratio is 0.001. ( Read Count: 3771000, Write Count: > 3401236000, in one month) SELECT vs UPDATE requests ratio is 0.001. ( Read Count: 3771000, Write > Count: 3401236000, in one month) The problem is that our read

RE: Cassandra 3.11 fails to start with JDK8u162

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

Re: Alter composite column

Hi Joel, You cannot alter a table primary key. You can however alter your existing table to only add column4 using cqlsh and cql, even if this table as created back with C* 1.X for instance On 18 January 2018 at 11:14, Joel Samuelsson wrote: > So to rephrase that in

Re: Alter composite column

Hi Joel, Sadly it's not possible to alter the primary key of a table in Cassandra. That would require to rewrite all data on disk to match the new partitioning and/or clustering. You need to create a new table and transfer all data from the old one programmatically. Cheers, Le jeu. 18 janv.

Re: Alter composite column

So to rephrase that in CQL terms I have a table like this: CREATE TABLE events ( key text, column1 int, column2 int, column3 text, value text, PRIMARY KEY(key, column1, column2, column3) ) WITH COMPACT STORAGE and I'd like to change it to: CREATE

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

Re: Cassandra 3.11 fails to start with JDK8u162

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 <