[jira] [Commented] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429593#comment-15429593
 ] 

Wei Deng commented on CASSANDRA-12512:
--

So the first problem with {{compaction-stress write}} was resolved by changing 
StressProfile code to avoid calling CFMetaData.compile(). However, the second 
problem goes deeper, as it is not trivial to replace CFMetaData.compile() used 
in SchemaKeyspace class.

[~krummas] Is it possible to avoid calling {{SystemKeyspace.finishStartup()}}?

> compaction-stress: assertion error on accessing Schema.instance from 
> client-mode tool
> -
>
> Key: CASSANDRA-12512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Wei Deng
>
> When I was trying the new compaction-stress tool from 3.10, I ran into the 
> following error:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.AssertionError: This assertion failure is probably due to accessing 
> Schema.instance from client-mode tools - See CASSANDRA-8143.
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
>   at 
> org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
>   at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
>   at 
> org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
>   at 
> org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
>   at 
> org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
>   at 
> org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
>   at 
> org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
> {noformat}
> [UPDATE] It appears that {{compaction-stress compact}} fails on the same 
> assert but via a totally different code path. The stack trace is like the 
> following:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress compact -d /tmp/compaction -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.cassandra.cql3.QueryProcessor$InternalStateInstance.(QueryProcessor.java:138)
>   at 
> org.apache.cassandra.cql3.QueryProcessor$InternalStateInstance.(QueryProcessor.java:132)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.internalQueryState(QueryProcessor.java:173)
>   at 
> org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:353)
>   at 
> org.apache.cassandra.schema.SchemaKeyspace.saveSystemKeyspacesSchema(SchemaKeyspace.java:263)
>   at 
> org.apache.cassandra.db.SystemKeyspace.finishStartup(SystemKeyspace.java:494)
>   at 
> org.apache.cassandra.stress.CompactionStress$Compaction.run(CompactionStress.java:213)
>   at 
> org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.cassandra.service.ClientState.(ClientState.java:73)
>   ... 8 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei Deng updated CASSANDRA-12512:
-
Description: 
When I was trying the new compaction-stress tool from 3.10, I ran into the 
following error:

{noformat}
automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
 -t 4
java.lang.AssertionError: This assertion failure is probably due to accessing 
Schema.instance from client-mode tools - See CASSANDRA-8143.
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
at 
org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
at 
org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
at 
org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
at 
org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
at 
org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
at 
org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
{noformat}

[UPDATE] It appears that {{compaction-stress compact}} fails on the same assert 
but via a totally different code path. The stack trace is like the following:

{noformat}
automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
./tools/bin/compaction-stress compact -d /tmp/compaction -p 
https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
 -t 4
java.lang.ExceptionInInitializerError
at 
org.apache.cassandra.cql3.QueryProcessor$InternalStateInstance.(QueryProcessor.java:138)
at 
org.apache.cassandra.cql3.QueryProcessor$InternalStateInstance.(QueryProcessor.java:132)
at 
org.apache.cassandra.cql3.QueryProcessor.internalQueryState(QueryProcessor.java:173)
at 
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:353)
at 
org.apache.cassandra.schema.SchemaKeyspace.saveSystemKeyspacesSchema(SchemaKeyspace.java:263)
at 
org.apache.cassandra.db.SystemKeyspace.finishStartup(SystemKeyspace.java:494)
at 
org.apache.cassandra.stress.CompactionStress$Compaction.run(CompactionStress.java:213)
at 
org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
Caused by: java.lang.NullPointerException
at 
org.apache.cassandra.service.ClientState.(ClientState.java:73)
... 8 more
{noformat}

  was:
When I was trying the new compaction-stress tool from 3.10, I ran into the 
following error:

{noformat}
automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
 -t 4
java.lang.AssertionError: This assertion failure is probably due to accessing 
Schema.instance from client-mode tools - See CASSANDRA-8143.
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
at 
org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
at 
org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
at 
org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
at 
org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
at 
org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
at 
org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
{noformat}



> compaction-stress: assertion error on accessing Schema.instance from 
> client-mode tool
> -
>
> Key: CASSANDRA-12512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Wei Deng
>
> When I was trying the new compaction-stress tool from 3.10, I ran into the 
> following error:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.AssertionError: This assertion failure is 

[jira] [Commented] (CASSANDRA-12329) Unreleased Resource: Sockets

[Arunkumar M (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429588#comment-15429588
 ] 

Arunkumar M commented on CASSANDRA-12329:
-

Yes, I have updated the patch.

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12329
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>Assignee: Arunkumar M
>  Labels: easyfix, newbie, patch
> Fix For: 3.0.x
>
> Attachments: 12329-3.0.txt
>
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> SSLFactory.java on line 62 a SSL server socket is acquired and eventually 
> returned to the caller on line 69.
> If an exception is thrown by any of the code between lines 62 and 69 the 
> socket acquired on line 62 will not be released for subsequent reuse..
> {code:java}
> SSLFactory.java, lines 59-70:
> 59 public static SSLServerSocket getServerSocket(EncryptionOptions options, 
> InetAddress address, int port) throws IOException
> 60 {
> 61 SSLContext ctx = createSSLContext(options, true);
> 62 SSLServerSocket serverSocket = 
> (SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
> 63 serverSocket.setReuseAddress(true);
> 64 String[] suites = 
> filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
> options.cipher_suites);
> 65 serverSocket.setEnabledCipherSuites(suites);
> 66 serverSocket.setNeedClientAuth(options.require_client_auth);
> 67 serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
> 68 serverSocket.bind(new InetSocketAddress(address, port), 500);
> 69 return serverSocket;
> 70 }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12329) Unreleased Resource: Sockets

