date:20171203

[jira] [Assigned] (CASSANDRA-14087) NPE when CAS encounters empty frozen collection

2017-12-03 Thread Kurt Greaves (JIRA)


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

Kurt Greaves reassigned CASSANDRA-14087:


Assignee: Kurt Greaves

> NPE when CAS encounters empty frozen collection
> ---
>
> Key: CASSANDRA-14087
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14087
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jens Bannmann
>Assignee: Kurt Greaves
>
> When a compare-and-set operation specifying an equality criterion with a 
> non-{{null}} value encounters an empty collection ({{null}} cell), the server 
> throws a {{NullPointerException}} and the query fails.
> This does not happen for non-frozen collections.
> There's a self-contained test case at 
> [github|https://github.com/incub8/cassandra-npe-in-cas].
> The stack trace for 3.11.0 is:
> {code}
> ERROR [Native-Transport-Requests-1] 2017-11-27 12:59:26,924 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.NullPointerException: null
> at 
> org.apache.cassandra.cql3.ColumnCondition$CollectionBound.appliesTo(ColumnCondition.java:546)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest$ColumnsConditions.appliesTo(CQL3CasRequest.java:324)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.appliesTo(CQL3CasRequest.java:210)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:265) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:217)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:248) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233) 
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_151]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [apache-cassandra-3.11.0.jar:3.11.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.11.0.jar:3.11.0]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14088) Forward slash in role name breaks CassandraAuthorizer

2017-12-03 Thread Kurt Greaves (JIRA)


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

Kurt Greaves edited comment on CASSANDRA-14088 at 12/4/17 3:39 AM:
---

[3.0|https://github.com/apache/cassandra/compare/trunk...kgreav:14088-3.0]
No reason for us to split in {{RoleResource::fromName}} more than once, so just 
specified a max and added some tests to make sure we accept forward slashes and 
some other names correctly.
Patch is the same for trunk and 3.11. Should merge cleanly.


was (Author: kurtg):
[trunk|https://github.com/apache/cassandra/compare/trunk...kgreav:14088-3.0]
No reason for us to split in {{RoleResource::fromName}} more than once, so just 
specified a max and added some tests to make sure we accept forward slashes and 
some other names correctly.
Patch is the same for trunk and 3.11. Should merge cleanly.

> Forward slash in role name breaks CassandraAuthorizer
> -
>
> Key: CASSANDRA-14088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14088
> Project: Cassandra
>  Issue Type: Bug
>  Components: Auth
> Environment: Git commit: 4c80eeece37d79f434078224a0504400ae10a20d 
> ({{HEAD}} of {{trunk}}).
>Reporter: Jesse Haber-Kucharsky
>Assignee: Kurt Greaves
>Priority: Minor
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> The standard system authorizer 
> ({{org.apache.cassandra.auth.CassandraAuthorizer}}) stores the permissions 
> granted to each user for a given resource in {{system_auth.role_permissions}}.
> A resource like the {{my_keyspace.items}} table is stored as 
> {{"data/my_keyspace/items"}} (note the {{/}} delimiter).
> Similarly, role resources (like the {{joe}} role) are stored as 
> {{"roles/joe"}}.
> The problem is that roles can be created with {{/}} in their names, which 
> confuses the authorizer when the table is queried.
> For example,
> {code}
> $ bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-SNAPSHOT | CQL spec 3.4.5 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE emperor;
> cassandra@cqlsh> CREATE ROLE "ki/ng";
> cassandra@cqlsh> GRANT ALTER ON ROLE "ki/ng" TO emperor;
> cassandra@cqlsh> LIST ROLES;
>  role  | super | login | options
> ---+---+---+-
>  cassandra |  True |  True |{}
>emperor | False | False |{}
>  ki/ng | False | False |{}
> (3 rows)
> cassandra@cqlsh> SELECT * FROM system_auth.role_permissions;
>  role  | resource  | permissions
> ---+---+
>emperor |   roles/ki/ng |  {'ALTER'}
>  cassandra | roles/emperor | {'ALTER', 'AUTHORIZE', 'DROP'}
>  cassandra |   roles/ki/ng | {'ALTER', 'AUTHORIZE', 'DROP'}
> (3 rows)
> cassandra@cqlsh> LIST ALL PERMISSIONS OF emperor;
> ServerError: java.lang.IllegalArgumentException: roles/ki/ng is not a valid 
> role resource name
> {code}
> Here's the backtrace from the server process:
> {code}
> ERROR [Native-Transport-Requests-1] 2017-12-01 11:07:52,811 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.IllegalArgumentException: roles/ki/ng is not a valid role resource 
> name
> at 
> org.apache.cassandra.auth.RoleResource.fromName(RoleResource.java:101) 
> ~[main/:na]
> at org.apache.cassandra.auth.Resources.fromName(Resources.java:56) 
> ~[main/:na]
> at 
> org.apache.cassandra.auth.CassandraAuthorizer.listPermissionsForRole(CassandraAuthorizer.java:283)
>  ~[main/:na]
> at 
> org.apache.cassandra.auth.CassandraAuthorizer.list(CassandraAuthorizer.java:263)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ListPermissionsStatement.list(ListPermissionsStatement.java:108)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ListPermissionsStatement.execute(ListPermissionsStatement.java:96)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.AuthorizationStatement.execute(AuthorizationStatement.java:48)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:207)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:238) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:223) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [main/:na]
> at 
>

