data file directory path customization

[Mehdi Bada]

Hi all, 

With the new apache cassandra 3.7 version, It is possible to setup a 
customizable path for data_files, saved_caches and commit_log in the 
configuration file (cassandra.yaml)? 
I ask the question because during some test, I wanted to setup the path for : 

- data_files_directories 
- commitlog_directory 
- saved_caches_directory 

After configuring this 3 variables (parameters) in the cassandra-yaml, I had 
the following issues: 

[cassandra@test bin]$ ./cassandra -f 
18:54:22.443 [main] INFO o.a.c.config.YamlConfigurationLoader - Configuration 
location: file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
18:54:22.447 [main] DEBUG o.a.c.config.YamlConfigurationLoader - Loading 
settings from file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered 
during startup: Invalid yaml: 
file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
Error: while parsing a block mapping; expected , but found 
BlockMappingStart; in 'reader', line 188, column 2: 
data_file_directories: 
^ 


 
18:59:30.554 [main] INFO o.a.c.config.YamlConfigurationLoader - Configuration 
location: file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
18:59:30.558 [main] DEBUG o.a.c.config.YamlConfigurationLoader - Loading 
settings from file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered 
during startup: Invalid yaml: 
file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
Error: while parsing a block mapping; expected , but found 
BlockMappingStart; in 'reader', line 194, column 2: 
commitlog_directory: /u01/cassan .. . 
^ 

***
 

The first issue was for the data_files_directories, after that I commented it 
out in the cassandra.yaml, and I had the same issue for the commitlog_directory 
parameter. 

Below the setting of my 2 variables: 

*** 
data_file_directories: 
- /u01/cassandradata/CSD1/data 

. 
commitlog_directory: /u01/cassandradata/CSD1/commitlog 
*** 

I also tested the syntax with double quote " " -> Same issue 


Many thanks in advance for your feedback 

Best Regards 

Mehdi Bada 


 
Mehdi Bada | Consultant 
Phone: +41 32 422 96 00 | Mobile: +41 79 928 75 48 | Fax: +41 32 422 96 15 
dbi services, Rue de la Jeunesse 2, CH-2800 Delémont 
mehdi.b...@dbi-services.com 
www.dbi-services.com 



⇒ dbi services is recruiting Oracle & SQL Server experts ! – Join the team 

Help on temporal data modeling

[Denis Mikhaylov]

Hi!

I have question regarding data modelling.

Let’s say that I have `subscriptions` table with two columns `subscription_id 
text` and `next_billing_date timestamp`.

How do I model a table to efficiently query all subscriptions due today 
(something like `where next_billing_date <= today`)

During writing data into Cassandra 3.7.0 using Python driver 3.7 sometime loose Connection because of Server NullPointerException (Help please!)

[Rajesh Radhakrishnan]

Hi,


In one of our C* cluster we are using the latest Cassandra 3.7.0 
(datastax-ddc.3.70) with Python driver 3.7. We are trying to insert 2 million 
row or more data into the database, it works but sometimes we are getting "Null 
pointer Exception". I am quoting  the Exception here.
Any help would be highly appreciated.

We are using Python 2.7.11 and Java 1.8.0_73 in the Cassandra nodes and in the 
client its Python 2.7.12.

==
ERROR [SharedPool-Worker-6] 2016-09-23 09:42:55,002 Message.java:611 - 
Unexpected exception during request; channel = [id: 0xc208da86, 
L:/IP1.IP2.IP3.IP4:9042 - R:/IP5.IP6.IP7.IP8:58418]

java.lang.NullPointerException: null

at 
org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:113) 
~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:273)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:85)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:81)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.getRoleFromTable(CassandraRoleManager.java:503)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:485)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.canLogin(CassandraRoleManager.java:298)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at org.apache.cassandra.service.ClientState.login(ClientState.java:227) 
~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:79)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
 [apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
 [apache-cassandra-3.7.0.jar:3.7.0]

at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
 [netty-all-4.0.36.Final.jar:4.0.36.Final]

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
 [netty-all-4.0.36.Final.jar:4.0.36.Final]

at 
io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
 [netty-all-4.0.36.Final.jar:4.0.36.Final]

at 
io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:283)
 [netty-all-4.0.36.Final.jar:4.0.36.Final]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_73]

at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
 [apache-cassandra-3.7.0.jar:3.7.0]

at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
[apache-cassandra-3.7.0.jar:3.7.0]

at java.lang.Thread.run(Thread.java:745) [na:1.8.0_73]

ERROR [SharedPool-Worker-1] 2016-09-23 09:42:56,238 Message.java:611 - 
Unexpected exception during request; channel = [id: 0x8e2eae00, 
L:/IP1.IP2.IP3.IP4:9042 - R:/IP5.IP6.IP7.IP8:58421]

java.lang.NullPointerException: null

at 
org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:113) 
~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:273)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:85)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:81)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.getRoleFromTable(CassandraRoleManager.java:503)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:485)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.canLogin(CassandraRoleManager.java:298)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at org.apache.cassandra.service.ClientState.login(ClientState.java:227) 
~[apa

Re: data file directory path customization

[Alain RODRIGUEZ]

Hi Mehdi,


> After configuring this 3 variables (parameters) in the cassandra-yaml, I
> had the following issues
>

With the new apache cassandra 3.7 version, It is possible to setup a
> customizable path for data_files, saved_caches and commit_log in the
> configuration file (cassandra.yaml)?
>

According to the configuration, parameters you're using are still valid in
3.7: https://github.com/apache/cassandra/blob/cassandra-3.7/
conf/cassandra.yaml#L184-L194.

*Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Invalid yaml: *


If I had to guess, I would say you have an indentation issue. When you
uncommented those properties, did you remove "#" - 1 character - or "# " -
2 characters - including the space? If I remember correctly, YAML is
sensitive to this kind of stuff. I would try that or some other similar
tool in case of doubts:

http://www.yamllint.com/

C*heers,
---
Alain Rodriguez - @arodream - al...@thelastpickle.com
France

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com

2016-09-23 9:58 GMT+02:00 Mehdi Bada :

> Hi all,
>
> With the new apache cassandra 3.7 version, It is possible to setup a
> customizable path for data_files, saved_caches and commit_log in the
> configuration file (cassandra.yaml)?
> I ask the question because during some test, I wanted to setup the path
> for :
>
> *   - data_files_directories*
> *   - commitlog_directory*
> *   - saved_caches_directory*
>
> After configuring this 3 variables (parameters) in the cassandra-yaml, I
> had the following issues:
>
> *[cassandra@test bin]$ ./cassandra -f*
> *18:54:22.443 [main] INFO  o.a.c.config.YamlConfigurationLoader -
> Configuration location:
> file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml*
> *18:54:22.447 [main] DEBUG o.a.c.config.YamlConfigurationLoader - Loading
> settings from file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml*
> *Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Invalid yaml:
> file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml*
> * Error: while parsing a block mapping; expected , but found
> BlockMappingStart;  in 'reader', line 188, column 2:*
> * data_file_directories: *
> * ^*
>
> 
> 
> 
> *18:59:30.554 [main] INFO  o.a.c.config.YamlConfigurationLoader -
> Configuration location:
> file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml*
> *18:59:30.558 [main] DEBUG o.a.c.config.YamlConfigurationLoader - Loading
> settings from file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml*
> *Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Invalid yaml:
> file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml*
> * Error: while parsing a block mapping; expected , but found
> BlockMappingStart;  in 'reader', line 194, column 2:*
> * commitlog_directory: /u01/cassan ..*.
>  ^
>
> 
> 
> ***
>
> The first issue was for the data_files_directories, after that I commented
> it out in the cassandra.yaml, and I had the same issue for the
> commitlog_directory parameter.
>
> Below the setting of my 2 variables:
>
> ***
> * data_file_directories: *
> * - /u01/cassandradata/CSD1/data*
>
> *.*
> *commitlog_directory: /u01/cassandradata/CSD1/commitlog*
> 
> ***
>
> I also tested the syntax with double quote " " -> Same issue
>
>
> Many thanks in advance for your feedback
>
> Best Regards
>
> Mehdi Bada
>
>
> 
> *Mehdi Bada* | Consultant
> Phone: +41 32 422 96 00 | Mobile: +41 79 928 75 48 | Fax: +41 32 422 96 15
> dbi services, Rue de la Jeunesse 2, CH-2800 Delémont
> mehdi.b...@dbi-services.com
> www.dbi-services.com
>
>
>
> *⇒ dbi services is recruiting Oracle & SQL Server experts ! – Join the
> team
> *
>
>

Re: During writing data into Cassandra 3.7.0 using Python driver 3.7 sometime loose Connection because of Server NullPointerException (Help please!)

[Sam Tunnicliffe]

The stacktrace suggests that when a connection is being established, either
the can_login or is_superuser attribute of the authenticated role is null,
which is definitely a bug as there should be no way to create a role in
that state.

Could you please open a ticket on
https://issues.apache.org/jira/browse/CASSANDRA (including as much detail
as possible)? If you could reply back to this with the ticket # that'd be
helpful for anyone coming across a similar issue in future.

Thanks,
Sam


On Fri, Sep 23, 2016 at 10:33 AM, Rajesh Radhakrishnan <
rajesh.radhakrish...@phe.gov.uk> wrote:

> Hi,
>
>
> In one of our C* cluster we are using the latest Cassandra 3.7.0
> (datastax-ddc.3.70) with Python driver 3.7. We are trying to insert 2
> million row or more data into the database, it works but sometimes we are
> getting "Null pointer Exception". I am quoting  the Exception here.
> Any help would be highly appreciated.
>
> We are using Python 2.7.11 and Java 1.8.0_73 in the Cassandra nodes and in
> the client its Python 2.7.12.
>
> 
> ==
> ERROR [SharedPool-Worker-6] 2016-09-23 09:42:55,002 Message.java:611 -
> Unexpected exception during request; channel = [id: 0xc208da86,
> L:/IP1.IP2.IP3.IP4:9042 - R:/IP5.IP6.IP7.IP8:58418]
>
> java.lang.NullPointerException: null
>
> at org.apache.cassandra.serializers.BooleanSerializer.
> deserialize(BooleanSerializer.java:33) ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at org.apache.cassandra.serializers.BooleanSerializer.
> deserialize(BooleanSerializer.java:24) ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:113)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at org.apache.cassandra.cql3.UntypedResultSet$Row.
> getBoolean(UntypedResultSet.java:273) ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:85)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:81)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.auth.CassandraRoleManager.getRoleFromTable(CassandraRoleManager.java:503)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:485)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.auth.CassandraRoleManager.canLogin(CassandraRoleManager.java:298)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at org.apache.cassandra.service.ClientState.login(ClientState.java:227)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:79)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
> [apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
> [apache-cassandra-3.7.0.jar:3.7.0]
>
> at io.netty.channel.SimpleChannelInboundHandler.channelRead(
> SimpleChannelInboundHandler.java:105) [netty-all-4.0.36.Final.jar:4.
> 0.36.Final]
>
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(
> AbstractChannelHandlerContext.java:292) [netty-all-4.0.36.Final.jar:4.
> 0.36.Final]
>
> at io.netty.channel.AbstractChannelHandlerContext.access$600(
> AbstractChannelHandlerContext.java:32) [netty-all-4.0.36.Final.jar:4.
> 0.36.Final]
>
> at io.netty.channel.AbstractChannelHandlerContext$7.run(
> AbstractChannelHandlerContext.java:283) [netty-all-4.0.36.Final.jar:4.
> 0.36.Final]
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_73]
>
> at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorServ
> ice$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> [apache-cassandra-3.7.0.jar:3.7.0]
>
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.7.0.jar:3.7.0]
>
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_73]
>
> ERROR [SharedPool-Worker-1] 2016-09-23 09:42:56,238 Message.java:611 -
> Unexpected exception during request; channel = [id: 0x8e2eae00,
> L:/IP1.IP2.IP3.IP4:9042 - R:/IP5.IP6.IP7.IP8:58421]
>
> java.lang.NullPointerException: null
>
> at org.apache.cassandra.serializers.BooleanSerializer.
> deserialize(BooleanSerializer.java:33) ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at org.apache.cassandra.serializers.BooleanSerializer.
> deserialize(BooleanSerializer.java:24) ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at 
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:113)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
>
> at org.apache.cassandra.cql3.UntypedResultSet$Row.
> getBoolean(UntypedResultSet.java:273) ~[apache-cassandra-3.7.0.ja

RE: data file directory path customization

[Rajesh Radhakrishnan]

Hi Mehdi,

Did you set it same for all nodes in the cluster?
Please check the space between the key and value and also before the key.
Key (data_files_directories, commitlog_directory, saved_caches_directory).
Check the write permission of the parent directory too.

Hope this helps!

Kind regards,
Rajesh Radhakrishnan


From: Mehdi Bada [mehdi.b...@dbi-services.com]
Sent: 23 September 2016 08:58
To: user@cassandra.apache.org
Subject: data file directory path customization

Hi all,

With the new apache cassandra 3.7 version, It is possible to setup a 
customizable path for data_files, saved_caches and commit_log in the 
configuration file (cassandra.yaml)?
I ask the question because during some test, I wanted to setup the path for :

   - data_files_directories
   - commitlog_directory
   - saved_caches_directory

After configuring this 3 variables (parameters) in the cassandra-yaml, I had 
the following issues:

[cassandra@test bin]$ ./cassandra -f
18:54:22.443 [main] INFO  o.a.c.config.YamlConfigurationLoader - Configuration 
location: file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml
18:54:22.447 [main] DEBUG o.a.c.config.YamlConfigurationLoader - Loading 
settings from file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered 
during startup: Invalid yaml: 
file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml
 Error: while parsing a block mapping; expected , but found 
BlockMappingStart;  in 'reader', line 188, column 2:
 data_file_directories:
 ^


18:59:30.554 [main] INFO  o.a.c.config.YamlConfigurationLoader - Configuration 
location: file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml
18:59:30.558 [main] DEBUG o.a.c.config.YamlConfigurationLoader - Loading 
settings from file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered 
during startup: Invalid yaml: 
file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml
 Error: while parsing a block mapping; expected , but found 
BlockMappingStart;  in 'reader', line 194, column 2:
 commitlog_directory: /u01/cassan ...
 ^

***

The first issue was for the data_files_directories, after that I commented it 
out in the cassandra.yaml, and I had the same issue for the commitlog_directory 
parameter.

Below the setting of my 2 variables:

***
 data_file_directories:
 - /u01/cassandradata/CSD1/data

.
commitlog_directory: /u01/cassandradata/CSD1/commitlog
***

I also tested the syntax with double quote " " -> Same issue


Many thanks in advance for your feedback

Best Regards

Mehdi Bada



Mehdi Bada | Consultant
Phone: +41 32 422 96 00 | Mobile: +41 79 928 75 48 | Fax: +41 32 422 96 15
dbi services, Rue de la Jeunesse 2, CH-2800 Delémont
mehdi.b...@dbi-services.com
www.dbi-services.com


[cid:1e02ecf01895aacdb0fd8d778ef9a33cef1c83ad@zimbra]

⇒ dbi services is recruiting Oracle & SQL Server experts ! – Join the 
team


**
The information contained in the EMail and any attachments is confidential and 
intended solely and for the attention and use of the named addressee(s). It may 
not be disclosed to any other person without the express authority of Public 
Health England, or the intended recipient, or both. If you are not the intended 
recipient, you must not disclose, copy, distribute or retain this message or 
any part of it. This footnote also confirms that this EMail has been swept for 
computer viruses by Symantec.Cloud, but please re-sweep any attachments before 
opening or saving. http://www.gov.uk/PHE
**

Re: data file directory path customization

[Mehdi Bada]

Hi Alain, 

Thank you for your feedback, the problem was the space character before the 
data_files_directories parameter. As you said the the YAML is very case 
sensitive. 

Many thanks for your feedback and have a nice day. 

Regards 

--- 

Mehdi Bada | Consultant 
Phone: +41 32 422 96 00 | Mobile: +41 79 928 75 48 | Fax: +41 32 499 96 15 
dbi services, Rue de la Jeunesse 2, CH-2800 Delémont 
mehdi.b...@dbi-services.com 
www.dbi-services.com 




From: "Alain RODRIGUEZ"  
To: "user"  
Sent: Friday, September 23, 2016 12:06:09 PM 
Subject: Re: data file directory path customization 

Hi Mehdi, 


After configuring this 3 variables (parameters) in the cassandra-yaml, I had 
the following issues 




BQ_BEGIN
With the new apache cassandra 3.7 version, It is possible to setup a 
customizable path for data_files, saved_caches and commit_log in the 
configuration file (cassandra.yaml)? 

BQ_END

According to the configuration, parameters you're using are still valid in 3.7: 
https://github.com/apache/cassandra/blob/cassandra-3.7/conf/cassandra.yaml#L184-L194
 . 


BQ_BEGIN
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered 
during startup: Invalid yaml: 
BQ_END

If I had to guess, I would say you have an indentation issue. When you 
uncommented those properties, did you remove "#" - 1 character - or "# " - 2 
characters - including the space? If I remember correctly, YAML is sensitive to 
this kind of stuff. I would try that or some other similar tool in case of 
doubts: 

http://www.yamllint.com/ 

C*heers, 
--- 
Alain Rodriguez - @arodream - al...@thelastpickle.com 
France 

The Last Pickle - Apache Cassandra Consulting 
http://www.thelastpickle.com 

2016-09-23 9:58 GMT+02:00 Mehdi Bada < mehdi.b...@dbi-services.com > : 

BQ_BEGIN

Hi all, 

With the new apache cassandra 3.7 version, It is possible to setup a 
customizable path for data_files, saved_caches and commit_log in the 
configuration file (cassandra.yaml)? 
I ask the question because during some test, I wanted to setup the path for : 

- data_files_directories 
- commitlog_directory 
- saved_caches_directory 

After configuring this 3 variables (parameters) in the cassandra-yaml, I had 
the following issues: 

[cassandra@test bin]$ ./cassandra -f 
18:54:22.443 [main] INFO o.a.c.config.YamlConfigurationLoader - Configuration 
location: file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
18:54:22.447 [main] DEBUG o.a.c.config.YamlConfigurationLoader - Loading 
settings from file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered 
during startup: Invalid yaml: 
file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
Error: while parsing a block mapping; expected , but found 
BlockMappingStart; in 'reader', line 188, column 2: 
data_file_directories: 
^ 


 
18:59:30.554 [main] INFO o.a.c.config.YamlConfigurationLoader - Configuration 
location: file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
18:59:30.558 [main] DEBUG o.a.c.config.YamlConfigurationLoader - Loading 
settings from file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered 
during startup: Invalid yaml: 
file:/u00/app/cassandra/admin/CSD1/etc/cassandra.yaml 
Error: while parsing a block mapping; expected , but found 
BlockMappingStart; in 'reader', line 194, column 2: 
commitlog_directory: /u01/cassan .. . 
^ 

***
 

The first issue was for the data_files_directories, after that I commented it 
out in the cassandra.yaml, and I had the same issue for the commitlog_directory 
parameter. 

Below the setting of my 2 variables: 

*** 
data_file_directories: 
- /u01/cassandradata/CSD1/data 

. 
commitlog_directory: /u01/cassandradata/CSD1/commitlog 
*** 

I also tested the syntax with double quote " " -> Same issue 


Many thanks in advance for your feedback 

Best Regards 

Mehdi Bada 


 
Mehdi Bada | Consultant 
Phone: +41 32 422 96 00 | Mobile: +41 79 928 75 48 | Fax: +41 32 422 96 15 
dbi services, Rue de la Jeunesse 2, CH-2800 Delémont 
mehdi.b...@dbi-services.com 
www.dbi-services.com 



⇒ dbi services is recruiting Oracle & SQL Server experts ! – Join the team 


BQ_END

Re: Help on temporal data modeling

[Alain RODRIGUEZ]

Hi Denis,

You might want to have a look at

- Materialized views
http://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views
- Secondary index
https://docs.datastax.com/en/cql/3.3/cql/cql_using/useWhenIndex.html

My 2 cents: make sure to understand the implications before moving forward,
what is happening under the hood or at least that your use case fits with
the recommendations. Indexes and views are not free. If you want to know
more, you might want to watch this:
https://www.youtube.com/watch?v=dxiuQ2CkXfM from DuyHai at the summit this
year :-).