[Arunkumar M (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arunkumar M updated CASSANDRA-12329:

Attachment: 12329-3.0.txt

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12329
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>Assignee: Arunkumar M
>  Labels: easyfix, newbie, patch
> Fix For: 3.0.x
>
> Attachments: 12329-3.0.txt
>
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> SSLFactory.java on line 62 a SSL server socket is acquired and eventually 
> returned to the caller on line 69.
> If an exception is thrown by any of the code between lines 62 and 69 the 
> socket acquired on line 62 will not be released for subsequent reuse..
> {code:java}
> SSLFactory.java, lines 59-70:
> 59 public static SSLServerSocket getServerSocket(EncryptionOptions options, 
> InetAddress address, int port) throws IOException
> 60 {
> 61 SSLContext ctx = createSSLContext(options, true);
> 62 SSLServerSocket serverSocket = 
> (SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
> 63 serverSocket.setReuseAddress(true);
> 64 String[] suites = 
> filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
> options.cipher_suites);
> 65 serverSocket.setEnabledCipherSuites(suites);
> 66 serverSocket.setNeedClientAuth(options.require_client_auth);
> 67 serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
> 68 serverSocket.bind(new InetSocketAddress(address, port), 500);
> 69 return serverSocket;
> 70 }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12329) Unreleased Resource: Sockets

[Arunkumar M (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arunkumar M updated CASSANDRA-12329:

Attachment: (was: 12329-3.0.txt)

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12329
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>Assignee: Arunkumar M
>  Labels: easyfix, newbie, patch
> Fix For: 3.0.x
>
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> SSLFactory.java on line 62 a SSL server socket is acquired and eventually 
> returned to the caller on line 69.
> If an exception is thrown by any of the code between lines 62 and 69 the 
> socket acquired on line 62 will not be released for subsequent reuse..
> {code:java}
> SSLFactory.java, lines 59-70:
> 59 public static SSLServerSocket getServerSocket(EncryptionOptions options, 
> InetAddress address, int port) throws IOException
> 60 {
> 61 SSLContext ctx = createSSLContext(options, true);
> 62 SSLServerSocket serverSocket = 
> (SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
> 63 serverSocket.setReuseAddress(true);
> 64 String[] suites = 
> filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
> options.cipher_suites);
> 65 serverSocket.setEnabledCipherSuites(suites);
> 66 serverSocket.setNeedClientAuth(options.require_client_auth);
> 67 serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
> 68 serverSocket.bind(new InetSocketAddress(address, port), 500);
> 69 return serverSocket;
> 70 }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11067) Improve SASI syntax

[Pavel Yaskevich (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429586#comment-15429586
 ] 

Pavel Yaskevich commented on CASSANDRA-11067:
-

Thanks for noticing that, [~dbrosius] and sorry for late response, I just got 
to this!.. [~ifesdjeen] Can you please include this as part of CASSANDRA-11990?

> Improve SASI syntax
> ---
>
> Key: CASSANDRA-11067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11067
> Project: Cassandra
>  Issue Type: Task
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Pavel Yaskevich
>  Labels: client-impacting, sasi
> Fix For: 3.4
>
>
> I think everyone agrees that a LIKE operator would be ideal, but that's 
> probably not in scope for an initial 3.4 release.
> Still, I'm uncomfortable with the initial approach of overloading = to mean 
> "satisfies index expression."  The problem is that it will be very difficult 
> to back out of this behavior once people are using it.
> I propose adding a new operator in the interim instead.  Call it MATCHES, 
> maybe.  With the exact same behavior that SASI currently exposes, just with a 
> separate operator rather than being rolled into =.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei Deng updated CASSANDRA-12512:
-
Comment: was deleted

(was: [~blambov] Do you know if there's a quick workaround for this problem? 
Thanks.)

> compaction-stress: assertion error on accessing Schema.instance from 
> client-mode tool
> -
>
> Key: CASSANDRA-12512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Wei Deng
>
> When I was trying the new compaction-stress tool from 3.10, I ran into the 
> following error:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.AssertionError: This assertion failure is probably due to accessing 
> Schema.instance from client-mode tools - See CASSANDRA-8143.
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
>   at 
> org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
>   at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
>   at 
> org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
>   at 
> org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
>   at 
> org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
>   at 
> org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
>   at 
> org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei Deng updated CASSANDRA-12512:
-
Description: 
When I was trying the new compaction-stress tool from 3.10, I ran into the 
following error:

{noformat}
automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
 -t 4
java.lang.AssertionError: This assertion failure is probably due to accessing 
Schema.instance from client-mode tools - See CASSANDRA-8143.
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
at 
org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
at 
org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
at 
org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
at 
org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
at 
org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
at 
org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
{noformat}


  was:
When I was trying the new compaction-stress tool from 3.10, I ran into the 
following error:

{noformat}
automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
 -t 4
java.lang.AssertionError: This assertion failure is probably due to accessing 
Schema.instance from client-mode tools - See CASSANDRA-8143.
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
at 
org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
at 
org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
at 
org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
at 
org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
at 
org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
at 
org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
{noformat}

Probably another code path not covered by CASSANDRA-8143? From the 
[comment|https://issues.apache.org/jira/browse/CASSANDRA-8143?focusedCommentId=14802787=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14802787]
 it appears that this should no longer happen after the patch and I confirmed 
the patch is in the code I'm using.

To be exact for reproduce, I'm building from trunk with this commit hash (Aug 
20, 2016): 
https://github.com/apache/cassandra/tree/7eb6b997f216d9971499d877bfc74489c9a46681


> compaction-stress: assertion error on accessing Schema.instance from 
> client-mode tool
> -
>
> Key: CASSANDRA-12512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Wei Deng
>
> When I was trying the new compaction-stress tool from 3.10, I ran into the 
> following error:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.AssertionError: This assertion failure is probably due to accessing 
> Schema.instance from client-mode tools - See CASSANDRA-8143.
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
>   at 
> org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
>   at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
>   at 
> org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
>   at 
> org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
>   at 
> org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
>   at 
> org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
>   at 
> org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
> 

[jira] [Commented] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429576#comment-15429576
 ] 

Wei Deng commented on CASSANDRA-12512:
--

Yep, after applying this 
[patch|https://issues.apache.org/jira/secure/attachment/12824146/0001-Replaced-using-CFMetaData.compile-in-cassandra-stres.patch],
 I was able to get compaction-stress to work.

To apply the patch cleanly, the additional import packages needed to be 
manually inserted but it was trivial.

> compaction-stress: assertion error on accessing Schema.instance from 
> client-mode tool
> -
>
> Key: CASSANDRA-12512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Wei Deng
>
> When I was trying the new compaction-stress tool from 3.10, I ran into the 
> following error:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.AssertionError: This assertion failure is probably due to accessing 
> Schema.instance from client-mode tools - See CASSANDRA-8143.
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
>   at 
> org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
>   at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
>   at 
> org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
>   at 
> org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
>   at 
> org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
>   at 
> org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
>   at 
> org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
> {noformat}
> Probably another code path not covered by CASSANDRA-8143? From the 
> [comment|https://issues.apache.org/jira/browse/CASSANDRA-8143?focusedCommentId=14802787=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14802787]
>  it appears that this should no longer happen after the patch and I confirmed 
> the patch is in the code I'm using.
> To be exact for reproduce, I'm building from trunk with this commit hash (Aug 
> 20, 2016): 
> https://github.com/apache/cassandra/tree/7eb6b997f216d9971499d877bfc74489c9a46681



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429575#comment-15429575
 ] 

Wei Deng commented on CASSANDRA-12512:
--

I think this is the same bug as discovered in CASSANDRA-12478, i.e. 
StressProfile is still using CFMetaData.compile().

I'm going to test the patch Denis provided in 12478 and report back if the 
problem is fixed.

> compaction-stress: assertion error on accessing Schema.instance from 
> client-mode tool
> -
>
> Key: CASSANDRA-12512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Wei Deng
>
> When I was trying the new compaction-stress tool from 3.10, I ran into the 
> following error:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.AssertionError: This assertion failure is probably due to accessing 
> Schema.instance from client-mode tools - See CASSANDRA-8143.
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
>   at 
> org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
>   at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
>   at 
> org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
>   at 
> org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
>   at 
> org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
>   at 
> org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
>   at 
> org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
> {noformat}
> Probably another code path not covered by CASSANDRA-8143? From the 
> [comment|https://issues.apache.org/jira/browse/CASSANDRA-8143?focusedCommentId=14802787=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14802787]
>  it appears that this should no longer happen after the patch and I confirmed 
> the patch is in the code I'm using.
> To be exact for reproduce, I'm building from trunk with this commit hash (Aug 
> 20, 2016): 
> https://github.com/apache/cassandra/tree/7eb6b997f216d9971499d877bfc74489c9a46681



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CASSANDRA-6216) Level Compaction should persist last compacted key per level

[Dikang Gu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dikang Gu reassigned CASSANDRA-6216:


Assignee: Dikang Gu

> Level Compaction should persist last compacted key per level
> 
>
> Key: CASSANDRA-6216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6216
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: sankalp kohli
>Assignee: Dikang Gu
>Priority: Minor
>  Labels: compaction, lcs
> Attachments: JIRA-6216.diff
>
>
> Level compaction does not persist the last compacted key per level. This is 
> important for higher levels. 
> The sstables with higher token and in higher levels wont get a chance to 
> compact as the last compacted key will get reset after a restart.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei Deng updated CASSANDRA-12512:
-
Description: 
When I was trying the new compaction-stress tool from 3.10, I ran into the 
following error:

{noformat}
automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
 -t 4
java.lang.AssertionError: This assertion failure is probably due to accessing 
Schema.instance from client-mode tools - See CASSANDRA-8143.
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
at 
org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
at 
org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
at 
org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
at 
org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
at 
org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
at 
org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
{noformat}

Probably another code path not covered by CASSANDRA-8143? From the 
[comment|https://issues.apache.org/jira/browse/CASSANDRA-8143?focusedCommentId=14802787=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14802787]
 it appears that this should no longer happen after the patch and I confirmed 
the patch is in the code I'm using.

To be exact for reproduce, I'm building from trunk with this commit hash (Aug 
20, 2016): 
https://github.com/apache/cassandra/tree/7eb6b997f216d9971499d877bfc74489c9a46681

  was:
When I was trying the new compaction-stress tool from 3.10, I ran into the 
following error:

{noformat}
automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
 -t 4
java.lang.AssertionError: This assertion failure is probably due to accessing 
Schema.instance from client-mode tools - See CASSANDRA-8143.
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
at 
org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
at 
org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
at 
org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
at 
org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
at 
org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
at 
org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
{noformat}

Probably another code path not covered by CASSANDRA-8143? From the 
[comment|https://issues.apache.org/jira/browse/CASSANDRA-8143?focusedCommentId=14802787=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14802787]
 it appears that this should no longer happen after the patch and I confirmed 
the patch is in the code I'm using.


> compaction-stress: assertion error on accessing Schema.instance from 
> client-mode tool
> -
>
> Key: CASSANDRA-12512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Wei Deng
>
> When I was trying the new compaction-stress tool from 3.10, I ran into the 
> following error:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.AssertionError: This assertion failure is probably due to accessing 
> Schema.instance from client-mode tools - See CASSANDRA-8143.
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
>   at 
> org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
>   at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
>   at 
> org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
>   at 
> 

[jira] [Commented] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429525#comment-15429525
 ] 

Wei Deng commented on CASSANDRA-12512:
--

[~blambov] Do you know if there's a quick workaround for this problem? Thanks.

> compaction-stress: assertion error on accessing Schema.instance from 
> client-mode tool
> -
>
> Key: CASSANDRA-12512
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Wei Deng
>
> When I was trying the new compaction-stress tool from 3.10, I ran into the 
> following error:
> {noformat}
> automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
> ./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
> https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
>  -t 4
> java.lang.AssertionError: This assertion failure is probably due to accessing 
> Schema.instance from client-mode tools - See CASSANDRA-8143.
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
>   at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
>   at 
> org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
>   at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
>   at 
> org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
>   at 
> org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
>   at 
> org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
>   at 
> org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
>   at 
> org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
> {noformat}
> Probably another code path not covered by CASSANDRA-8143? From the 
> [comment|https://issues.apache.org/jira/browse/CASSANDRA-8143?focusedCommentId=14802787=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14802787]
>  it appears that this should no longer happen after the patch and I confirmed 
> the patch is in the code I'm using.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12512) compaction-stress: assertion error on accessing Schema.instance from client-mode tool

[Wei Deng (JIRA)]

Wei Deng created CASSANDRA-12512:


 Summary: compaction-stress: assertion error on accessing 
Schema.instance from client-mode tool
 Key: CASSANDRA-12512
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12512
 Project: Cassandra
  Issue Type: Bug
Reporter: Wei Deng


When I was trying the new compaction-stress tool from 3.10, I ran into the 
following error:

{noformat}
automaton@wdengsummitsparkgoogle-0ce59d338-1:~/cassandra-trunk$ 
./tools/bin/compaction-stress write -d /tmp/compaction -g 5 -p 
https://gist.githubusercontent.com/tjake/8995058fed11d9921e31/raw/a9334d1090017bf546d003e271747351a40692ea/blogpost.yaml
 -t 4
java.lang.AssertionError: This assertion failure is probably due to accessing 
Schema.instance from client-mode tools - See CASSANDRA-8143.
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:288)
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:66)
at 
org.apache.cassandra.config.CFMetaData$Builder.build(CFMetaData.java:1332)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:433)
at 
org.apache.cassandra.stress.StressProfile.init(StressProfile.java:174)
at 
org.apache.cassandra.stress.StressProfile.load(StressProfile.java:801)
at 
org.apache.cassandra.stress.CompactionStress.getStressProfile(CompactionStress.java:162)
at 
org.apache.cassandra.stress.CompactionStress$DataWriter.run(CompactionStress.java:289)
at 
org.apache.cassandra.stress.CompactionStress.main(CompactionStress.java:353)
{noformat}