[jira] [Updated] (CASSANDRA-14088) Forward slash in role name breaks CassandraAuthorizer

2017-12-03 Thread Kurt Greaves (JIRA)


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

Kurt Greaves updated CASSANDRA-14088:
-
Fix Version/s: 4.0
   3.11.2
   3.0.16
   Status: Patch Available  (was: In Progress)

[trunk|https://github.com/apache/cassandra/compare/trunk...kgreav:14088-3.0]
No reason for us to split in {{RoleResource::fromName}} more than once, so just 
specified a max and added some tests to make sure we accept forward slashes and 
some other names correctly.
Patch is the same for trunk and 3.11. Should merge cleanly.

> Forward slash in role name breaks CassandraAuthorizer
> -
>
> Key: CASSANDRA-14088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14088
> Project: Cassandra
>  Issue Type: Bug
>  Components: Auth
> Environment: Git commit: 4c80eeece37d79f434078224a0504400ae10a20d 
> ({{HEAD}} of {{trunk}}).
>Reporter: Jesse Haber-Kucharsky
>Assignee: Kurt Greaves
>Priority: Minor
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> The standard system authorizer 
> ({{org.apache.cassandra.auth.CassandraAuthorizer}}) stores the permissions 
> granted to each user for a given resource in {{system_auth.role_permissions}}.
> A resource like the {{my_keyspace.items}} table is stored as 
> {{"data/my_keyspace/items"}} (note the {{/}} delimiter).
> Similarly, role resources (like the {{joe}} role) are stored as 
> {{"roles/joe"}}.
> The problem is that roles can be created with {{/}} in their names, which 
> confuses the authorizer when the table is queried.
> For example,
> {code}
> $ bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-SNAPSHOT | CQL spec 3.4.5 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE emperor;
> cassandra@cqlsh> CREATE ROLE "ki/ng";
> cassandra@cqlsh> GRANT ALTER ON ROLE "ki/ng" TO emperor;
> cassandra@cqlsh> LIST ROLES;
>  role  | super | login | options
> ---+---+---+-
>  cassandra |  True |  True |{}
>emperor | False | False |{}
>  ki/ng | False | False |{}
> (3 rows)
> cassandra@cqlsh> SELECT * FROM system_auth.role_permissions;
>  role  | resource  | permissions
> ---+---+
>emperor |   roles/ki/ng |  {'ALTER'}
>  cassandra | roles/emperor | {'ALTER', 'AUTHORIZE', 'DROP'}
>  cassandra |   roles/ki/ng | {'ALTER', 'AUTHORIZE', 'DROP'}
> (3 rows)
> cassandra@cqlsh> LIST ALL PERMISSIONS OF emperor;
> ServerError: java.lang.IllegalArgumentException: roles/ki/ng is not a valid 
> role resource name
> {code}
> Here's the backtrace from the server process:
> {code}
> ERROR [Native-Transport-Requests-1] 2017-12-01 11:07:52,811 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.IllegalArgumentException: roles/ki/ng is not a valid role resource 
> name
> at 
> org.apache.cassandra.auth.RoleResource.fromName(RoleResource.java:101) 
> ~[main/:na]
> at org.apache.cassandra.auth.Resources.fromName(Resources.java:56) 
> ~[main/:na]
> at 
> org.apache.cassandra.auth.CassandraAuthorizer.listPermissionsForRole(CassandraAuthorizer.java:283)
>  ~[main/:na]
> at 
> org.apache.cassandra.auth.CassandraAuthorizer.list(CassandraAuthorizer.java:263)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ListPermissionsStatement.list(ListPermissionsStatement.java:108)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ListPermissionsStatement.execute(ListPermissionsStatement.java:96)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.AuthorizationStatement.execute(AuthorizationStatement.java:48)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:207)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:238) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:223) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [main/:na]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.1.14.Final.jar:4.1.14.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
>  [netty-all-4.1.14.Final.jar:4.1.14.Final]
> at 
>