C*heers,
---
Alain Rodriguez - @arodream - al...@thelastpickle.com
France

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com

2016-09-23 10:42 GMT+02:00 Denis Mikhaylov :

> Hi!
>
> I have question regarding data modelling.
>
> Let’s say that I have `subscriptions` table with two columns
> `subscription_id text` and `next_billing_date timestamp`.
>
> How do I model a table to efficiently query all subscriptions due today
> (something like `where next_billing_date <= today`)

#RE: During writing data into Cassandra 3.7.0 using Python driver 3.7 sometime loose Connection because of Server NullPointerException (Help please!)

[Rajesh Radhakrishnan]

Hi Sam,

Thank you for the prompt reply!
We will raise a ticket with Cassandra Jira.

In between I am posting here the Exception from the client too.
The client is Python script running Python 2.7.12.
=

Traceback (most recent call last):
 File "vssandra_v5.py", line 132, in 
   db.insert_batch()
 File "vssandra_v5.py", line 60, in insert_batch
   self.session.execute(self.batch, timeout=None)
 File "cassandra/cluster.py", line 1998, in cassandra.cluster.Session.execute 
(cassandra/cluster.c:34869)
 File "cassandra/cluster.py", line 3781, in 
cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:73073)
cassandra.protocol.ServerError: 

==

Kind regards,
Rajesh Radhakrishnan


From: li...@beobal.com [li...@beobal.com] on behalf of Sam Tunnicliffe 
[s...@beobal.com]
Sent: 23 September 2016 11:06
To: user@cassandra.apache.org
Subject: Re: During writing data into Cassandra 3.7.0 using Python driver 3.7 
sometime loose Connection because of Server NullPointerException (Help please!)

The stacktrace suggests that when a connection is being established, either the 
can_login or is_superuser attribute of the authenticated role is null, which is 
definitely a bug as there should be no way to create a role in that state.

Could you please open a ticket on 
https://issues.apache.org/jira/browse/CASSANDRA
 (including as much detail as possible)? If you could reply back to this with 
the ticket # that'd be helpful for anyone coming across a similar issue in 
future.

Thanks,
Sam


On Fri, Sep 23, 2016 at 10:33 AM, Rajesh Radhakrishnan 
>
 wrote:
Hi,


In one of our C* cluster we are using the latest Cassandra 3.7.0 
(datastax-ddc.3.70) with Python driver 3.7. We are trying to insert 2 million 
row or more data into the database, it works but sometimes we are getting "Null 
pointer Exception". I am quoting  the Exception here.
Any help would be highly appreciated.

We are using Python 2.7.11 and Java 1.8.0_73 in the Cassandra nodes and in the 
client its Python 2.7.12.

==
ERROR [SharedPool-Worker-6] 2016-09-23 09:42:55,002 Message.java:611 - 
Unexpected exception during request; channel = [id: 0xc208da86, 
L:/IP1.IP2.IP3.IP4:9042 - R:/IP5.IP6.IP7.IP8:58418]

java.lang.NullPointerException: null

at 
org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:113) 
~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:273)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:85)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:81)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.getRoleFromTable(CassandraRoleManager.java:503)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:485)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.auth.CassandraRoleManager.canLogin(CassandraRoleManager.java:298)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at org.apache.cassandra.service.ClientState.login(ClientState.java:227) 
~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:79)
 ~[apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
 [apache-cassandra-3.7.0.jar:3.7.0]

at 
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
 [apache-cassandra-3.7.0.jar:3.7.0]

at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
 [netty-all-4.0.36.Final.jar:4.0.36.Final]

at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
 [netty-all-4.0.36.Final.jar:4.0.36.Final]

at 
io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
 [netty-all-4.0.36.Final.jar:4.0.36.Final]

at 
io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:283)
 [netty-all-4.0.36.Final.jar:4.0.36.Final]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_73]

at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
 [apache-cassandra-3.7.0.jar:3.7.0]

at org.apache.cassandr

Re: Help on temporal data modeling

[Peter Lin]

Ignoring noSql for a minute, the standard way of modeling this in car and
health insurance is with effective/expiration day. Commonly called
bi-temporal data modeling.

How people model bi-temporal models varies quite a bit from first hand
experience, but the common thing is to have transaction timestamp,
effective day and expiration day. This way, when the system needs to get
all the policies that expires in 30 days, it would run a query like this

select * from policies where expiration = '2016-10-25'

the batch application is responsible for calculating the expiration by
getting today's date + 30 days. The first thing I would change is modify
next_billing_date from timestamp to date and set the hour to 00:00:00. It
doesn't make sense to use timestamp datatype for this particular use case.

Getting back to Cassandra and CQL. You should be able to just query it
without having to resort to materialized views and secondary indexes. If
you really want to index it, use Solr or buy a license of DSE. The temporal
database I built on top of Cassandra uses Solr, which gives me greater
flexibility and control over indexes and query performance.


On Fri, Sep 23, 2016 at 4:42 AM, Denis Mikhaylov  wrote:

> Hi!
>
> I have question regarding data modelling.
>
> Let’s say that I have `subscriptions` table with two columns
> `subscription_id text` and `next_billing_date timestamp`.
>
> How do I model a table to efficiently query all subscriptions due today
> (something like `where next_billing_date <= today`)

Re: understanding partitions

[Firdousi Farozan]

Hi,

One more thing to consider is wide partition. Even though theoretically
Cassandra supports wide rows, practical limit is max 100 MB per partition.
So based on your use-case and model, you may have to split the data into
partitions so that wide partitions are not created.

Regards,
Firdousi

On Thu, Sep 22, 2016 at 3:08 AM, S Ahmed  wrote:

> Hello,
>
> If you have a 10 node cluster, how does having 10 partitions or 100
> partitions change how cassandra will perform?
>
> With 10 partitions you will have 1 partition per node.
> WIth 100 partitions you will have 10 partitions per node.
>
> With 100 partitions I guess it helps because when you add more nodes to
> your cluster, the data can be redistributed since you have more nodes.
>
> What else are things to consider?
>

Re: Help on temporal data modeling

[Denis Mikhaylov]

Thanks, for you answer.

Wouldn’t simple `select * from subscriptions where next_billing_date = 
'2016-10-25’` require full scan of all partitions?

> On 23 Sep 2016, at 14:28, Peter Lin  wrote:
> 
> 
> Ignoring noSql for a minute, the standard way of modeling this in car and 
> health insurance is with effective/expiration day. Commonly called 
> bi-temporal data modeling.
> 
> How people model bi-temporal models varies quite a bit from first hand 
> experience, but the common thing is to have transaction timestamp, effective 
> day and expiration day. This way, when the system needs to get all the 
> policies that expires in 30 days, it would run a query like this
> 
> select * from policies where expiration = '2016-10-25'
> 
> the batch application is responsible for calculating the expiration by 
> getting today's date + 30 days. The first thing I would change is modify 
> next_billing_date from timestamp to date and set the hour to 00:00:00. It 
> doesn't make sense to use timestamp datatype for this particular use case.
> 
> Getting back to Cassandra and CQL. You should be able to just query it 
> without having to resort to materialized views and secondary indexes. If you 
> really want to index it, use Solr or buy a license of DSE. The temporal 
> database I built on top of Cassandra uses Solr, which gives me greater 
> flexibility and control over indexes and query performance.
> 
> 
> On Fri, Sep 23, 2016 at 4:42 AM, Denis Mikhaylov  wrote:
> Hi!
> 
> I have question regarding data modelling.
> 
> Let’s say that I have `subscriptions` table with two columns `subscription_id 
> text` and `next_billing_date timestamp`.
> 
> How do I model a table to efficiently query all subscriptions due today 
> (something like `where next_billing_date <= today`)
> 