Probably another code path not covered by CASSANDRA-8143? From the 
[comment|https://issues.apache.org/jira/browse/CASSANDRA-8143?focusedCommentId=14802787=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14802787]
 it appears that this should no longer happen after the patch and I confirmed 
the patch is in the code I'm using.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11906) Unstable JVM due too many files when anticompacting big LCS tables

[Stefano Ortolani (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429513#comment-15429513
 ] 

Stefano Ortolani commented on CASSANDRA-11906:
--

Now that I think of it, it might be related to the fact that repairs are ran 
with the -pr option on each node sequentially.
Since the the repair command returns way before all anticompactions are done, 
the crashing node might do so because of anticompaction sessions induced by the 
repairs of more than one node.

> Unstable JVM due too many files when anticompacting big LCS tables
> --
>
> Key: CASSANDRA-11906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11906
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefano Ortolani
>Assignee: Sean McCarthy
> Fix For: 3.0.x
>
>
> I have recently moved from C* 2.1.x to C* 3.0.6. The setup is quite 
> heavy:
>   - 13 nodes with spinning disks
>   - ~120 GB of data per node
>   - 50% of CFs are LCS and have quite wide rows.
>   - 2/3 CFs with LCS have more than 200 SStables
> Incremental repairs do not seem to play really well with that.
> I have been running some tests node by node by using the -pr option:
> {code:xml}
> nodetool -h localhost repair -pr keyscheme
> {code}
> and to my surprise the whole process takes quite some time (1 hour
> minimum, 8 hours if I haven't been repairing for 5/6 days).
> Yesterday I tried to run the command with the -seq option so to 
> decrease the number of simultanoues compactions. After a while
> the node on which I was running the repair simply died during
> the anticompaction phase with the following
> exception in the logs.
> {code:xml}
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-25 21:54:21,868 
> ScheduledReporter.java:119 - RuntimeException thrown from 
> GraphiteReporter#report. Exception was suppressed.
> java.lang.RuntimeException: Failed to list files in 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:57)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:691)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.listFiles(Directories.java:662)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$TrueFilesSizeVisitor.(Directories.java:981)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.getTrueAllocatedSizeIn(Directories.java:893)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.trueSnapshotsSize(Directories.java:883) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.trueSnapshotsSize(ColumnFamilyStore.java:2332)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:637) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:634) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_91]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: java.lang.RuntimeException: java.nio.file.FileSystemException: 
> 