[jira] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>

2017-12-03 Thread Alex Lourie (JIRA)


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

Alex Lourie commented on CASSANDRA-14054:
-

I'm looking into this.

> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is 
> flaky: expected <2> but got <1>
> -
>
> Key: CASSANDRA-14054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is 
> flaky: expected <2> but got <1>
> Fails about 25% of the time. It is currently our only flaky unit test on 
> trunk so it would be great to get this one fixed up so we can be confident in 
> unit test failures going forward.
> junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of 
> type int), expected <2> but got <1>
>   at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973)
>   at 
> org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>

2017-12-03 Thread Alex Lourie (JIRA)


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

Alex Lourie reassigned CASSANDRA-14054:
---

Assignee: Alex Lourie

> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is 
> flaky: expected <2> but got <1>
> -
>
> Key: CASSANDRA-14054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14054
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is 
> flaky: expected <2> but got <1>
> Fails about 25% of the time. It is currently our only flaky unit test on 
> trunk so it would be great to get this one fixed up so we can be confident in 
> unit test failures going forward.
> junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of 
> type int), expected <2> but got <1>
>   at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973)
>   at 
> org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14080) Handling 0 size hint files during start

2017-12-03 Thread Alex Lourie (JIRA)


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

Alex Lourie updated CASSANDRA-14080:

Reproduced In: 3.0.14, 4.x  (was: 3.0.14)
   Status: Patch Available  (was: In Progress)

> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
>  Issue Type: Bug
>  Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO  [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra 
> version: 3.0.14
> INFO  [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API 
> version: 20.1.0
> INFO  [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported 
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception 
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at 
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) 
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116) 
> ~[na:1.8.0_141]
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>  ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) 
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsService.(HintsService.java:88) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsService.(HintsService.java:63) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
> ~[na:1.8.0_141]
> at 
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's 
> possible that the original patch didn't consider 0 byte files (I don't have 
> time to go back and look at the commit, and it was long enough ago that I've 
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14080) Handling 0 size hint files during start

2017-12-03 Thread Alex Lourie (JIRA)


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

Alex Lourie commented on CASSANDRA-14080:
-

A patch for trunk in 
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-14080

> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
>  Issue Type: Bug
>  Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO  [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra 
> version: 3.0.14
> INFO  [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API 
> version: 20.1.0
> INFO  [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported 
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception 
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at 
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) 
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116) 
> ~[na:1.8.0_141]
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>  ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) 
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsService.(HintsService.java:88) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsService.(HintsService.java:63) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
> ~[na:1.8.0_141]
> at 
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's 
> possible that the original patch didn't consider 0 byte files (I don't have 
> time to go back and look at the commit, and it was long enough ago that I've 
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14080) Handling 0 size hint files during start

2017-12-03 Thread Alex Lourie (JIRA)


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

Alex Lourie edited comment on CASSANDRA-14080 at 12/4/17 2:48 AM:
--

A patch for trunk is in 
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-14080


was (Author: alourie):
A patch for trunk in 
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-14080

> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
>  Issue Type: Bug
>  Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO  [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra 
> version: 3.0.14
> INFO  [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API 
> version: 20.1.0
> INFO  [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported 
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception 
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at 
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) 
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116) 
> ~[na:1.8.0_141]
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>  ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) 
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsService.(HintsService.java:88) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsService.(HintsService.java:63) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
> ~[na:1.8.0_141]
> at 
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's 
> possible that the original patch didn't consider 0 byte files (I don't have 
> time to go back and look at the commit, and it was long enough ago that I've 
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For

[jira] [Assigned] (CASSANDRA-14088) Forward slash in role name breaks CassandraAuthorizer

2017-12-03 Thread Kurt Greaves (JIRA)


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

Kurt Greaves reassigned CASSANDRA-14088:


Assignee: Kurt Greaves