Re: Help on temporal data modeling

[Peter Lin]

yes it would. Whether next_billing_date is timestamp or date wouldn't make
any difference on scanning all partitions. If you want to them to be on the
same node, you can use composite key, but there's a trade off. The nodes
may get unbalanced, so you have to do the math to figure out if your
specific use case would lead to unbalanced nodes.

These kinds of partitioning problems have been around for over 30 yrs, so
it's not a problem that will magically go away. In theory, if each
partition is small enough the query times "should" be acceptable. Having a
few large partitions isn't good in practice regardless of whether it's
RDBMS or NoSql

https://docs.datastax.com/en/cql/3.1/cql/cql_reference/refCompositePk.html



On Fri, Sep 23, 2016 at 7:36 AM, Denis Mikhaylov  wrote:

> Thanks, for you answer.
>
> Wouldn’t simple `select * from subscriptions where next_billing_date =
> '2016-10-25’` require full scan of all partitions?
>
>

Re: Nodetool repair

[Romain Hardouin]

OK. If you still have issues after setting streaming_socket_timeout_in_ms != 0, 
consider increasing request_timeout_in_ms to a high value, say 1 or 2 minutes. 
See comments in https://issues.apache.org/jira/browse/CASSANDRA-7904Regarding 
2.1, be sure to test incremental repair on your data before to run it in 
production ;-)
Romain

Upgrading from Cassandra 2.1.12 to 3.0.9

[Khaja, Raziuddin (NIH/NLM/NCBI) [C]]

Hello all,

I would like to upgrade my Cassandra cluster from 2.1.12 to 3.7.

I have read the following documentation:

· 
http://docs.datastax.com/en/latest-upgrade/upgrade/cassandra/upgrdCassandra.html

· https://github.com/apache/cassandra/blob/cassandra-3.7/NEWS.txt

but still had some questions:

· The upgrdCassandra.html page says : “Upgrade from Cassandra 2.1 
versions later or equal to 2.1.9 directly to Cassandra 3.0.x”, and I am not 
sure if this includes 3.x, my question is: Can I upgrade directly to 3.7?

· Can I run a heterogeneous cluster, with one DC running 2.1.12 and 
another DC running 3.7?

Thanks,
-Razi

Re: How to query '%' character using LIKE operator in Cassandra 3.7?

[Mikhail Krupitskiy]

Hi, Jim,

What pattern should be used to search “ends with  ‘%escape’ “ with your 
conception?

Thanks,
Mikhail
> On 22 Sep 2016, at 18:51, Jim Ancona  wrote:
> 
> To answer DuyHai's question without introducing new syntax, I'd suggest:
>> LIKE '%%%escape' means STARTS WITH '%' AND ENDS WITH 'escape' 
> So the first two %'s are translated to a literal, non-wildcard % and the 
> third % is a wildcard because it's not doubled.
> 
> Jim
> 
> On Thu, Sep 22, 2016 at 11:40 AM, Mikhail Krupitskiy 
> mailto:mikhail.krupits...@jetbrains.com>> 
> wrote:
> I guess that it should be similar to how it is done in SQL for LIKE patterns.
> 
> You can introduce an escape character, e.g. ‘\’.
> Examples:
> ‘%’ - any string
> ‘\%’ - equal to ‘%’ character
> ‘\%foo%’ - starts from ‘%foo’
> ‘%%%escape’ - ends with ’escape’
> ‘\%%’ - starts from ‘%’
> ‘\\\%%’ - starts from ‘\%’ .
> 
> What do you think?
> 
> Thanks,
> Mikhail
>> On 22 Sep 2016, at 16:47, DuyHai Doan > > wrote:
>> 
>> Hello Mikhail
>> 
>> It's more complicated that it seems
>> 
>> LIKE '%%escape' means  EQUAL TO '%escape'
>> 
>> LIKE '%escape' means ENDS WITH 'escape'
>> 
>> What's about LIKE '%%%escape' 
>> 
>> How should we treat this case ? Replace %% by % at the beginning of the 
>> searched term ??
>> 
>> 
>> 
>> On Thu, Sep 22, 2016 at 3:31 PM, Mikhail Krupitskiy 
>> mailto:mikhail.krupits...@jetbrains.com>> 
>> wrote:
>> Hi!
>> 
>> We’ve talked about two items:
>> 1) ‘%’ as a wildcard in the middle of LIKE pattern.
>> 2) How to escape ‘%’ to be able to find strings with the ‘%’ char with help 
>> of LIKE.
>> 
>> Item #1was resolved as CASSANDRA-12573.
>> 
>> Regarding to item #2: you said the following:
>>> A possible fix would be:
>>> 
>>> 1) convert the bytebuffer into plain String (UTF8 or ASCII, depending on 
>>> the column data type)
>>> 2) remove the escape character e.g. before parsing OR use some advanced 
>>> regex to exclude the %% from parsing e.g
>>> 
>>> Step 2) is dead easy but step 1) is harder because I don't know if 
>>> converting the bytebuffer into String at this stage of the CQL parser is 
>>> expensive or not (in term of computation)
>>> 
>>> Let me try a patch 
>> 
>> So is there any update on this?
>> 
>> Thanks,
>> Mikhail
>> 
>> 
>>> On 20 Sep 2016, at 18:38, Mikhail Krupitskiy 
>>> >> > wrote:
>>> 
>>> Hi!
>>> 
>>> Have you had a chance to try your patch or solve the issue in an other way? 
>>> 
>>> Thanks,
>>> Mikhail
 On 15 Sep 2016, at 16:02, DuyHai Doan >>> > wrote:
 
 Ok so I've found the source of the issue, it's pretty well hidden because 
 it is NOT in the SASI source code directly.
 
 Here is the method where C* determines what kind of LIKE expression you're 
 using (LIKE_PREFIX , LIKE CONTAINS or LIKE_MATCHES)
 
 https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/restrictions/SingleColumnRestriction.java#L733-L778
  
 
 
 As you can see, it's pretty simple, maybe too simple. Indeed, they forget 
 to remove escape character BEFORE doing the matching so if your search is 
 LIKE '%%esc%', the detected expression is LIKE_CONTAINS.
 
 A possible fix would be:
 
 1) convert the bytebuffer into plain String (UTF8 or ASCII, depending on 
 the column data type)
 2) remove the escape character e.g. before parsing OR use some advanced 
 regex to exclude the %% from parsing e.g
 
 Step 2) is dead easy but step 1) is harder because I don't know if 
 converting the bytebuffer into String at this stage of the CQL parser is 
 expensive or not (in term of computation)
 
 Let me try a patch  
 
 
 
 On Wed, Sep 14, 2016 at 9:42 AM, DuyHai Doan >>> > wrote:
 Ok you're right, I get your point
 
 LIKE '%%esc%' --> startWith('%esc')
 
 LIKE 'escape%%' -->  = 'escape%'
 
 What I strongly suspect is that in the source code of SASI, we parse the % 
 xxx % expression BEFORE applying escape. That will explain the observed 
 behavior. E.g:
 
 LIKE '%%esc%'  parsed as %xxx% where xxx = %esc
 
 LIKE 'escape%%' parsed as xxx% where xxx =escape%
 
 Let me check in the source code and try to reproduce the issue
 
 
 
 On Tue, Sep 13, 2016 at 7:24 PM, Mikhail Krupitskiy 
 >>> > wrote:
 Looks like we have different understanding of what results are expected.
 I based my understanding on 
 http://docs.datastax.com/en/cql/3.3/cql/cql_using/useSASIIndex.html 
 
 According to the doc ‘esc’ is a pattern for exact match and I guess th

Re: Nodetool rebuild exception on c*-2.0.17

[Yabin Meng]

Hi,

>From "nodetool status" output, it looks like the cluster is running ok. The
exception itself simply says that data streaming fails during nodetool
rebuild. This could be due to possible network hiccup. It is hard to say.

You need to do further investigation. For example, you can run "nodetool
netstats" and check log file on the target node to get more information
about the failed streaming sessions, such as the source nodes of the failed
streaming sessions and then check the log files on those nodes.

Yabin

On Thu, Sep 22, 2016 at 4:57 PM, laxmikanth sadula 
wrote:

> Hi,
>
> We have c* 2.0.17 cluster with 2 DCs - DC1, DC2.  We tried to add new data
> center DC3 and ran "nodetool rebuild 'DC1'" and we faced below exception on
> few nodes after some data got streamed to new nodes in new data center DC3.
>
>
> *Exception in thread "main" java.lang.RuntimeException: Error while
> rebuilding node: Stream failed*
> *at
> org.apache.cassandra.service.StorageService.rebuild(StorageService.java:936)*
> *at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)*
> *at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)*
> *at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)*
> *at java.lang.reflect.Method.invoke(Method.java:606)*
> *at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)*
> *at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)*
> *at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)*
> *at java.lang.reflect.Method.invoke(Method.java:606)*
> *at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)*
> *at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)*
> *at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)*
> *at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)*
> *at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)*
> *at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)*
> *at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)*
> *at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)*
> *at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)*
> *at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)*
> *at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)*
> *at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)*
> *at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)*
> *at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)*
> *at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)*
> *at java.lang.reflect.Method.invoke(Method.java:606)*
> *at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)*
> *at sun.rmi.transport.Transport$2.run(Transport.java:202)*
> *at sun.rmi.transport.Transport$2.run(Transport.java:199)*
> *at java.security.AccessController.doPrivileged(Native Method)*
> *at sun.rmi.transport.Transport.serviceCall(Transport.java:198)*
> *at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:567)*
> *at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)*
> *at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.access$400(TCPTransport.java:619)*
> *at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:684)*
> *at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:681)*
> *at java.security.AccessController.doPrivileged(Native Method)*
> *at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:681)*
> *at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)*
> *at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)*
> *at java.lang.Thread.run(Thread.java:745)*
>
>
> We  have 4  user keyspaces , so we altered all keyspaces as below before
> issuing rebuild.
>
> *ALTER KEYSPACE keyspace_name WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC1': '3' , 'DC2' : '3' , 'DC3' : '3'};*
>
>
> *Output of describecluster*
>
> ./nodetool describecluster
> Cluster Information:
> Name: Ss Cluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> 3b688e54-47be-39e8-ae45-e71ba98d69e2: [xxx.xxx.198.75, xxx.xxx.198.132,
> xxx.xxx.198.133, xxx.xxx.12.115, xxx.xxx.198.78, xxx.xxx.12.123,
> xxx.xxx.98.205, xxx.xxx.98.219, xxx.xxx.98.220, xxx.xxx.198.167,
> xxx.xxx.98.172, xxx.xxx.98.173, xxx.xxx.98.170, xxx.xxx.198.168,
> xxx.xxx.98.171, xxx.xxx.198.169, xxx.xxx.12.146, xxx.xxx.98.168,
> xxx.xxx.12.14

Re: Upgrading from Cassandra 2.1.12 to 3.0.9

[Joaquin Casares]

Hello Razi,

Since you were using a highly stable version of 2.1.x, you may want to
stick with using 3.0.9. 3.7 has introduced many great features, but has not
been as heavily tested in production as 3.0.9.

Running heterogenous clusters, even when using the same major version (e.g.
3.0.8 and 3.0.9), is never recommended. Running a cluster that spans major
releases, for longer than the timespan of a routine upgrade, is strongly
not advised.

Hope that helps!

Joaquin Casares
Consultant
Austin, TX

Apache Cassandra Consulting
http://www.thelastpickle.com

On Fri, Sep 23, 2016 at 8:17 AM, Khaja, Raziuddin (NIH/NLM/NCBI) [C] <
raziuddin.kh...@nih.gov> wrote:

> Hello all,
>
>
>
> I would like to upgrade my Cassandra cluster from 2.1.12 to 3.7.
>
>
>
> I have read the following documentation:
>
> · http://docs.datastax.com/en/latest-upgrade/upgrade/
> cassandra/upgrdCassandra.html
>
> · https://github.com/apache/cassandra/blob/cassandra-3.7/NEWS.txt
>
>
>
> but still had some questions:
>
> · The upgrdCassandra.html page says : “Upgrade from Cassandra 2.1
> versions later or equal to 2.1.9 directly to Cassandra 3.0.x”, and I am not
> sure if this includes 3.x, my question is: Can I upgrade directly to 3.7?
>
> · Can I run a heterogeneous cluster, with one DC running 2.1.12
> and another DC running 3.7?
>
>
>
> Thanks,
>
> -Razi
>

Re: Upgrading from Cassandra 2.1.12 to 3.0.9

[Jonathan Haddad]

I strongly recommend not upgrading to 3.7.  Here's my thoughts on Tick Tock
releases, copy / pasted from a previous email I wrote on this ML:

3.7 falls under the Tick Tock release cycle, which is almost completely
untested in production by experienced operators.  In the cases where it has
been tested, there have been numerous bugs found which I (and I think most
people on this list) consider to be show stoppers.  Additionally, the Tick
Tock release cycle puts the operator in the uncomfortable position of
having to decide between upgrading to a new version with new features
(probably new bugs) or back porting bug fixes from future versions
themselves.There will never be a 3.7.1 release which fixes bugs in 3.7
without adding new features.

https://github.com/apache/cassandra/blob/trunk/NEWS.txt

For new projects I recommend starting with the recently released 3.0.9.

Assuming the project changes it's policy on releases (all signs point to
yes), then by the time 4.0 rolls out a lot of the features which have been
released in the 3.x series will have matured a bit, so it's very possible
4.0 will stabilize faster than the usual 6 months it takes for a major
release.

All that said, there's nothing wrong with doing compatibility & smoke tests
against the latest 3.x release as well as 3.0 and reporting bugs back to
the Apache Cassandra JIRA, I'm sure it would be greatly appreciated.

https://issues.apache.org/jira/secure/Dashboard.jspa

Jon



On Fri, Sep 23, 2016 at 9:00 AM Khaja, Raziuddin (NIH/NLM/NCBI) [C] <
raziuddin.kh...@nih.gov> wrote:

> Thank you Joaquim for the advice.
>
>
>
> I seem to have sent this email with the wrong subject.  It should have
> been *Upgrading from Cassandra 2.1.12 to 3.7*, but too late now.
>
>
>
> The plan is to upgrade from 2.1.12 to 3.7 and to maintain a heterogeneous
> cluster only for a short time, while we observe how 3.7 reacts to our
> client applications with traffic, then proceed with upgrading all DCs to
> 3.7.
>
>
>
> In our current installation we are using *memtable_allocation_type:
> offheap_objects*. Support for offheap_objects was removed in the 3.0.x
> branch and only added back in 3.4+, so an upgrade to 3.0.9 will not be
> possible for me unless I change this parameter.
>
> Still looking to hear from others about upgrade experiences, problems etc.
>
> -Razi
>
>
>
> *From: *Joaquin Casares 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Friday, September 23, 2016 at 11:41 AM
> *To: *"user@cassandra.apache.org" 
> *Cc: *"Khaja, Raziuddin (NIH/NLM/NCBI) [C]" 
> *Subject: *Re: Upgrading from Cassandra 2.1.12 to 3.0.9
>
>
>
> Hello Razi,
>
>
>
> Since you were using a highly stable version of 2.1.x, you may want to
> stick with using 3.0.9. 3.7 has introduced many great features, but has not
> been as heavily tested in production as 3.0.9.
>
>
>
> Running heterogenous clusters, even when using the same major version
> (e.g. 3.0.8 and 3.0.9), is never recommended. Running a cluster that spans
> major releases, for longer than the timespan of a routine upgrade, is
> strongly not advised.
>
>
>
> Hope that helps!
>
>
> Joaquin Casares
>
> Consultant
>
> Austin, TX
>
>
>
> Apache Cassandra Consulting
>
> http://www.thelastpickle.com
>
>
>
> On Fri, Sep 23, 2016 at 8:17 AM, Khaja, Raziuddin (NIH/NLM/NCBI) [C] <
> raziuddin.kh...@nih.gov> wrote:
>
> Hello all,
>
>
>
> I would like to upgrade my Cassandra cluster from 2.1.12 to 3.7.
>
>
>
> I have read the following documentation:
>
> ·
> http://docs.datastax.com/en/latest-upgrade/upgrade/cassandra/upgrdCassandra.html
>
> · https://github.com/apache/cassandra/blob/cassandra-3.7/NEWS.txt
>
>
>
> but still had some questions:
>
> · The upgrdCassandra.html page says : “Upgrade from Cassandra 2.1
> versions later or equal to 2.1.9 directly to Cassandra 3.0.x”, and I am not
> sure if this includes 3.x, my question is: Can I upgrade directly to 3.7?
>
> · Can I run a heterogeneous cluster, with one DC running 2.1.12
> and another DC running 3.7?
>
>
>
> Thanks,
>
> -Razi
>
>
>

Re: Upgrading from Cassandra 2.1.12 to 3.0.9

[Khaja, Raziuddin (NIH/NLM/NCBI) [C]]

Thank you Joaquim for the advice.

I seem to have sent this email with the wrong subject.  It should have been 
Upgrading from Cassandra 2.1.12 to 3.7, but too late now.

The plan is to upgrade from 2.1.12 to 3.7 and to maintain a heterogeneous 
cluster only for a short time, while we observe how 3.7 reacts to our client 
applications with traffic, then proceed with upgrading all DCs to 3.7.

In our current installation we are using memtable_allocation_type: 
offheap_objects. Support for offheap_objects was removed in the 3.0.x branch 
and only added back in 3.4+, so an upgrade to 3.0.9 will not be possible for me 
unless I change this parameter.
Still looking to hear from others about upgrade experiences, problems etc.
-Razi