[jira] [Commented] (CASSANDRA-11906) Unstable JVM due too many files when anticompacting big LCS tables

[Stefano Ortolani (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429510#comment-15429510
 ] 

Stefano Ortolani commented on CASSANDRA-11906:
--

Ok, it happened again. A node crashed because of too many files open. 
This time even with parallel repairs.

> Unstable JVM due too many files when anticompacting big LCS tables
> --
>
> Key: CASSANDRA-11906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11906
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefano Ortolani
>Assignee: Sean McCarthy
> Fix For: 3.0.x
>
>
> I have recently moved from C* 2.1.x to C* 3.0.6. The setup is quite 
> heavy:
>   - 13 nodes with spinning disks
>   - ~120 GB of data per node
>   - 50% of CFs are LCS and have quite wide rows.
>   - 2/3 CFs with LCS have more than 200 SStables
> Incremental repairs do not seem to play really well with that.
> I have been running some tests node by node by using the -pr option:
> {code:xml}
> nodetool -h localhost repair -pr keyscheme
> {code}
> and to my surprise the whole process takes quite some time (1 hour
> minimum, 8 hours if I haven't been repairing for 5/6 days).
> Yesterday I tried to run the command with the -seq option so to 
> decrease the number of simultanoues compactions. After a while
> the node on which I was running the repair simply died during
> the anticompaction phase with the following
> exception in the logs.
> {code:xml}
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-25 21:54:21,868 
> ScheduledReporter.java:119 - RuntimeException thrown from 
> GraphiteReporter#report. Exception was suppressed.
> java.lang.RuntimeException: Failed to list files in 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:57)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:691)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.listFiles(Directories.java:662)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$TrueFilesSizeVisitor.(Directories.java:981)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.getTrueAllocatedSizeIn(Directories.java:893)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.trueSnapshotsSize(Directories.java:883) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.trueSnapshotsSize(ColumnFamilyStore.java:2332)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:637) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:634) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_91]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: java.lang.RuntimeException: java.nio.file.FileSystemException: 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396/ma_txn_anticompactionafterrepair_f20b50d0-22bd-11e6-970f-6f22464f4624.log:
>  Too many open files
>   at org.apache.cassandra.io.util.FileUtils.readLines(FileUtils.java:622) 
> 

[jira] [Created] (CASSANDRA-12511) Refactor Compaction Strategy to support generic SSTable component

[ZhaoYang (JIRA)]

ZhaoYang created CASSANDRA-12511:


 Summary: Refactor Compaction Strategy to support generic SSTable 
component
 Key: CASSANDRA-12511
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12511
 Project: Cassandra
  Issue Type: Improvement
  Components: Compaction
Reporter: ZhaoYang
Priority: Minor
 Fix For: 3.x


The compaction strategy should be plugable and IMO it's better to refactor 
Leveled CS to use generic type so that user can defined their own component in 
SSTable.(like the 'level' attribute)





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12154) "SELECT * FROM foo LIMIT ;" does not error out