> Forward slash in role name breaks CassandraAuthorizer
> -
>
> Key: CASSANDRA-14088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14088
> Project: Cassandra
>  Issue Type: Bug
>  Components: Auth
> Environment: Git commit: 4c80eeece37d79f434078224a0504400ae10a20d 
> ({{HEAD}} of {{trunk}}).
>Reporter: Jesse Haber-Kucharsky
>Assignee: Kurt Greaves
>Priority: Minor
>
> The standard system authorizer 
> ({{org.apache.cassandra.auth.CassandraAuthorizer}}) stores the permissions 
> granted to each user for a given resource in {{system_auth.role_permissions}}.
> A resource like the {{my_keyspace.items}} table is stored as 
> {{"data/my_keyspace/items"}} (note the {{/}} delimiter).
> Similarly, role resources (like the {{joe}} role) are stored as 
> {{"roles/joe"}}.
> The problem is that roles can be created with {{/}} in their names, which 
> confuses the authorizer when the table is queried.
> For example,
> {code}
> $ bin/cqlsh -u cassandra -p cassandra
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-SNAPSHOT | CQL spec 3.4.5 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE ROLE emperor;
> cassandra@cqlsh> CREATE ROLE "ki/ng";
> cassandra@cqlsh> GRANT ALTER ON ROLE "ki/ng" TO emperor;
> cassandra@cqlsh> LIST ROLES;
>  role  | super | login | options
> ---+---+---+-
>  cassandra |  True |  True |{}
>emperor | False | False |{}
>  ki/ng | False | False |{}
> (3 rows)
> cassandra@cqlsh> SELECT * FROM system_auth.role_permissions;
>  role  | resource  | permissions
> ---+---+
>emperor |   roles/ki/ng |  {'ALTER'}
>  cassandra | roles/emperor | {'ALTER', 'AUTHORIZE', 'DROP'}
>  cassandra |   roles/ki/ng | {'ALTER', 'AUTHORIZE', 'DROP'}
> (3 rows)
> cassandra@cqlsh> LIST ALL PERMISSIONS OF emperor;
> ServerError: java.lang.IllegalArgumentException: roles/ki/ng is not a valid 
> role resource name
> {code}
> Here's the backtrace from the server process:
> {code}
> ERROR [Native-Transport-Requests-1] 2017-12-01 11:07:52,811 
> QueryMessage.java:129 - Unexpected error during query
> java.lang.IllegalArgumentException: roles/ki/ng is not a valid role resource 
> name
> at 
> org.apache.cassandra.auth.RoleResource.fromName(RoleResource.java:101) 
> ~[main/:na]
> at org.apache.cassandra.auth.Resources.fromName(Resources.java:56) 
> ~[main/:na]
> at 
> org.apache.cassandra.auth.CassandraAuthorizer.listPermissionsForRole(CassandraAuthorizer.java:283)
>  ~[main/:na]
> at 
> org.apache.cassandra.auth.CassandraAuthorizer.list(CassandraAuthorizer.java:263)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ListPermissionsStatement.list(ListPermissionsStatement.java:108)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ListPermissionsStatement.execute(ListPermissionsStatement.java:96)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.AuthorizationStatement.execute(AuthorizationStatement.java:48)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:207)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:238) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:223) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [main/:na]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.1.14.Final.jar:4.1.14.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
>  [netty-all-4.1.14.Final.jar:4.1.14.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:38)
>  [netty-all-4.1.14.Final.jar:4.1.14.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:353)
>  [netty-all-4.1.14.Final.jar:4.1.14.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_151]
> at 
>

[jira] [Assigned] (CASSANDRA-14080) Handling 0 size hint files during start

2017-12-03 Thread Alex Lourie (JIRA)


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

Alex Lourie reassigned CASSANDRA-14080:
---

Assignee: Alex Lourie

> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
>  Issue Type: Bug
>  Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO  [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra 
> version: 3.0.14
> INFO  [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API 
> version: 20.1.0
> INFO  [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported 
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception 
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at 
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) 
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116) 
> ~[na:1.8.0_141]
> at 
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>  ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) 
> ~[na:1.8.0_141]
> at 
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) 
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsService.(HintsService.java:88) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsService.(HintsService.java:63) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121) 
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
>  [apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697) 
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803) 
> ~[na:1.8.0_141]
> at 
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> at 
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
>  ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's 
> possible that the original patch didn't consider 0 byte files (I don't have 
> time to go back and look at the commit, and it was long enough ago that I've 
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14060) Separate CorruptSSTableException and FSError handling policies

2017-12-03 Thread Jay Zhuang (JIRA)


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

Jay Zhuang commented on CASSANDRA-14060:


bq. when you say most of your corrupt sstables aren't disk issues - to what do 
you attribute them?
We don't know the root cause, but it should be software bug. We saw the 
{{CorruptSSTableException}} in several nodes at the same time, which causes 
multiple nodes down. So I don't think it's a disk issue.
For example just yesterday, 10 nodes were down at the same time (the cluster 
has 2 DCs, each DC has 15 nodes, all down nodes are in the same DC, we use 
{{local_quorum}}), here is the call stack:
{noformat}
ERROR [SharedPool-Worker-7] 2017-12-02 01:06:51,135 
JVMStabilityInspector.java:140 - JVM state determined to be unstable.  Exiting 
forcefully due to:
org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted: 
/var/data/[keyspace]/[table]/mc-1-big-Data.db
at 
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:356)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:220)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:33)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:58)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:67)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:26)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:296)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76) 
~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:321) 
~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:47)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67) 
~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[na:1.8.0_121]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
 ~[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at 
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
 [apache-cassandra-3.0.14.1.jar:3.0.14.1]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
[apache-cassandra-3.0.14.1.jar:3.0.14.1]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.rangeCheck(ArrayList.java:653) ~[na:1.8.0_121]
at

[jira] [Commented] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime

2017-12-03 Thread Paulo Motta (JIRA)


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

Paulo Motta commented on CASSANDRA-14092:
-

I think that CASSANDRA-8099 already removed this limitation from the storage 
engine by encoding {{localDeletionTime}} as a varint, so it should be 
relatively easy to update the code to represent {{localDeletionTime}} as a long 
instead.

> Max ttl of 20 years will overflow localDeletionTime
> ---
>
> Key: CASSANDRA-14092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14092
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Paulo Motta
>
> CASSANDRA-4771 added a max value of 20 years for ttl to protect against [year 
> 2038 overflow bug|https://en.wikipedia.org/wiki/Year_2038_problem] for 
> {{localDeletionTime}}.
> It turns out that next year the {{localDeletionTime}} will start overflowing 
> with the maximum ttl of 20 years ({{System.currentTimeMillis() + ttl(20 
> years) > Integer.MAX_VALUE}}), so we should remove this limitation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime

2017-12-03 Thread Paulo Motta (JIRA)


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

Paulo Motta updated CASSANDRA-14092:

Description: 
CASSANDRA-4771 added a max value of 20 years for ttl to protect against [year 
2038 overflow bug|https://en.wikipedia.org/wiki/Year_2038_problem] for 
{{localDeletionTime}}.

It turns out that next year the {{localDeletionTime}} will start overflowing 
with the maximum ttl of 20 years ({{System.currentTimeMillis() + ttl(20 years) 
> Integer.MAX_VALUE}}), so we should remove this limitation.

  was:
CASSANDRA-4771 added a max value of 20 years for ttl to protect against [year 
2038 overflow bug|https://en.wikipedia.org/wiki/Year_2038_problem] for 
{{localDeletionTime}}, when {{System.currentTimeMillis() + ttl(20 years) > 
Integer.MAX_VALUE}}

It turns out that next year the {{localDeletionTime}} will start overflowing 
with the maximum ttl of 20 years, so we should remove this limitation.


> Max ttl of 20 years will overflow localDeletionTime
> ---
>
> Key: CASSANDRA-14092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14092
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Paulo Motta
>
> CASSANDRA-4771 added a max value of 20 years for ttl to protect against [year 
> 2038 overflow bug|https://en.wikipedia.org/wiki/Year_2038_problem] for 
> {{localDeletionTime}}.
> It turns out that next year the {{localDeletionTime}} will start overflowing 
> with the maximum ttl of 20 years ({{System.currentTimeMillis() + ttl(20 
> years) > Integer.MAX_VALUE}}), so we should remove this limitation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime

2017-12-03 Thread Paulo Motta (JIRA)

Paulo Motta created CASSANDRA-14092:
---

 Summary: Max ttl of 20 years will overflow localDeletionTime
 Key: CASSANDRA-14092
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14092
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Paulo Motta


CASSANDRA-4771 added a max value of 20 years for ttl to protect against [year 
2038 overflow bug|https://en.wikipedia.org/wiki/Year_2038_problem] for 
{{localDeletionTime}}, when {{System.currentTimeMillis() + ttl(20 years) > 
Integer.MAX_VALUE}}

It turns out that next year the {{localDeletionTime}} will start overflowing 
with the maximum ttl of 20 years, so we should remove this limitation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14071) Materialized view on table with TTL issue

2017-12-03 Thread ZhaoYang (JIRA)


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

ZhaoYang commented on CASSANDRA-14071:
--

Thanks for the feedback.

bq. The approach looks good to me but even though this looks safe I think we 
should restrict this new resolution rule only to pk liveness info of views to 
ensure no other code path can be affected by this since this is a pretty 
critical path. What do you think?

Current TTL in insert/update request is at most 20 yrs defined in 
Attributes.java, but there is no TTL limit for table default_time_to_live. I 
think using a very large default_time_to_live is not reasonable because {{TTL + 
nowInSeconds}} can cause int32 overflow. 

I added an validation logic in {{TableParams}} to make sure 
default_time_to_live will never be {{Integer.MAX_VALUE}} which is reserved for 
MV..

Or do you think adding a method param, eg {{isView}}, to 
{{LivenessInfo.supersedes()}} is safer?

bq. Also, besides the case with default ttl, this also affects overwrites with 
ttl right? Can you add a test with this case as well?

Make sense, I have updated the test with user-provided TTL

> Materialized view on table with TTL issue
> -
>
> Key: CASSANDRA-14071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14071
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination, Materialized Views
> Environment: Cassandra 3
>Reporter: Silviu Butnariu
>Assignee: ZhaoYang
>  Labels: correctness
>
> Materialized views that cluster by a column that is not part of table's PK 
> and are created from tables that have *default_time_to_live* seems to 
> malfunction.
> Having this table
> {code:java}
> CREATE TABLE sbutnariu.test_bug (
> field1 smallint,
> field2 smallint,
> date timestamp,
> PRIMARY KEY ((field1), field2)
> ) WITH default_time_to_live = 1000;
> {code}
> and the materialized view
> {code:java}
> CREATE MATERIALIZED VIEW sbutnariu.test_bug_by_date AS SELECT * FROM 
> sbutnariu.test_bug WHERE field1 IS NOT NULL AND field2 IS NOT NULL AND date 
> IS NOT NULL PRIMARY KEY ((field1), date, field2) WITH CLUSTERING ORDER BY 
> (date desc, field2 asc);
> {code}
> After inserting 3 rows with same PK (should upsert), the materialized view 
> will have 3 rows.
> {code:java}
> insert into sbutnariu.test_bug(field1, field2, date) values (1, 2, 
> toTimestamp(now()));
> insert into sbutnariu.test_bug(field1, field2, date) values (1, 2, 
> toTimestamp(now()));
> insert into sbutnariu.test_bug(field1, field2, date) values (1, 2, 
> toTimestamp(now()));
> select * from sbutnariu.test_bug; /*1 row*/
> select * from sbutnariu.test_bug_by_date;/*3 rows*/
> {code}
> If I remove the ttl and try again, it works as expected:
> {code:java}
> truncate sbutnariu.test_bug;
> alter table sbutnariu.test_bug with default_time_to_live = 0;
> select * from sbutnariu.test_bug; /*1 row*/
> select * from sbutnariu.test_bug_by_date;/*1 row*/
> {code}
> I've tested on versions 3.0.14 and 3.0.15. The bug was introduced in 3.0.15, 
> as in 3.0.14 it works as expected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13916) Remove OpenJDK log warning

2017-12-03 Thread Jason Brown (JIRA)


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

Jason Brown updated CASSANDRA-13916:

   Resolution: Fixed
Fix Version/s: (was: 3.11.x)
   (was: 4.x)
   4.0
   3.11.2
   Status: Resolved  (was: Ready to Commit)

committed as sha {{d577918ba93fe9e761ca9fdbe1b4fe1f32dcac7b}}

> Remove OpenJDK log warning
> --
>
> Key: CASSANDRA-13916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13916
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Anthony Grasso
>Assignee: Jason Brown
>Priority: Minor
>  Labels: lhf
> Fix For: 3.11.2, 4.0
>
>
> The following warning message will appear in the logs when using OpenJDK
> {noformat}
> WARN  [main] ... OpenJDK is not recommended. Please upgrade to the newest 
> Oracle Java release
> {noformat}
> The above warning dates back to when OpenJDK 6 was released and there were 
> some issues in early releases of this version. The OpenJDK implementation is 
> used as a reference for the OracleJDK which means the implementations are 
> very close. In addition, most users have moved off Java 6 so we can probably 
> remove this warning message.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[2/4] cassandra git commit: Remove OpenJDK log warning

2017-12-03 Thread jasobrown

Remove OpenJDK log warning

patch by jasobrown; reviewed by Jeff Jirsa for CASSANDRA-13916


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

Branch: refs/heads/trunk
Commit: d577918ba93fe9e761ca9fdbe1b4fe1f32dcac7b
Parents: d2e4ce4
Author: Jason Brown 
Authored: Sat Dec 2 05:51:23 2017 -0800
Committer: Jason Brown 
Committed: Sun Dec 3 03:47:02 2017 -0800

--
 CHANGES.txt  | 1 +
 src/java/org/apache/cassandra/service/StartupChecks.java | 8 +---
 2 files changed, 2 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d577918b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ce279f2..e26aeb8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.11.2
+ * Remove OpenJDK log warning (CASSANDRA-13916)
  * Prevent compaction strategies from looping indefinitely (CASSANDRA-14079)
  * Cache disk boundaries (CASSANDRA-13215)
  * Add asm jar to build.xml for maven builds (CASSANDRA-11193)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d577918b/src/java/org/apache/cassandra/service/StartupChecks.java
--
diff --git a/src/java/org/apache/cassandra/service/StartupChecks.java 
b/src/java/org/apache/cassandra/service/StartupChecks.java
index 372f5f9..3ccea5f 100644
--- a/src/java/org/apache/cassandra/service/StartupChecks.java
+++ b/src/java/org/apache/cassandra/service/StartupChecks.java
@@ -196,13 +196,7 @@ public class StartupChecks
 logger.warn("32bit JVM detected.  It is recommended to run 
Cassandra on a 64bit JVM for better performance.");
 
 String javaVmName = System.getProperty("java.vm.name");
-if (javaVmName.contains("OpenJDK"))
-{
-// There is essentially no QA done on OpenJDK builds, and
-// clusters running OpenJDK have seen many heap and load 
issues.
-logger.warn("OpenJDK is not recommended. Please upgrade to the 
newest Oracle Java release");
-}
-else if (!javaVmName.contains("HotSpot"))
+if (!(javaVmName.contains("HotSpot") || 
javaVmName.contains("OpenJDK")))
 {
 logger.warn("Non-Oracle JVM detected.  Some features, such as 
immediate unmap of compacted SSTables, may not work as intended");
 }


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[4/4] cassandra git commit: Remove OpenJDK log warning

2017-12-03 Thread jasobrown

Remove OpenJDK log warning

patch by jasobrown; reviewed by Jeff Jirsa for CASSANDRA-13916


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

Branch: refs/heads/trunk
Commit: 69052a05597a9c3571356d8c39232512c9f3f393
Parents: 58aebd1
Author: Jason Brown 
Authored: Sat Dec 2 05:51:23 2017 -0800
Committer: Jason Brown 
Committed: Sun Dec 3 03:48:32 2017 -0800

--
 CHANGES.txt  | 1 +
 src/java/org/apache/cassandra/service/StartupChecks.java | 8 +---
 2 files changed, 2 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/69052a05/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d197038..9a5b80d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -165,6 +165,7 @@
 
 
 3.11.2
+ * Remove OpenJDK log warning (CASSANDRA-13916)
  * Prevent compaction strategies from looping indefinitely (CASSANDRA-14079)
  * Cache disk boundaries (CASSANDRA-13215)
  * Add asm jar to build.xml for maven builds (CASSANDRA-11193)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/69052a05/src/java/org/apache/cassandra/service/StartupChecks.java
--
diff --git a/src/java/org/apache/cassandra/service/StartupChecks.java 
b/src/java/org/apache/cassandra/service/StartupChecks.java
index 2774dee..f84920e 100644
--- a/src/java/org/apache/cassandra/service/StartupChecks.java
+++ b/src/java/org/apache/cassandra/service/StartupChecks.java
@@ -195,13 +195,7 @@ public class StartupChecks
 logger.warn("32bit JVM detected.  It is recommended to run 
Cassandra on a 64bit JVM for better performance.");
 
 String javaVmName = System.getProperty("java.vm.name");
-if (javaVmName.contains("OpenJDK"))
-{
-// There is essentially no QA done on OpenJDK builds, and
-// clusters running OpenJDK have seen many heap and load 
issues.
-logger.warn("OpenJDK is not recommended. Please upgrade to the 
newest Oracle Java release");
-}
-else if (!javaVmName.contains("HotSpot"))
+if (!(javaVmName.contains("HotSpot") || 
javaVmName.contains("OpenJDK")))
 {
 logger.warn("Non-Oracle JVM detected.  Some features, such as 
immediate unmap of compacted SSTables, may not work as intended");
 }


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[1/4] cassandra git commit: Remove OpenJDK log warning

2017-12-03 Thread jasobrown

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.11 d2e4ce489 -> d577918ba
  refs/heads/trunk 95b43b195 -> 69052a055


Remove OpenJDK log warning

patch by jasobrown; reviewed by Jeff Jirsa for CASSANDRA-13916


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

Branch: refs/heads/cassandra-3.11
Commit: d577918ba93fe9e761ca9fdbe1b4fe1f32dcac7b
Parents: d2e4ce4
Author: Jason Brown 
Authored: Sat Dec 2 05:51:23 2017 -0800
Committer: Jason Brown 
Committed: Sun Dec 3 03:47:02 2017 -0800

--
 CHANGES.txt  | 1 +
 src/java/org/apache/cassandra/service/StartupChecks.java | 8 +---
 2 files changed, 2 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d577918b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ce279f2..e26aeb8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.11.2
+ * Remove OpenJDK log warning (CASSANDRA-13916)
  * Prevent compaction strategies from looping indefinitely (CASSANDRA-14079)
  * Cache disk boundaries (CASSANDRA-13215)
  * Add asm jar to build.xml for maven builds (CASSANDRA-11193)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d577918b/src/java/org/apache/cassandra/service/StartupChecks.java
--
diff --git a/src/java/org/apache/cassandra/service/StartupChecks.java 
b/src/java/org/apache/cassandra/service/StartupChecks.java
index 372f5f9..3ccea5f 100644
--- a/src/java/org/apache/cassandra/service/StartupChecks.java
+++ b/src/java/org/apache/cassandra/service/StartupChecks.java
@@ -196,13 +196,7 @@ public class StartupChecks
 logger.warn("32bit JVM detected.  It is recommended to run 
Cassandra on a 64bit JVM for better performance.");
 
 String javaVmName = System.getProperty("java.vm.name");
-if (javaVmName.contains("OpenJDK"))
-{
-// There is essentially no QA done on OpenJDK builds, and
-// clusters running OpenJDK have seen many heap and load 
issues.
-logger.warn("OpenJDK is not recommended. Please upgrade to the 
newest Oracle Java release");
-}
-else if (!javaVmName.contains("HotSpot"))
+if (!(javaVmName.contains("HotSpot") || 
javaVmName.contains("OpenJDK")))
 {
 logger.warn("Non-Oracle JVM detected.  Some features, such as 
immediate unmap of compacted SSTables, may not work as intended");
 }


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[3/4] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

2017-12-03 Thread jasobrown

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 58aebd17677c0f6a27035629ed389d6cb28297a0
Parents: 95b43b1 d577918
Author: Jason Brown 
Authored: Sun Dec 3 03:47:30 2017 -0800
Committer: Jason Brown 
Committed: Sun Dec 3 03:47:30 2017 -0800

--

--



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-14087) NPE when CAS encounters empty frozen collection

[jira] [Comment Edited] (CASSANDRA-14088) Forward slash in role name breaks CassandraAuthorizer

[jira] [Updated] (CASSANDRA-14088) Forward slash in role name breaks CassandraAuthorizer

[jira] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>

[jira] [Assigned] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>

[jira] [Updated] (CASSANDRA-14080) Handling 0 size hint files during start

[jira] [Commented] (CASSANDRA-14080) Handling 0 size hint files during start

[jira] [Comment Edited] (CASSANDRA-14080) Handling 0 size hint files during start

[jira] [Assigned] (CASSANDRA-14088) Forward slash in role name breaks CassandraAuthorizer

[jira] [Assigned] (CASSANDRA-14080) Handling 0 size hint files during start

[jira] [Commented] (CASSANDRA-14060) Separate CorruptSSTableException and FSError handling policies

[jira] [Commented] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime

[jira] [Updated] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime

[jira] [Created] (CASSANDRA-14092) Max ttl of 20 years will overflow localDeletionTime

[jira] [Commented] (CASSANDRA-14071) Materialized view on table with TTL issue

[jira] [Updated] (CASSANDRA-13916) Remove OpenJDK log warning

[2/4] cassandra git commit: Remove OpenJDK log warning

[4/4] cassandra git commit: Remove OpenJDK log warning

[1/4] cassandra git commit: Remove OpenJDK log warning

[3/4] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

20 matches

Site Navigation

Mail list logo

Footer information