From: Joaquin Casares 
Reply-To: "user@cassandra.apache.org" 
Date: Friday, September 23, 2016 at 11:41 AM
To: "user@cassandra.apache.org" 
Cc: "Khaja, Raziuddin (NIH/NLM/NCBI) [C]" 
Subject: Re: Upgrading from Cassandra 2.1.12 to 3.0.9

Hello Razi,

Since you were using a highly stable version of 2.1.x, you may want to stick 
with using 3.0.9. 3.7 has introduced many great features, but has not been as 
heavily tested in production as 3.0.9.

Running heterogenous clusters, even when using the same major version (e.g. 
3.0.8 and 3.0.9), is never recommended. Running a cluster that spans major 
releases, for longer than the timespan of a routine upgrade, is strongly not 
advised.

Hope that helps!

Joaquin Casares
Consultant
Austin, TX

Apache Cassandra Consulting
http://www.thelastpickle.com

On Fri, Sep 23, 2016 at 8:17 AM, Khaja, Raziuddin (NIH/NLM/NCBI) [C] 
mailto:raziuddin.kh...@nih.gov>> wrote:
Hello all,

I would like to upgrade my Cassandra cluster from 2.1.12 to 3.7.

I have read the following documentation:

• 
http://docs.datastax.com/en/latest-upgrade/upgrade/cassandra/upgrdCassandra.html

• https://github.com/apache/cassandra/blob/cassandra-3.7/NEWS.txt

but still had some questions:

• The upgrdCassandra.html page says : “Upgrade from Cassandra 2.1 
versions later or equal to 2.1.9 directly to Cassandra 3.0.x”, and I am not 
sure if this includes 3.x, my question is: Can I upgrade directly to 3.7?

• Can I run a heterogeneous cluster, with one DC running 2.1.12 and 
another DC running 3.7?

Thanks,
-Razi

Re: Upgrading from Cassandra 2.1.12 to 3.0.9

[SmartCat - Scott Hirleman]

I think the TLP team are recommending the approach I would as well, which
is to spin up a new cluster and copy your data into it for testing
purposes. If your app isn't in production yet, playing around with 3.7 is
great, really helps the community as Jon said; the word "upgrading" will
set off many alarm bells because the connotation is you have a stable
application built and are looking to put it on pretty bleeding edge tech
that hasn't been well tested yet, which is usually a road to tears.

On Fri, Sep 23, 2016 at 10:28 AM, Jonathan Haddad  wrote:

> I strongly recommend not upgrading to 3.7.  Here's my thoughts on Tick
> Tock releases, copy / pasted from a previous email I wrote on this ML:
>
> 3.7 falls under the Tick Tock release cycle, which is almost completely
> untested in production by experienced operators.  In the cases where it has
> been tested, there have been numerous bugs found which I (and I think most
> people on this list) consider to be show stoppers.  Additionally, the Tick
> Tock release cycle puts the operator in the uncomfortable position of
> having to decide between upgrading to a new version with new features
> (probably new bugs) or back porting bug fixes from future versions
> themselves.There will never be a 3.7.1 release which fixes bugs in 3.7
> without adding new features.
>
> https://github.com/apache/cassandra/blob/trunk/NEWS.txt
>
> For new projects I recommend starting with the recently released 3.0.9.
>
> Assuming the project changes it's policy on releases (all signs point to
> yes), then by the time 4.0 rolls out a lot of the features which have been
> released in the 3.x series will have matured a bit, so it's very possible
> 4.0 will stabilize faster than the usual 6 months it takes for a major
> release.
>
> All that said, there's nothing wrong with doing compatibility & smoke tests
> against the latest 3.x release as well as 3.0 and reporting bugs back to
> the Apache Cassandra JIRA, I'm sure it would be greatly appreciated.
>
> https://issues.apache.org/jira/secure/Dashboard.jspa
>
> Jon
>
>
>
> On Fri, Sep 23, 2016 at 9:00 AM Khaja, Raziuddin (NIH/NLM/NCBI) [C] <
> raziuddin.kh...@nih.gov> wrote:
>
>> Thank you Joaquim for the advice.
>>
>>
>>
>> I seem to have sent this email with the wrong subject.  It should have
>> been *Upgrading from Cassandra 2.1.12 to 3.7*, but too late now.
>>
>>
>>
>> The plan is to upgrade from 2.1.12 to 3.7 and to maintain a heterogeneous
>> cluster only for a short time, while we observe how 3.7 reacts to our
>> client applications with traffic, then proceed with upgrading all DCs to
>> 3.7.
>>
>>
>>
>> In our current installation we are using *memtable_allocation_type:
>> offheap_objects*. Support for offheap_objects was removed in the 3.0.x
>> branch and only added back in 3.4+, so an upgrade to 3.0.9 will not be
>> possible for me unless I change this parameter.
>>
>> Still looking to hear from others about upgrade experiences, problems etc.
>>
>> -Razi
>>
>>
>>
>> *From: *Joaquin Casares 
>> *Reply-To: *"user@cassandra.apache.org" 
>> *Date: *Friday, September 23, 2016 at 11:41 AM
>> *To: *"user@cassandra.apache.org" 
>> *Cc: *"Khaja, Raziuddin (NIH/NLM/NCBI) [C]" 
>> *Subject: *Re: Upgrading from Cassandra 2.1.12 to 3.0.9
>>
>>
>>
>> Hello Razi,
>>
>>
>>
>> Since you were using a highly stable version of 2.1.x, you may want to
>> stick with using 3.0.9. 3.7 has introduced many great features, but has not
>> been as heavily tested in production as 3.0.9.
>>
>>
>>
>> Running heterogenous clusters, even when using the same major version
>> (e.g. 3.0.8 and 3.0.9), is never recommended. Running a cluster that spans
>> major releases, for longer than the timespan of a routine upgrade, is
>> strongly not advised.
>>
>>
>>
>> Hope that helps!
>>
>>
>> Joaquin Casares
>>
>> Consultant
>>
>> Austin, TX
>>
>>
>>
>> Apache Cassandra Consulting
>>
>> http://www.thelastpickle.com
>>
>>
>>
>> On Fri, Sep 23, 2016 at 8:17 AM, Khaja, Raziuddin (NIH/NLM/NCBI) [C] <
>> raziuddin.kh...@nih.gov> wrote:
>>
>> Hello all,
>>
>>
>>
>> I would like to upgrade my Cassandra cluster from 2.1.12 to 3.7.
>>
>>
>>
>> I have read the following documentation:
>>
>> · http://docs.datastax.com/en/latest-upgrade/upgrade/
>> cassandra/upgrdCassandra.html
>>
>> · https://github.com/apache/cassandra/blob/cassandra-3.7/NEWS.txt
>>
>>
>>
>> but still had some questions:
>>
>> · The upgrdCassandra.html page says : “Upgrade from Cassandra
>> 2.1 versions later or equal to 2.1.9 directly to Cassandra 3.0.x”, and I am
>> not sure if this includes 3.x, my question is: Can I upgrade directly to
>> 3.7?
>>
>> · Can I run a heterogeneous cluster, with one DC running 2.1.12
>> and another DC running 3.7?
>>
>>
>>
>> Thanks,
>>
>> -Razi
>>
>>
>>
>


-- 
*Scott Hirleman*
*Head of US Marketing and Sales*
www.smartcat.io
https://github.com/smartcat-labs 

Re: Upgrading from Cassandra 2.1.12 to 3.0.9

[Jonathan Haddad]

Oh yeah, and to the second question, can you run a cluster with mixed
versions, the answer is absolutely not in any sort of sane way.

On Fri, Sep 23, 2016 at 10:01 AM SmartCat - Scott Hirleman <
sc...@smartcat.io> wrote:

> I think the TLP team are recommending the approach I would as well, which
> is to spin up a new cluster and copy your data into it for testing
> purposes. If your app isn't in production yet, playing around with 3.7 is
> great, really helps the community as Jon said; the word "upgrading" will
> set off many alarm bells because the connotation is you have a stable
> application built and are looking to put it on pretty bleeding edge tech
> that hasn't been well tested yet, which is usually a road to tears.
>
> On Fri, Sep 23, 2016 at 10:28 AM, Jonathan Haddad 
> wrote:
>
>> I strongly recommend not upgrading to 3.7.  Here's my thoughts on Tick
>> Tock releases, copy / pasted from a previous email I wrote on this ML:
>>
>> 3.7 falls under the Tick Tock release cycle, which is almost completely
>> untested in production by experienced operators.  In the cases where it
>> has
>> been tested, there have been numerous bugs found which I (and I think most
>> people on this list) consider to be show stoppers.  Additionally, the Tick
>> Tock release cycle puts the operator in the uncomfortable position of
>> having to decide between upgrading to a new version with new features
>> (probably new bugs) or back porting bug fixes from future versions
>> themselves.There will never be a 3.7.1 release which fixes bugs in 3.7
>> without adding new features.
>>
>> https://github.com/apache/cassandra/blob/trunk/NEWS.txt
>>
>> For new projects I recommend starting with the recently released 3.0.9.
>>
>> Assuming the project changes it's policy on releases (all signs point to
>> yes), then by the time 4.0 rolls out a lot of the features which have been
>> released in the 3.x series will have matured a bit, so it's very possible
>> 4.0 will stabilize faster than the usual 6 months it takes for a major
>> release.
>>
>> All that said, there's nothing wrong with doing compatibility & smoke
>> tests
>> against the latest 3.x release as well as 3.0 and reporting bugs back to
>> the Apache Cassandra JIRA, I'm sure it would be greatly appreciated.
>>
>> https://issues.apache.org/jira/secure/Dashboard.jspa
>>
>> Jon
>>
>>
>>
>> On Fri, Sep 23, 2016 at 9:00 AM Khaja, Raziuddin (NIH/NLM/NCBI) [C] <
>> raziuddin.kh...@nih.gov> wrote:
>>
>>> Thank you Joaquim for the advice.
>>>
>>>
>>>
>>> I seem to have sent this email with the wrong subject.  It should have
>>> been *Upgrading from Cassandra 2.1.12 to 3.7*, but too late now.
>>>
>>>
>>>
>>> The plan is to upgrade from 2.1.12 to 3.7 and to maintain a
>>> heterogeneous cluster only for a short time, while we observe how 3.7
>>> reacts to our client applications with traffic, then proceed with upgrading
>>> all DCs to 3.7.
>>>
>>>
>>>
>>> In our current installation we are using *memtable_allocation_type:
>>> offheap_objects*. Support for offheap_objects was removed in the 3.0.x
>>> branch and only added back in 3.4+, so an upgrade to 3.0.9 will not be
>>> possible for me unless I change this parameter.
>>>
>>> Still looking to hear from others about upgrade experiences, problems
>>> etc.
>>>
>>> -Razi
>>>
>>>
>>>
>>> *From: *Joaquin Casares 
>>> *Reply-To: *"user@cassandra.apache.org" 
>>> *Date: *Friday, September 23, 2016 at 11:41 AM
>>> *To: *"user@cassandra.apache.org" 
>>> *Cc: *"Khaja, Raziuddin (NIH/NLM/NCBI) [C]" 
>>> *Subject: *Re: Upgrading from Cassandra 2.1.12 to 3.0.9
>>>
>>>
>>>
>>> Hello Razi,
>>>
>>>
>>>
>>> Since you were using a highly stable version of 2.1.x, you may want to
>>> stick with using 3.0.9. 3.7 has introduced many great features, but has not
>>> been as heavily tested in production as 3.0.9.
>>>
>>>
>>>
>>> Running heterogenous clusters, even when using the same major version
>>> (e.g. 3.0.8 and 3.0.9), is never recommended. Running a cluster that spans
>>> major releases, for longer than the timespan of a routine upgrade, is
>>> strongly not advised.
>>>
>>>
>>>
>>> Hope that helps!
>>>
>>>
>>> Joaquin Casares
>>>
>>> Consultant
>>>
>>> Austin, TX
>>>
>>>
>>>
>>> Apache Cassandra Consulting
>>>
>>> http://www.thelastpickle.com
>>>
>>>
>>>
>>> On Fri, Sep 23, 2016 at 8:17 AM, Khaja, Raziuddin (NIH/NLM/NCBI) [C] <
>>> raziuddin.kh...@nih.gov> wrote:
>>>
>>> Hello all,
>>>
>>>
>>>
>>> I would like to upgrade my Cassandra cluster from 2.1.12 to 3.7.
>>>
>>>
>>>
>>> I have read the following documentation:
>>>
>>> ·
>>> http://docs.datastax.com/en/latest-upgrade/upgrade/cassandra/upgrdCassandra.html
>>>
>>> ·
>>> https://github.com/apache/cassandra/blob/cassandra-3.7/NEWS.txt
>>>
>>>
>>>
>>> but still had some questions:
>>>
>>> · The upgrdCassandra.html page says : “Upgrade from Cassandra
>>> 2.1 versions later or equal to 2.1.9 directly to Cassandra 3.0.x”, and I am
>>> not sure if this includes 3.x, my question is: Can I upgr

Re: Upgrading from Cassandra 2.1.12 to 3.0.9

[Edward Capriolo]

To me clear about the mixed versions. You do not want to do it. Especially
if the versions are very far apart.

Typically you can not run repair in mixed versions.
You can not do schema changes with mixed versions.
Data files from new versions are not readable from old versions.

Basically you only want to have mixed versions while you are doing an
upgrade. You want to finish the update across all nodes quickly (without
rushing).




On Fri, Sep 23, 2016 at 1:22 PM, Jonathan Haddad  wrote:

> Oh yeah, and to the second question, can you run a cluster with mixed
> versions, the answer is absolutely not in any sort of sane way.
>
> On Fri, Sep 23, 2016 at 10:01 AM SmartCat - Scott Hirleman <
> sc...@smartcat.io> wrote:
>
>> I think the TLP team are recommending the approach I would as well, which
>> is to spin up a new cluster and copy your data into it for testing
>> purposes. If your app isn't in production yet, playing around with 3.7 is
>> great, really helps the community as Jon said; the word "upgrading" will
>> set off many alarm bells because the connotation is you have a stable
>> application built and are looking to put it on pretty bleeding edge tech
>> that hasn't been well tested yet, which is usually a road to tears.
>>
>> On Fri, Sep 23, 2016 at 10:28 AM, Jonathan Haddad 
>> wrote:
>>
>>> I strongly recommend not upgrading to 3.7.  Here's my thoughts on Tick
>>> Tock releases, copy / pasted from a previous email I wrote on this ML:
>>>
>>> 3.7 falls under the Tick Tock release cycle, which is almost completely
>>> untested in production by experienced operators.  In the cases where it
>>> has
>>> been tested, there have been numerous bugs found which I (and I think
>>> most
>>> people on this list) consider to be show stoppers.  Additionally, the
>>> Tick
>>> Tock release cycle puts the operator in the uncomfortable position of
>>> having to decide between upgrading to a new version with new features
>>> (probably new bugs) or back porting bug fixes from future versions
>>> themselves.There will never be a 3.7.1 release which fixes bugs in
>>> 3.7
>>> without adding new features.
>>>
>>> https://github.com/apache/cassandra/blob/trunk/NEWS.txt
>>>
>>> For new projects I recommend starting with the recently released 3.0.9.
>>>
>>> Assuming the project changes it's policy on releases (all signs point to
>>> yes), then by the time 4.0 rolls out a lot of the features which have
>>> been
>>> released in the 3.x series will have matured a bit, so it's very possible
>>> 4.0 will stabilize faster than the usual 6 months it takes for a major
>>> release.
>>>
>>> All that said, there's nothing wrong with doing compatibility & smoke
>>> tests
>>> against the latest 3.x release as well as 3.0 and reporting bugs back to
>>> the Apache Cassandra JIRA, I'm sure it would be greatly appreciated.
>>>
>>> https://issues.apache.org/jira/secure/Dashboard.jspa
>>>
>>> Jon
>>>
>>>
>>>
>>> On Fri, Sep 23, 2016 at 9:00 AM Khaja, Raziuddin (NIH/NLM/NCBI) [C] <
>>> raziuddin.kh...@nih.gov> wrote:
>>>
 Thank you Joaquim for the advice.



 I seem to have sent this email with the wrong subject.  It should have
 been *Upgrading from Cassandra 2.1.12 to 3.7*, but too late now.



 The plan is to upgrade from 2.1.12 to 3.7 and to maintain a
 heterogeneous cluster only for a short time, while we observe how 3.7
 reacts to our client applications with traffic, then proceed with upgrading
 all DCs to 3.7.



 In our current installation we are using *memtable_allocation_type:
 offheap_objects*. Support for offheap_objects was removed in the 3.0.x
 branch and only added back in 3.4+, so an upgrade to 3.0.9 will not be
 possible for me unless I change this parameter.

 Still looking to hear from others about upgrade experiences, problems
 etc.

 -Razi



 *From: *Joaquin Casares 
 *Reply-To: *"user@cassandra.apache.org" 
 *Date: *Friday, September 23, 2016 at 11:41 AM
 *To: *"user@cassandra.apache.org" 
 *Cc: *"Khaja, Raziuddin (NIH/NLM/NCBI) [C]" 
 *Subject: *Re: Upgrading from Cassandra 2.1.12 to 3.0.9



 Hello Razi,



 Since you were using a highly stable version of 2.1.x, you may want to
 stick with using 3.0.9. 3.7 has introduced many great features, but has not
 been as heavily tested in production as 3.0.9.



 Running heterogenous clusters, even when using the same major version
 (e.g. 3.0.8 and 3.0.9), is never recommended. Running a cluster that spans
 major releases, for longer than the timespan of a routine upgrade, is
 strongly not advised.



 Hope that helps!


 Joaquin Casares

 Consultant

 Austin, TX



 Apache Cassandra Consulting

 http://www.thelastpickle.com



 On Fri, Sep 23, 2016 at 8:17 AM, Khaja, Raziuddin (NIH/NLM/

Lightweight tx is good enough to handle counter?

[Jaydeep Chovatia]

We have a following table:

create table mytable {

id int,
count int static,
rec_id int,
primary key (id, rec_id)

};

The count in the table represents how many records (rec_id clustering
columns) exists. So when we add new a new record we do it following way:

UNLOGGED BATCH
insert into mytable (id, rec_id) values (, );
update mytable set count =  + 1 where id =  if count =
; //light-weight transaction
APPLY BATCH

Then we do following read query as QUORUM:

select count, rec_id from mytable where id = ;

Here we expect count to exactly match number of rows (number of clustering
rec_id) returned. But under a stress we have observed that they do not
match sometimes.

Is this expected?

Thanks,
Jaydeep

Re: Lightweight tx is good enough to handle counter?

[DuyHai Doan]

Lightweight transaction is not available for counters, for the simple
reason that counters are not idempotent

On Fri, Sep 23, 2016 at 8:10 PM, Jaydeep Chovatia <
chovatia.jayd...@gmail.com> wrote:

> We have a following table:
>
> create table mytable {
>
> id int,
> count int static,
> rec_id int,
> primary key (id, rec_id)
>
> };
>
> The count in the table represents how many records (rec_id clustering
> columns) exists. So when we add new a new record we do it following way:
>
> UNLOGGED BATCH
> insert into mytable (id, rec_id) values (, );
> update mytable set count =  + 1 where id =  if count =
> ; //light-weight transaction
> APPLY BATCH
>
> Then we do following read query as QUORUM:
>
> select count, rec_id from mytable where id = ;
>
> Here we expect count to exactly match number of rows (number of clustering
> rec_id) returned. But under a stress we have observed that they do not
> match sometimes.
>
> Is this expected?
>
> Thanks,
> Jaydeep
>

Re: Lightweight tx is good enough to handle counter?

[Jaydeep Chovatia]

Ok.  But I am trying to understand a scenario under which this mis-match
can occur with light-weight tx.

On Fri, Sep 23, 2016 at 11:14 AM, DuyHai Doan  wrote:

> Lightweight transaction is not available for counters, for the simple
> reason that counters are not idempotent
>
> On Fri, Sep 23, 2016 at 8:10 PM, Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
>> We have a following table:
>>
>> create table mytable {
>>
>> id int,
>> count int static,
>> rec_id int,
>> primary key (id, rec_id)
>>
>> };
>>
>> The count in the table represents how many records (rec_id clustering
>> columns) exists. So when we add new a new record we do it following way:
>>
>> UNLOGGED BATCH
>> insert into mytable (id, rec_id) values (, );
>> update mytable set count =  + 1 where id =  if count =
>> ; //light-weight transaction
>> APPLY BATCH
>>
>> Then we do following read query as QUORUM:
>>
>> select count, rec_id from mytable where id = ;
>>
>> Here we expect count to exactly match number of rows (number of
>> clustering rec_id) returned. But under a stress we have observed that they
>> do not match sometimes.
>>
>> Is this expected?
>>
>> Thanks,
>> Jaydeep
>>
>
>

Re: Lightweight tx is good enough to handle counter?

[DuyHai Doan]

What is the consistency level used for the batch query ?


On Fri, Sep 23, 2016 at 8:19 PM, Jaydeep Chovatia <
chovatia.jayd...@gmail.com> wrote:

> Ok.  But I am trying to understand a scenario under which this mis-match
> can occur with light-weight tx.
>
> On Fri, Sep 23, 2016 at 11:14 AM, DuyHai Doan 
> wrote:
>
>> Lightweight transaction is not available for counters, for the simple
>> reason that counters are not idempotent
>>
>> On Fri, Sep 23, 2016 at 8:10 PM, Jaydeep Chovatia <
>> chovatia.jayd...@gmail.com> wrote:
>>
>>> We have a following table:
>>>
>>> create table mytable {
>>>
>>> id int,
>>> count int static,
>>> rec_id int,
>>> primary key (id, rec_id)
>>>
>>> };
>>>
>>> The count in the table represents how many records (rec_id clustering
>>> columns) exists. So when we add new a new record we do it following way:
>>>
>>> UNLOGGED BATCH
>>> insert into mytable (id, rec_id) values (, );
>>> update mytable set count =  + 1 where id =  if count =
>>> ; //light-weight transaction
>>> APPLY BATCH
>>>
>>> Then we do following read query as QUORUM:
>>>
>>> select count, rec_id from mytable where id = ;
>>>
>>> Here we expect count to exactly match number of rows (number of
>>> clustering rec_id) returned. But under a stress we have observed that they
>>> do not match sometimes.
>>>
>>> Is this expected?
>>>
>>> Thanks,
>>> Jaydeep
>>>
>>
>>
>

Re: Lightweight tx is good enough to handle counter?

[Jaydeep Chovatia]

Since SERIAL consistency is not supported for batch updates, I used QUORUM
for the operation.

On Fri, Sep 23, 2016 at 11:23 AM, DuyHai Doan  wrote:

> What is the consistency level used for the batch query ?
>
>
> On Fri, Sep 23, 2016 at 8:19 PM, Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
>> Ok.  But I am trying to understand a scenario under which this mis-match
>> can occur with light-weight tx.
>>
>> On Fri, Sep 23, 2016 at 11:14 AM, DuyHai Doan 
>> wrote:
>>
>>> Lightweight transaction is not available for counters, for the simple
>>> reason that counters are not idempotent
>>>
>>> On Fri, Sep 23, 2016 at 8:10 PM, Jaydeep Chovatia <
>>> chovatia.jayd...@gmail.com> wrote:
>>>
 We have a following table:

 create table mytable {

 id int,
 count int static,
 rec_id int,
 primary key (id, rec_id)

 };

 The count in the table represents how many records (rec_id clustering
 columns) exists. So when we add new a new record we do it following way:

 UNLOGGED BATCH
 insert into mytable (id, rec_id) values (, );
 update mytable set count =  + 1 where id =  if count =
 ; //light-weight transaction
 APPLY BATCH

 Then we do following read query as QUORUM:

 select count, rec_id from mytable where id = ;

 Here we expect count to exactly match number of rows (number of
 clustering rec_id) returned. But under a stress we have observed that they
 do not match sometimes.

 Is this expected?

 Thanks,
 Jaydeep

>>>
>>>
>>
>

Re: Lightweight tx is good enough to handle counter?

[Edward Capriolo]

This might help you:

https://github.com/edwardcapriolo/ec/blob/master/src/test/java/Base/CompareAndSwapTest.java

It counts using lwt's with multiple threads.

On Fri, Sep 23, 2016 at 2:31 PM, Jaydeep Chovatia <
chovatia.jayd...@gmail.com> wrote:

> Since SERIAL consistency is not supported for batch updates, I used QUORUM
> for the operation.
>
> On Fri, Sep 23, 2016 at 11:23 AM, DuyHai Doan 
> wrote:
>
>> What is the consistency level used for the batch query ?
>>
>>
>> On Fri, Sep 23, 2016 at 8:19 PM, Jaydeep Chovatia <
>> chovatia.jayd...@gmail.com> wrote:
>>
>>> Ok.  But I am trying to understand a scenario under which this mis-match
>>> can occur with light-weight tx.
>>>
>>> On Fri, Sep 23, 2016 at 11:14 AM, DuyHai Doan 
>>> wrote:
>>>
 Lightweight transaction is not available for counters, for the simple
 reason that counters are not idempotent

 On Fri, Sep 23, 2016 at 8:10 PM, Jaydeep Chovatia <
 chovatia.jayd...@gmail.com> wrote:

> We have a following table:
>
> create table mytable {
>
> id int,
> count int static,
> rec_id int,
> primary key (id, rec_id)
>
> };
>
> The count in the table represents how many records (rec_id clustering
> columns) exists. So when we add new a new record we do it following way:
>
> UNLOGGED BATCH
> insert into mytable (id, rec_id) values (, );
> update mytable set count =  + 1 where id =  if count =
> ; //light-weight transaction
> APPLY BATCH
>
> Then we do following read query as QUORUM:
>
> select count, rec_id from mytable where id = ;
>
> Here we expect count to exactly match number of rows (number of
> clustering rec_id) returned. But under a stress we have observed that they
> do not match sometimes.
>
> Is this expected?
>
> Thanks,
> Jaydeep
>


>>>
>>
>

Re: repair_history maintenance

[Chris Lohfink]

Probably should just periodically truncate/clear snapshots when gets too
big (will probably take months before noticeable). I opened
https://issues.apache.org/jira/browse/CASSANDRA-12701 for discussion on if
it should use TTLs

Chris

On Thu, Sep 22, 2016 at 1:28 PM, sfesc...@gmail.com 
wrote:

> Should there be a maintenance schedule for repair_history? Meaning, a
> scheduled nodetool repair and/or deletion schedule? Or is it the intention
> that this table just grow for the life of the cluster?
>

Re: repair_history maintenance

[sfesc...@gmail.com]

That sounds good to me. Unless there are objections I'll start doing that
on a scheduled bases.

Cheers

On Fri, Sep 23, 2016 at 11:55 AM Chris Lohfink  wrote:

> Probably should just periodically truncate/clear snapshots when gets too
> big (will probably take months before noticeable). I opened
> https://issues.apache.org/jira/browse/CASSANDRA-12701 for discussion on
> if it should use TTLs
>
> Chris
>
> On Thu, Sep 22, 2016 at 1:28 PM, sfesc...@gmail.com 
> wrote:
>
>> Should there be a maintenance schedule for repair_history? Meaning, a
>> scheduled nodetool repair and/or deletion schedule? Or is it the intention
>> that this table just grow for the life of the cluster?
>>
>
>