[Robert Stupp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-12154:
-
Fix Version/s: 3.x

> "SELECT * FROM foo LIMIT ;" does not error out
> --
>
> Key: CASSANDRA-12154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12154
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Robert Stupp
>Assignee: Thomas Boucher
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
>
> We found out that {{SELECT * FROM foo LIMIT ;}} is unanimously accepted and 
> executed but it should not.
> Have not dug deeper why that is possible (it's not a big issue IMO) but it is 
> strange. Seems it doesn't parse {{LIMIT}} as {{K_LIMIT}} because otherwise it 
> would require an int argument.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CASSANDRA-11914) Provide option for cassandra-stress to dump all settings

[Robert Stupp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp reopened CASSANDRA-11914:
--

The trades workload test (e.g. {{cassandra-stress user 
profile=https://raw.githubusercontent.com/mambocab/cstar_perf/belliottsmith-perf-jobs/regression_suites/trades.yaml
 ops\(insert=100,latest=100,range=1\) n=100M -rate threads=300 -pop seq=1..10K 
contents=SORTED read-lookback=uniform\(1..10K\) -insert visits=fixed\(10K\) 
revisit=uniform\(1..10K\)}}) fails with this patch with the following NPE:
{code}
...
  Generator Configs:
millisecond: Clustering: Uniform:  min=50,max=200;
second: Clustering: Uniform:  min=50,max=200;
  Query Definitions:
latest: CQL:select * from trades where instrumentid = ? and day = ? ORDER 
BY second DESC, millisecond DESC LIMIT 1;Fields:samerow;
range: CQL:select * from trades where instrumentid = ? and day = ? and 
second > ? ORDER BY second DESC, millisecond DESC LIMIT 100;Fields:samerow;
  Token Range Queries:
  Insert Settings:
java.lang.NullPointerException
at 
org.apache.cassandra.stress.StressProfile.printSettings(StressProfile.java:116)
at 
org.apache.cassandra.stress.settings.StressSettings.printSettings(StressSettings.java:383)
at org.apache.cassandra.stress.Stress.run(Stress.java:95)
at org.apache.cassandra.stress.Stress.main(Stress.java:62)
{code}

Can be reproduced locally by starting Cassandra from trunk locally and running 
the stress profile above.

> Provide option for cassandra-stress to dump all settings
> 
>
> Key: CASSANDRA-11914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11914
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Ben Slater
>Assignee: Ben Slater
>Priority: Minor
> Fix For: 3.10
>
>
> cassandra-stress has quite a lot of default settings and settings that are 
> derived as side effects of explicit options. For people learning the tool and 
> saving a clear record of what was run, I think it would be useful if there 
> was an option to have the tool print all its settings at the start of a run.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12154) "SELECT * FROM foo LIMIT ;" does not error out

[Robert Stupp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-12154:
-
Assignee: Thomas Boucher  (was: Mahdi Mohammadi)

> "SELECT * FROM foo LIMIT ;" does not error out
> --
>
> Key: CASSANDRA-12154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12154
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Robert Stupp
>Assignee: Thomas Boucher
>Priority: Minor
>  Labels: lhf
>
> We found out that {{SELECT * FROM foo LIMIT ;}} is unanimously accepted and 
> executed but it should not.
> Have not dug deeper why that is possible (it's not a big issue IMO) but it is 
> strange. Seems it doesn't parse {{LIMIT}} as {{K_LIMIT}} because otherwise it 
> would require an int argument.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11052) Cannot use Java 8 lambda expression inside UDF code body

[Robert Stupp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-11052:
-
Reviewer:   (was: Robert Stupp)

> Cannot use Java 8 lambda expression inside UDF code body
> 
>
> Key: CASSANDRA-11052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11052
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: Robert Stupp
> Fix For: 3.x
>
> Attachments: 11052-2.patch, 11052.patch
>
>
> When creating the following **UDF** using Java 8 lambda syntax
> {code:sql}
>  CREATE FUNCTION IF NOT EXISTS music.udf(state map, styles 
> list)
>  RETURNS NULL ON NULL INPUT
>  RETURNS map
>  LANGUAGE java
>  AS $$
>styles.forEach((Object o) -> {
>String style = (String)o;
>if(state.containsKey(style)) {
> state.put(style, (Long)state.get(style)+1);
>} else {
> state.put(style, 1L);   
>}
>});
>
>return state;
>  $$;
> {code}
>  I got the following exception:
> {code:java}
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Could 
> not compile function 'music.udf' from Java source: 
> org.apache.cassandra.exceptions.InvalidRequestException: Java source 
> compilation failed:
> Line 2: The type java.util.function.Consumer cannot be resolved. It is 
> indirectly referenced from required .class files
> Line 2: The method forEach(Consumer) from the type Iterable refers to the 
> missing type Consumer
> Line 2: The target type of this expression must be a functional interface
>   at 
> com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
>   at 
> com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:179)
>   at 
> com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:184)
>   at 
> com.datastax.driver.core.RequestHandler.access$2500(RequestHandler.java:43)
>   at 
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.setFinalResult(RequestHandler.java:798)
>   at 
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.onSet(RequestHandler.java:617)
>   at 
> com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:1005)
>   at 
> com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:928)
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
>   at 
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:266)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
>   at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
>   at 
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:276)
>   at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:263)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
>   at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
>   at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
>   at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
>   ... 1 more
> {code}
>  It looks like the compiler requires importing java.util.Consumer but I have 
> checked the source code and compiler options already support Java 8 source 
> code so I'm pretty puzzled here ...
> /cc [~snazy]

[jira] [Comment Edited] (CASSANDRA-11906) Unstable JVM due too many files when anticompacting big LCS tables

[Stefano Ortolani (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429360#comment-15429360
 ] 

Stefano Ortolani edited comment on CASSANDRA-11906 at 8/20/16 12:40 PM:


How many SStables are created during AntiCompaction? With my current setup I 
have three CFs that spike to 700/800 on every node during repairs. This while 
doing parallel repairs. Sequential repairs push that number even higher.


was (Author: ostefano):
How many SStables are created during AntiCompaction? With my current setup I 
have three CFs that spike to 700/800 on every node during repairs.

> Unstable JVM due too many files when anticompacting big LCS tables
> --
>
> Key: CASSANDRA-11906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11906
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefano Ortolani
>Assignee: Sean McCarthy
> Fix For: 3.0.x
>
>
> I have recently moved from C* 2.1.x to C* 3.0.6. The setup is quite 
> heavy:
>   - 13 nodes with spinning disks
>   - ~120 GB of data per node
>   - 50% of CFs are LCS and have quite wide rows.
>   - 2/3 CFs with LCS have more than 200 SStables
> Incremental repairs do not seem to play really well with that.
> I have been running some tests node by node by using the -pr option:
> {code:xml}
> nodetool -h localhost repair -pr keyscheme
> {code}
> and to my surprise the whole process takes quite some time (1 hour
> minimum, 8 hours if I haven't been repairing for 5/6 days).
> Yesterday I tried to run the command with the -seq option so to 
> decrease the number of simultanoues compactions. After a while
> the node on which I was running the repair simply died during
> the anticompaction phase with the following
> exception in the logs.
> {code:xml}
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-25 21:54:21,868 
> ScheduledReporter.java:119 - RuntimeException thrown from 
> GraphiteReporter#report. Exception was suppressed.
> java.lang.RuntimeException: Failed to list files in 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:57)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:691)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.listFiles(Directories.java:662)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$TrueFilesSizeVisitor.(Directories.java:981)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.getTrueAllocatedSizeIn(Directories.java:893)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.trueSnapshotsSize(Directories.java:883) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.trueSnapshotsSize(ColumnFamilyStore.java:2332)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:637) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:634) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_91]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: 

[jira] [Commented] (CASSANDRA-11906) Unstable JVM due too many files when anticompacting big LCS tables

[Stefano Ortolani (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429360#comment-15429360
 ] 

Stefano Ortolani commented on CASSANDRA-11906:
--

How many SStables are created during AntiCompaction? With my current setup I 
have three CFs that spike to 700/800 on every node during repairs.

> Unstable JVM due too many files when anticompacting big LCS tables
> --
>
> Key: CASSANDRA-11906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11906
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefano Ortolani
>Assignee: Sean McCarthy
> Fix For: 3.0.x
>
>
> I have recently moved from C* 2.1.x to C* 3.0.6. The setup is quite 
> heavy:
>   - 13 nodes with spinning disks
>   - ~120 GB of data per node
>   - 50% of CFs are LCS and have quite wide rows.
>   - 2/3 CFs with LCS have more than 200 SStables
> Incremental repairs do not seem to play really well with that.
> I have been running some tests node by node by using the -pr option:
> {code:xml}
> nodetool -h localhost repair -pr keyscheme
> {code}
> and to my surprise the whole process takes quite some time (1 hour
> minimum, 8 hours if I haven't been repairing for 5/6 days).
> Yesterday I tried to run the command with the -seq option so to 
> decrease the number of simultanoues compactions. After a while
> the node on which I was running the repair simply died during
> the anticompaction phase with the following
> exception in the logs.
> {code:xml}
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-25 21:54:21,868 
> ScheduledReporter.java:119 - RuntimeException thrown from 
> GraphiteReporter#report. Exception was suppressed.
> java.lang.RuntimeException: Failed to list files in 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:57)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:691)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.listFiles(Directories.java:662)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$TrueFilesSizeVisitor.(Directories.java:981)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.getTrueAllocatedSizeIn(Directories.java:893)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.trueSnapshotsSize(Directories.java:883) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.trueSnapshotsSize(ColumnFamilyStore.java:2332)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:637) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:634) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_91]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: java.lang.RuntimeException: java.nio.file.FileSystemException: 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396/ma_txn_anticompactionafterrepair_f20b50d0-22bd-11e6-970f-6f22464f4624.log:
>  Too many open files
>   at 

[jira] [Commented] (CASSANDRA-10050) Secondary Index Performance Dependent on TokenRange Searched in Analytics

[Robert Stupp (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429358#comment-15429358
 ] 

Robert Stupp commented on CASSANDRA-10050:
--

As far as I understand this ticket, it would require at least a schema change. 
Changing the order of the keys would require that the token is encoded in the 
internal 2i tables. I.e. instead of _partition-key=index-value + 
clustering-key=base-primary-key_ it would be _partition-key=index-value + 
clustering-key=token-of-base-partition-key+base-primary-key_ ; also, "token" 
would depend on the partitioner. Quite irrelevant for BOP, but random and 
murmur3 partitioner would require the token to be included.
Not sure, whether the current implementation (i.e. returning the rows in key 
order) is something that people rely on. Means, would it be worth to add an 
option to internal 2i that says: _store in token order_?

> Secondary Index Performance Dependent on TokenRange Searched in Analytics
> -
>
> Key: CASSANDRA-10050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10050
> Project: Cassandra
>  Issue Type: Improvement
> Environment: Single node, macbook, 2.1.8
>Reporter: Russell Spitzer
> Fix For: 3.x
>
>
> In doing some test work on the Spark Cassandra Connector I saw some odd 
> performance when pushing down range queries with Secondary Index filters. 
> When running the queries we see huge amount of time when the C* server is not 
> doing any work and the query seem to be hanging. This investigation led to 
> the work in this document
> https://docs.google.com/spreadsheets/d/1aJg3KX7nPnY77RJ9ZT-IfaYADgJh0A--nAxItvC6hb4/edit#gid=0
> The Spark Cassandra Connector builds up token range specific queries and 
> allows the user to pushdown relevant fields to C*. Here we have two indexed 
> fields (size) and (color) being pushed down to C*. 
> {code}
> SELECT count(*) FROM ks.tab WHERE token("store") > $min AND token("store") <= 
> $max AND color = 'red' AND size = 'P' ALLOW FILTERING;{code}
> These queries will have different token ranges inserted and executed as 
> separate spark tasks. Spark tasks with token ranges near the Min(token) end 
> up executing much faster than those near Max(token) which also happen to 
> through errors.
> {code}
> Coordinator node timed out waiting for replica nodes' responses] 
> message="Operation timed out - received only 0 responses." 
> info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> I took the queries and ran them through CQLSH to see the difference in time. 
> A linear relationship is seen based on where the tokenRange being queried is 
> starting with only 2 second for queries near the beginning of the full token 
> spectrum and over 12 seconds at the end of the spectrum. 
> The question is, can this behavior be improved? or should we not recommend 
> using secondary indexes with Analytics workloads?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12199) Config class uses boxed types but DD exposes primitive types

[Robert Stupp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-12199:
-
Status: Patch Available  (was: Open)

Patch replacing boxed with primitive types available.
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12199-primitives-config-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12199-primitives-config-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12199-primitives-config-trunk-dtest/lastSuccessfulBuild/]


> Config class uses boxed types but DD exposes primitive types
> 
>
> Key: CASSANDRA-12199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12199
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
>
> {{Config}} class contains a lot of properties that are defined using boxed 
> types - ({{Config.dynamic_snitch_update_interval_in_ms}}) but the 
> corresponding get-methods in {{DatabaseDescriptor}} require them to be not 
> null. Means, setting such properties to {{null}} will lead to NPEs anyway.
> Proposal:
> * Identify all properties that use boxed values and have a default value 
> (e.g. {{public Integer rpc_port = 9160;}})
> * Refactor those to use primitive types



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12502) ColumnIndex does not reuse buffer

[Robert Stupp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-12502:
-
 Reviewer: Branimir Lambov
Fix Version/s: 3.x
   Status: Patch Available  (was: Open)

Ah - sorry for that. Target trunk or 3.8/3.9?

||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:12502-reuse-dob-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12502-reuse-dob-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-12502-reuse-dob-trunk-dtest/lastSuccessfulBuild/]


> ColumnIndex does not reuse buffer
> -
>
> Key: CASSANDRA-12502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12502
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Branimir Lambov
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.x
>
>
> {{ColumnIndex}} is supposed to be reusing its shallow entry buffer. Instead 
> it always allocates as {{buffer}} isn't returned [from 
> {{useBuffer}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnIndex.java#L227].
> Additionally, relying on caller to set {{buffer}} after the call is 
> error-prone.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cassandra git commit: Ninja, remove gen-thrift-java ant task from IntelliJ launch configs

[snazy]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 528204267 -> 7eb6b997f


Ninja, remove gen-thrift-java ant task from IntelliJ launch configs


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7eb6b997
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7eb6b997
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7eb6b997

Branch: refs/heads/trunk
Commit: 7eb6b997f216d9971499d877bfc74489c9a46681
Parents: 5282042
Author: Robert Stupp 
Authored: Sat Aug 20 21:55:56 2016 +1000
Committer: Robert Stupp 
Committed: Sat Aug 20 21:55:56 2016 +1000

--
 ide/idea/workspace.xml | 2 --
 1 file changed, 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7eb6b997/ide/idea/workspace.xml
--
diff --git a/ide/idea/workspace.xml b/ide/idea/workspace.xml
index 5e7a761..a8922ed 100644
--- a/ide/idea/workspace.xml
+++ b/ide/idea/workspace.xml
@@ -155,7 +155,6 @@
   
   
 
-
 
   
 
@@ -180,7 +179,6 @@
   
   
 
-
 
   
 

cassandra git commit: Ninja, include lib/sigar-bin in java.library.path for IntelliJ launch configs

[snazy]

Repository: cassandra
Updated Branches:
  refs/heads/trunk f56c0c668 -> 528204267


Ninja, include lib/sigar-bin in java.library.path for IntelliJ launch configs


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/52820426
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/52820426
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/52820426

Branch: refs/heads/trunk
Commit: 528204267bc8855e95f28191e3ad821a6d686af5
Parents: f56c0c6
Author: Robert Stupp 
Authored: Sat Aug 20 21:34:13 2016 +1000
Committer: Robert Stupp 
Committed: Sat Aug 20 21:34:13 2016 +1000

--
 ide/idea/workspace.xml | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/52820426/ide/idea/workspace.xml
--
diff --git a/ide/idea/workspace.xml b/ide/idea/workspace.xml
index 1645d56..5e7a761 100644
--- a/ide/idea/workspace.xml
+++ b/ide/idea/workspace.xml
@@ -143,7 +143,7 @@
 
   
   
-  
+  
   
   
   
@@ -168,7 +168,7 @@
   
   
   
-  
+  
   
   
   
@@ -187,7 +187,7 @@
 
   
   
-  
+  
   
   
   
@@ -356,4 +356,4 @@
   
 
   
-
\ No newline at end of file
+

[jira] [Commented] (CASSANDRA-9054) Let DatabaseDescriptor not implicitly startup services

[Robert Stupp (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429330#comment-15429330
 ] 

Robert Stupp commented on CASSANDRA-9054:
-

Thanks,
follow-up committed as 
[f56c0c6685a490c9237f5f8ff0baa84f3441b545|https://github.com/apache/cassandra/commit/f56c0c6685a490c9237f5f8ff0baa84f3441b545]
 to [trunk|https://github.com/apache/cassandra/tree/trunk]


> Let DatabaseDescriptor not implicitly startup services
> --
>
> Key: CASSANDRA-9054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9054
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeremiah Jordan
>Assignee: Robert Stupp
> Fix For: 3.10
>
>
> Right now to get at Config stuff you go through DatabaseDescriptor.  But when 
> you instantiate DatabaseDescriptor it actually opens system tables and such, 
> which triggers commit log replays, and other things if the right flags aren't 
> set ahead of time.  This makes getting at config stuff from tools annoying, 
> as you have to be very careful about instantiation orders.
> It would be nice if we could break DatabaseDescriptor up into multiple 
> classes, so that getting at config stuff from tools wasn't such a pain.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cassandra git commit: FOLLOW-UP OF Let DatabaseDescriptor not implicitly startup services

[snazy]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 39df31a06 -> f56c0c668


FOLLOW-UP OF Let DatabaseDescriptor not implicitly startup services

patch by Robert Stupp; reviewed by Jeremiah Jordon for CASSANDRA-9054


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f56c0c66
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f56c0c66
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f56c0c66

Branch: refs/heads/trunk
Commit: f56c0c6685a490c9237f5f8ff0baa84f3441b545
Parents: 39df31a
Author: Robert Stupp 
Authored: Sat Aug 20 21:18:27 2016 +1000
Committer: Robert Stupp 
Committed: Sat Aug 20 21:18:27 2016 +1000

--
 src/java/org/apache/cassandra/auth/AuthConfig.java | 4 ++--
 src/java/org/apache/cassandra/config/DatabaseDescriptor.java   | 2 +-
 src/java/org/apache/cassandra/service/CassandraDaemon.java | 6 --
 .../org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java  | 1 -
 4 files changed, 3 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f56c0c66/src/java/org/apache/cassandra/auth/AuthConfig.java
--
diff --git a/src/java/org/apache/cassandra/auth/AuthConfig.java 
b/src/java/org/apache/cassandra/auth/AuthConfig.java
index c3dd9a9..c389ae4 100644
--- a/src/java/org/apache/cassandra/auth/AuthConfig.java
+++ b/src/java/org/apache/cassandra/auth/AuthConfig.java
@@ -27,7 +27,7 @@ import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.utils.FBUtilities;
 
 /**
- * Only purpose is to Initialize authentication/authorization via {@link 
#applyAuthz()}.
+ * Only purpose is to Initialize authentication/authorization via {@link 
#applyAuth()}.
  * This is in this separate class as it implicitly initializes schema stuff 
(via classes referenced in here).
  */
 public final class AuthConfig
@@ -36,7 +36,7 @@ public final class AuthConfig
 
 private static boolean initialized;
 
-public static void applyAuthz()
+public static void applyAuth()
 {
 // some tests need this
 if (initialized)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f56c0c66/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java 
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index f9d0498..8b33242 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -128,7 +128,7 @@ public class DatabaseDescriptor
 
 setConfig(loadConfig());
 applyAll();
-AuthConfig.applyAuthz();
+AuthConfig.applyAuth();
 }
 
 public static void toolInitialization()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f56c0c66/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index d18fc82..4cbac41 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -46,11 +46,6 @@ import com.google.common.util.concurrent.Uninterruptibles;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
-import com.addthis.metrics3.reporter.config.ReporterConfig;
-import com.codahale.metrics.Meter;
-import com.codahale.metrics.MetricRegistryListener;
-import com.codahale.metrics.SharedMetricRegistries;
-import org.apache.cassandra.auth.AuthConfig;
 import org.apache.cassandra.batchlog.LegacyBatchlogMigrator;
 import org.apache.cassandra.concurrent.ScheduledExecutors;
 import org.apache.cassandra.config.CFMetaData;
@@ -643,7 +638,6 @@ public class CassandraDaemon
 public void applyConfig()
 {
 DatabaseDescriptor.daemonInitialization();
-AuthConfig.applyAuthz();
 }
 
 public void startNativeTransport()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f56c0c66/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java 
b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
index 02edf3a..56409c4 100644
--- a/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java
@@ -57,7 +57,6 @@ public class CQLSSTableWriterTest
 static
 {
 

[jira] [Updated] (CASSANDRA-12476) SyntaxException when COPY FROM Counter Table with Null value

[Ashraful Islam (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashraful Islam updated CASSANDRA-12476:
---
Status: Patch Available  (was: Open)

> SyntaxException when COPY FROM Counter Table with Null value
> 
>
> Key: CASSANDRA-12476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12476
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Ashraful Islam
>Assignee: Stefania
>Priority: Minor
>  Labels: cqlsh
> Fix For: 3.0.x, 3.x
>
> Attachments: 
> Fix_issue___CASSANDRA_12476__SyntaxException_when_COPY_FROM_Counter_Table_with_Null_value.patch
>
>
> I have a simple counter table 
> {noformat}
> CREATE TABLE test (
> a int PRIMARY KEY,
> b counter,
> c counter
> ) ;
> {noformat}
> I have updated b column value with 
> {noformat}
> UPDATE test SET b = b + 1 WHERE a = 1;
> {noformat}
> Now I have export the data with 
> {noformat}
> COPY test TO 'test.csv';
> {noformat}
> And Import it with 
> {noformat}
> COPY test FROM 'test.csv';
> {noformat}
> I get this Error
> {noformat}
> Failed to import 1 rows: SyntaxException - line 1:34 no viable alternative at 
> input 'WHERE' (...=b+1,c=c+ [WHERE]...) -  will retry later, attempt 1 of 5
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12476) SyntaxException when COPY FROM Counter Table with Null value

[Ashraful Islam (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashraful Islam updated CASSANDRA-12476:
---
Attachment: 
Fix_issue___CASSANDRA_12476__SyntaxException_when_COPY_FROM_Counter_Table_with_Null_value.patch

Patch File

> SyntaxException when COPY FROM Counter Table with Null value
> 
>
> Key: CASSANDRA-12476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12476
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Ashraful Islam
>Assignee: Stefania
>Priority: Minor
>  Labels: cqlsh
> Fix For: 3.0.x, 3.x
>
> Attachments: 
> Fix_issue___CASSANDRA_12476__SyntaxException_when_COPY_FROM_Counter_Table_with_Null_value.patch
>
>
> I have a simple counter table 
> {noformat}
> CREATE TABLE test (
> a int PRIMARY KEY,
> b counter,
> c counter
> ) ;
> {noformat}
> I have updated b column value with 
> {noformat}
> UPDATE test SET b = b + 1 WHERE a = 1;
> {noformat}
> Now I have export the data with 
> {noformat}
> COPY test TO 'test.csv';
> {noformat}
> And Import it with 
> {noformat}
> COPY test FROM 'test.csv';
> {noformat}
> I get this Error
> {noformat}
> Failed to import 1 rows: SyntaxException - line 1:34 no viable alternative at 
> input 'WHERE' (...=b+1,c=c+ [WHERE]...) -  will retry later, attempt 1 of 5
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6216) Level Compaction should persist last compacted key per level

[Dikang Gu (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429283#comment-15429283
 ] 

Dikang Gu commented on CASSANDRA-6216:
--

[~krummas] cool, I think it's a more easy-to-understand idea, and maybe could 
save a lot of code. Here is the patch 
https://github.com/DikangGu/cassandra/commit/a63c8583ada93187b177c68dbc4443c29717e44e,
 can you please take a look?

I'm not sure how to write the unit test at this moment, will try some manual 
testing.

> Level Compaction should persist last compacted key per level
> 
>
> Key: CASSANDRA-6216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6216
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: sankalp kohli
>Priority: Minor
>  Labels: compaction, lcs
> Attachments: JIRA-6216.diff
>
>
> Level compaction does not persist the last compacted key per level. This is 
> important for higher levels. 
> The sstables with higher token and in higher levels wont get a chance to 
> compact as the last compacted key will get reset after a restart.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12485) Always require replace_address to replace existing token

[Achal Shah (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429273#comment-15429273
 ] 

Achal Shah commented on CASSANDRA-12485:


Hi, I'm interested in working on this task - from my reading of it, it seems 
like checking {code}DatabaseDescriptor::getReplaceTokens{code} to ensure there 
are no replace tokens in the {code}StorageService::isReplacing{code} method 
should suffice - is that correct?

Please correct me if I'm wrong; I haven't had a lot of experience with 
Cassandra internals.

> Always require replace_address to replace existing token
> 
>
> Key: CASSANDRA-12485
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12485
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Paulo Motta
>Priority: Minor
>  Labels: lhf
>
> CASSANDRA-10134 prevented replace an existing node unless 
> {{\-Dcassandra.replace_address}} or 
> {{\-Dcassandra.allow_unsafe_replace=true}} is specified.
> We should extend this behavior to tokens, preventing a node from joining the 
> ring if another node with the same token already existing in the ring, unless 
> {{\-Dcassandra.replace_address}} or 
> {{\-Dcassandra.allow_unsafe_replace=true}} is specified in order to avoid 
> catastrophic scenarios.
> One scenario where this can easily happen is if you replace a node with 
> another node with a different IP, and after some time you restart the 
> original node by mistake. The original node will then take over the tokens of 
> the replaced node (since it has a newer gossip generation).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)