[jira] [Assigned] (CASSANDRA-14118) Refactor write path

[Dikang Gu (JIRA)]

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

Dikang Gu reassigned CASSANDRA-14118:
-

Assignee: Blake Eggleston  (was: Dikang Gu)

> Refactor write path
> ---
>
> Key: CASSANDRA-14118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14118
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Dikang Gu
>Assignee: Blake Eggleston
>Priority: Major
>
> As part of the pluggable storage engine effort, we'd like to modularize the 
> write path related code, make it to be independent from existing storage 
> engine implementation details.
> For now, refer to 
> https://docs.google.com/document/d/1suZlvhzgB6NIyBNpM9nxoHxz_Ri7qAm-UEO8v8AIFsc
>  for high level designs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-13010:


I like the idea of hiding the extra stuff behind a flag, I think that would be 
great.  

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Compaction, Tools
>Reporter: Jon Haddad
>Assignee: Alex Lourie
>Priority: Major
>  Labels: lhf
> Attachments: 13010.patch, cleanup.png, multiple operations.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (CASSANDRA-13889) cfstats should take sorting and limit parameters

[Jon Haddad (JIRA)]

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

Jon Haddad reassigned CASSANDRA-13889:
--

Assignee: Patrick Bannister

> cfstats should take sorting and limit parameters
> 
>
> Key: CASSANDRA-13889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13889
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Jon Haddad
>Assignee: Patrick Bannister
>Priority: Major
> Fix For: 4.0
>
>
> When looking at a problematic node I'm not familiar with, one of the first 
> things I do is check cfstats to identify the tables with the most reads, 
> writes, and data.  This is fine as long as there aren't a lot of tables but 
> once it goes above a dozen it's quite difficult.  cfstats should allow me to 
> sort the results and limit to top K tables.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13889) cfstats should take sorting and limit parameters

[Patrick Bannister (JIRA)]

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

Patrick Bannister commented on CASSANDRA-13889:
---

OK, I'll get to work.

Would somebody with assignment privileges please assign this ticket to me?

> cfstats should take sorting and limit parameters
> 
>
> Key: CASSANDRA-13889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13889
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Jon Haddad
>Priority: Major
> Fix For: 4.0
>
>
> When looking at a problematic node I'm not familiar with, one of the first 
> things I do is check cfstats to identify the tables with the most reads, 
> writes, and data.  This is fine as long as there aren't a lot of tables but 
> once it goes above a dozen it's quite difficult.  cfstats should allow me to 
> sort the results and limit to top K tables.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14118) Refactor write path

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-14118:
-

I've been working on an alternate implementation 
[here|https://github.com/bdeggleston/cassandra/tree/14118-v2]. I think it's 
probably more in line with what we need here.

The main interfaces are 
[KeyspaceWriteHandler|https://github.com/bdeggleston/cassandra/blob/14118-v2/src/java/org/apache/cassandra/db/KeyspaceWriteHandler.java]
 and 
[TableWriteHandler|https://github.com/bdeggleston/cassandra/blob/14118-v2/src/java/org/apache/cassandra/db/TableWriteHandler.java],
 which I still need to write docs for. The interfaces hide most of the existing 
implementation, including the operation ordering. I've also done some 
preliminary work on indexes since they need to deal with the write interface.

{{Keyspace.writeOrder}} is still exposed in a few places related to creating 
and dropping keyspaces/tables/indexes to wait on pending writes. I think those 
are probably best left for CASSANDRA-14124 or CASSANDRA-14125

> Refactor write path
> ---
>
> Key: CASSANDRA-14118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14118
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Major
>
> As part of the pluggable storage engine effort, we'd like to modularize the 
> write path related code, make it to be independent from existing storage 
> engine implementation details.
> For now, refer to 
> https://docs.google.com/document/d/1suZlvhzgB6NIyBNpM9nxoHxz_Ri7qAm-UEO8v8AIFsc
>  for high level designs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13396:
-

[~ehubert] I can successfully apply your patch now. I moved the logback jars 
out of the way, added slf4j-jdk14-1.7.7.jar into lib, and was able to bring up 
cassandra without problem with the patch. Got this message as output:

{noformat}
WARNING: You are using Cassandra with an unsupported deployment. The intended 
logging implementation library logback is not used by slf4j. Detected slf4j 
binding: org.slf4j.impl.JDK14LoggerFactory. You will not be able to dynamically 
manage log levels via JMX and may have performance or other issues.
{noformat} 

Thus the code went down the {{else}} block.

Review will continue ...

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch, 
> CASSANDRA-13396_ehubert_2.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13396:
-

hmm, yeah those aren't great options. I think we can stick with the 
{{StaticLoggerBinder}} while we're still on slf4j < 1.8, to keep it simple. 
Maybe we can include a note for the future for when we do upgrade slf4j 1.8. 
wdyt?

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch, 
> CASSANDRA-13396_ehubert_2.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-12151) Audit logging for database activity

[Dinesh Joshi (JIRA)]

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

Dinesh Joshi updated CASSANDRA-12151:
-
Status: Patch Available  (was: Awaiting Feedback)

> Audit logging for database activity
> ---
>
> Key: CASSANDRA-12151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12151
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: stefan setyadi
>Assignee: Vinay Chella
>Priority: Major
> Fix For: 4.x
>
> Attachments: 12151.txt, CASSANDRA_12151-benchmark.html, 
> DesignProposal_AuditingFeature_ApacheCassandra_v1.docx
>
>
> we would like a way to enable cassandra to log database activity being done 
> on our server.
> It should show username, remote address, timestamp, action type, keyspace, 
> column family, and the query statement.
> it should also be able to log connection attempt and changes to the 
> user/roles.
> I was thinking of making a new keyspace and insert an entry for every 
> activity that occurs.
> Then It would be possible to query for specific activity or a query targeting 
> a specific keyspace and column family.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-12151) Audit logging for database activity

[Dinesh Joshi (JIRA)]

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

Dinesh Joshi commented on CASSANDRA-12151:
--

Hey [~vinaykumarcse], 
 # {{AuditLogEntry.host}} - this should be final. You should use 
{{FBUtilities::getBroadcastAddressAndPort}} instead for completeness sake.
 # {{AuditLogEntry}} - variables {{source, srcPort, user, type}} could be made 
final
 # {{AuditLogEntry}} - line 47 Do you need to create a new Date object for each 
entry? How about using {{System.currentTimeMillis()}} instead?
 # {{AuditLogFilter.logger}} - this needs to be private
 # {{AuditLogFilter::loadFilters}} - consider using {{private volatile 
ImmutableSet}} instead of {{AtomicReferences}} to mutable sets. The class 
invariant should be that once constructed none of the sets should be null.
 # Initialization can be simplified like this - {{excludedUsers = 
ImmutableSet.of(DatabaseDescriptor.getAuditLoggingOptions().excluded_users.split(","));}}
 # Make {{AuditLogFilter}} constructor private
 # {{AuditLogFilter}}'s constructor - Do not call a public overridable method 
{{loadFilters}} in a constructor. See: 
[https://wiki.sei.cmu.edu/confluence/display/java/MET05-J.+Ensure+that+constructors+do+not+call+overridable+methods]
 # {{AuditLogFilter:: isFiltered}} - You can return directly at line 137 and 
get rid of {{isExcluded}} variable You can get rid of {{isIncluded}} as well 
and return at line 148. Let the control fall through to line 153 and it will 
return false. Furthermore, If you check the sets during initialization and 
ensure that they're mutually exclusive, your logic simplifies to {{if 
(includedSet.contains(object)) return false; else if 
(excludedSet.contains(object)}) return true;}}
 # {{AuditLogManager.logger}} - this needs to be private
 # {{AuditLogManager::logError}} - get rid of this method as it is not used 
anywhere
 # {{AuditLogUtil.DEFAULT_SOURCE}} - this should be {{0.0.0.0/0}} for IPv4 and 
{{::/0}} for IPv6. This are used to represent "unknown or unspecified" 
addresses.
 # {{IAuditLogContext.AuditLogContext}} - please make all the class variables 
final.
 # {{CreateTypeStatement, AlterTypeStatement, DropTypeStatement}} all have 
{{getStringTypeName}}. Since it's not being used anywhere except inside the 
class, you can get rid of it.

> Audit logging for database activity
> ---
>
> Key: CASSANDRA-12151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12151
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: stefan setyadi
>Assignee: Vinay Chella
>Priority: Major
> Fix For: 4.x
>
> Attachments: 12151.txt, CASSANDRA_12151-benchmark.html, 
> DesignProposal_AuditingFeature_ApacheCassandra_v1.docx
>
>
> we would like a way to enable cassandra to log database activity being done 
> on our server.
> It should show username, remote address, timestamp, action type, keyspace, 
> column family, and the query statement.
> it should also be able to log connection attempt and changes to the 
> user/roles.
> I was thinking of making a new keyspace and insert an entry for every 
> activity that occurs.
> Then It would be possible to query for specific activity or a query targeting 
> a specific keyspace and column family.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Eric Hubert (JIRA)]

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

Eric Hubert commented on CASSANDRA-13396:
-

I'm willing to test this out, but I think for slf4j >=1.8 we may need something 
like the following untested litte utility method to do the job of determining 
the binding
{code}
private static SLF4JServiceProvider determineSlf4jProvider() 
{
ServiceLoader serviceLoader = 
ServiceLoader.load(SLF4JServiceProvider.class);
Iterator serviceIterator = 
serviceLoader.iterator();
if (serviceIterator.hasNext()) 
{
return serviceIterator.next();
} else {
return new NOPServiceProvider()
}
}
{code}
or via reflection make org.slf4j.LoggerFactory#getProvider() accessible and 
call it
or provde an own class in package org.slf4j and wrap this static message call 
to this package-scoped method.

Maybe this is all not necessary and one can directly work with public 
org.slf4j.LoggerFactory#getILoggerFactory() using the bound provider to return 
a implementation-specific factory. As said, I'll happily have a closer look at 
this. I'm pretty sure something which can be addressed rather easily. The 
latter might even be somehow possible to use for a compatible implementation 
although returned implementation classes are very likely completely different 
for those slf4j versions.

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch, 
> CASSANDRA-13396_ehubert_2.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Eric Hubert (JIRA)]

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

Eric Hubert commented on CASSANDRA-13396:
-

Hi Jason! Sorry about the patch file. I now quickly recreated it from command 
line using git diff after pulling all updates from the 3.11 branch and attached 
it as  [^CASSANDRA-13396_ehubert_2.patch].
Regarding your question about alternatives to determine the logging 
implementation slf4j bound to when using slf4j >= 1.8 I do not think this will 
be much related to Jigsaw modularization (although I may be wrong). Looks like 
they make use of the long existing ServiceLoader JDK implementation (AFAIK 
since JDK6). I happily offer to investigate this. Other alternatives to simply 
do something similar by attempting to load specific implementation classes via 
reflection is by far not as elegant if you ask me.


> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch, 
> CASSANDRA-13396_ehubert_2.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Eric Hubert (JIRA)]

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

Eric Hubert updated CASSANDRA-13396:

Attachment: CASSANDRA-13396_ehubert_2.patch

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch, 
> CASSANDRA-13396_ehubert_2.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Jason Brown (JIRA)]

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

Jason Brown edited comment on CASSANDRA-13396 at 3/23/18 10:05 PM:
---

Looks like you are using {{StaticLoggerBinder}} to figure out which logging 
implementation to use. That seems 
[deprecated|https://www.slf4j.org/faq.html#changesInVersion18] as of slf4j v1.8 
(soon to be released), in lieu of some JIgsaw modularization. I have absolutely 
zero desire to investigate that modularization, wrt to cassandra as a whole. 
What are the alternatives here? Remaining on the current version of slf4j is 
certainly an option

ftr, 3.11 uses slf4j 1.7.7


was (Author: jasobrown):
Looks like you are using {{StaticLoggerBinder}} to figure out which logging 
implementation to use. That seems 
[deprecated|https://www.slf4j.org/faq.html#changesInVersion18] as of slf4j v1.8 
(soon to be released), in lieu of some JIgsaw modularization. I have absolutely 
zero desire to investigate that modularization. What are the alternatives here?

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13396:
-

Looks like you are using {{StaticLoggerBinder}} to figure out which logging 
implementation to use. That seems 
[deprecated|https://www.slf4j.org/faq.html#changesInVersion18] as of slf4j v1.8 
(soon to be released), in lieu of some JIgsaw modularization. I have absolutely 
zero desire to investigate that modularization. What are the alternatives here?

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-13396:
-

[~ehubert] the attached 'patch' file completely fails to apply to 
cassandra-3.11. Can you either push up a git patch or diff file, or just push 
your branch up to your github repo and share the link?  Reading the code in the 
attachment now

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14118) Refactor write path

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-14118:
---

Then I misunderstood Blake's comment:
{quote}You haven't abstracted all of the storage layer implementation details 
though. You should be able to step through the entire local write path without 
seeing anything related to commit logs, caches, sstables, or memtables.|
{quote}
 I thought he wanted me to abstract the commit logs and caches as well.  

Let me put them back to the CassandraWriteHandler implementation then.

> Refactor write path
> ---
>
> Key: CASSANDRA-14118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14118
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Major
>
> As part of the pluggable storage engine effort, we'd like to modularize the 
> write path related code, make it to be independent from existing storage 
> engine implementation details.
> For now, refer to 
> https://docs.google.com/document/d/1suZlvhzgB6NIyBNpM9nxoHxz_Ri7qAm-UEO8v8AIFsc
>  for high level designs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-7272) Add "Major" Compaction to LCS and split sstables during STCS major compaction

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-7272:
---
Summary: Add "Major" Compaction to LCS and split sstables during STCS major 
compaction  (was: Add "Major" Compaction to LCS )

> Add "Major" Compaction to LCS and split sstables during STCS major compaction
> -
>
> Key: CASSANDRA-7272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7272
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: T Jake Luciani
>Assignee: Marcus Eriksson
>Priority: Minor
>  Labels: compaction, docs-impacting, lcs
> Fix For: 2.2.0 beta 1
>
>
> LCS has a number of minor issues (maybe major depending on your perspective).
> LCS is primarily used for wide rows so for instance when you repair data in 
> LCS you end up with a copy of an entire repaired row in L0.  Over time if you 
> repair you end up with multiple copies of a row in L0 - L5.  This can make 
> predicting disk usage confusing.  
> Another issue is cleaning up tombstoned data.  If a tombstone lives in level 
> 1 and data for the cell lives in level 5 the data will not be reclaimed from 
> disk until the tombstone reaches level 5.
> I propose we add a "major" compaction for LCS that forces consolidation of 
> data to level 5 to address these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14118) Refactor write path

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14118:
---

[~JoshuaMcKenzie] in his comment, and [~bdeggleston] before him, explicitly 
mentioned that commit log and cache are specific implementation details of 
Cassandra's storage engine. You don't 'abstract' them - you make them part of 
the Cassandra {{WriteHandler}} implementation, in your terminology.

 

And you don't do that by writing code like this:
{code:java}
if (writeHandler.hasCommitLog() && writeCommitLog)
{
Tracing.trace("Appending to commitlog");
commitLogPosition = writeHandler.writeCommitLog(mutation);
}{code}
This is *not* how you 'abstract commit log'. External code shouldn't even know 
about the commitlog in this scenario. Writing to the commitlog - including the 
decision to do so - should be inside the default engine's default 
implementation of {{apply()}}.

Same goes for caching. This is not abstracting things away. I don't know what 
this is.

> Refactor write path
> ---
>
> Key: CASSANDRA-14118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14118
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Major
>
> As part of the pluggable storage engine effort, we'd like to modularize the 
> write path related code, make it to be independent from existing storage 
> engine implementation details.
> For now, refer to 
> https://docs.google.com/document/d/1suZlvhzgB6NIyBNpM9nxoHxz_Ri7qAm-UEO8v8AIFsc
>  for high level designs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14340) Refactor ColumnFamilyStore to Table

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14340:
---

Seems like I accidentally a word. What I meant: forcing people to change their 
logging settings because of a class rename is perfectly acceptable. Breaking 
JMX compatibility is less so. 

> Refactor ColumnFamilyStore to Table
> ---
>
> Key: CASSANDRA-14340
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14340
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Major
>
> This end result of this should change the ColumnFamily store, 
> ColumnFamilyStoreMBean, and tests that reference them by name.
> Deserves a note in news as this will break JMX compatibility and affect 
> scripts which change log level by class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14118) Refactor write path

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14118:
---

I feel like you either aren't listening, or are intentionally misinterpreting 
Blake's comments - and it's not helping.

You keep creating these 'Handler' classes and hacking 'pluggability' sideways 
into {{ColumnFamilyStore}} instead of abstracting away the store itself. As it 
was explained before - multiple times - what we want is not shims, but CFS 
(soon to be renamed to {{Table}}) and {{Keyspace}} classes becoming interfaces, 
with current classes becoming just some possible implementations of them.

> Refactor write path
> ---
>
> Key: CASSANDRA-14118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14118
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Major
>
> As part of the pluggable storage engine effort, we'd like to modularize the 
> write path related code, make it to be independent from existing storage 
> engine implementation details.
> For now, refer to 
> https://docs.google.com/document/d/1suZlvhzgB6NIyBNpM9nxoHxz_Ri7qAm-UEO8v8AIFsc
>  for high level designs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14330) Handle repeat open bound from SRP in read repair

[Jeremy Hanna (JIRA)]

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

Jeremy Hanna updated CASSANDRA-14330:
-
Description: 
If there is an open range tombstone in an iterator, a short read protection 
request for it will include a repeat open bound. Currently, {{DataResolver}} 
doesn't expect this, and will raise an assertion, timing out the request:
{code:java}
java.lang.AssertionError: Error merging RTs on test.test: merged=null, 
versions=[Marker EXCL_START_BOUND(0)@0, null], sources={[/127.0.0.1, 
/127.0.0.2]}, responses:
/127.0.0.1 => [test.test] key=0 
partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
columns=[[] | []]
   Row[info=[ts=1] ]: ck=0 | ,
   /127.0.0.2 => [test.test] key=0 
partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
columns=[[] | []]
   Row[info=[ts=-9223372036854775808] del=deletedAt=1, 
localDeletion=1521572669 ]: ck=0 |
   Row[info=[ts=1] ]: ck=1 | 
{code}
As this is a completely normal/common scenario, we should allow for this, and 
relax the assertion.

Additionally, the linked branch makes the re-throwing {{AssertionError}} more 
detailed and more correct: the responses are now printed out in the correct 
order, respecting {{isReversed}}, the command causing the assertion is now 
logged, as is {{isReversed}} itself, and local deletion times for RTs.

  was:
If there is an open range tombstone in an iterator, a short read protection 
request for it will include a repeat open bound. Currently, {{DataResolver}} 
doesn't expect this, and will raise an assertion, timing out the request:

{code}
java.lang.AssertionError: Error merging RTs on test.test: merged=null, 
versions=[Marker EXCL_START_BOUND(0)@0, null], sources={[/127.0.0.1, 
/127.0.0.2]}, responses:
/127.0.0.1 => [test.test] key=0 
partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
columns=[[] | []]
   Row[info=[ts=1] ]: ck=0 | ,
   /127.0.0.2 => [test.test] key=0 
partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
columns=[[] | []]
   Row[info=[ts=-9223372036854775808] del=deletedAt=1, 
localDeletion=1521572669 ]: ck=0 |
   Row[info=[ts=1] ]: ck=1 | 
{code}

As this is a completely normal/common scenario, we should allow for this, and 
relax the assertion.

Additionally, the linked branch makes the re-trhowing {{AssertionError}} more 
detailed and more correct: the responses are now printed out in the correct 
order, respecting {{isReversed}}, the command causing the assertion is now 
logged, as is {{isReversed}} itself, and local deletion times for RTs.


> Handle repeat open bound from SRP in read repair
> 
>
> Key: CASSANDRA-14330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14330
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0, 3.0.17, 3.11.3
>
>
> If there is an open range tombstone in an iterator, a short read protection 
> request for it will include a repeat open bound. Currently, {{DataResolver}} 
> doesn't expect this, and will raise an assertion, timing out the request:
> {code:java}
> java.lang.AssertionError: Error merging RTs on test.test: merged=null, 
> versions=[Marker EXCL_START_BOUND(0)@0, null], sources={[/127.0.0.1, 
> /127.0.0.2]}, responses:
> /127.0.0.1 => [test.test] key=0 
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
> columns=[[] | []]
>Row[info=[ts=1] ]: ck=0 | ,
>/127.0.0.2 => [test.test] key=0 
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
> columns=[[] | []]
>Row[info=[ts=-9223372036854775808] del=deletedAt=1, 
> localDeletion=1521572669 ]: ck=0 |
>Row[info=[ts=1] ]: ck=1 | 
> {code}
> As this is a completely normal/common scenario, we should allow for this, and 
> relax the assertion.
> Additionally, the linked branch makes the re-throwing {{AssertionError}} more 
> detailed and more correct: the responses are now printed out in the correct 
> order, respecting {{isReversed}}, the command causing the assertion is now 
> logged, as is {{isReversed}} itself, and local deletion times for RTs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14340) Refactor ColumnFamilyStore to Table

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-14340:


Table works.  Re: JMX compatibility, do you mean for logging or in general?

> Refactor ColumnFamilyStore to Table
> ---
>
> Key: CASSANDRA-14340
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14340
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Major
>
> This end result of this should change the ColumnFamily store, 
> ColumnFamilyStoreMBean, and tests that reference them by name.
> Deserves a note in news as this will break JMX compatibility and affect 
> scripts which change log level by class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14340) Refactor ColumnFamilyStore to Table

[Jon Haddad (JIRA)]

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

Jon Haddad updated CASSANDRA-14340:
---
Summary: Refactor ColumnFamilyStore to Table  (was: Refactor 
ColumnFamilyStore to TableStoer)

> Refactor ColumnFamilyStore to Table
> ---
>
> Key: CASSANDRA-14340
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14340
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Major
>
> This end result of this should change the ColumnFamily store, 
> ColumnFamilyStoreMBean, and tests that reference them by name.
> Deserves a note in news as this will break JMX compatibility and affect 
> scripts which change log level by class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-7622) Implement virtual tables

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-7622:


ftr, [~bdeggleston], [~dikanggu], and I are working on the pluggable storage 
engine right now. It's not our top priority, but we should get the vast 
majority of it completed for 4.0 (probably within a month or two .. no 
guarantees on that, though).

> Implement virtual tables
> 
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Chris Lohfink
>Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14340) Refactor ColumnFamilyStore to TableStoer

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14340:
---

And while logging by class is fine - please find a way to maintain JMX 
compatibility here.

> Refactor ColumnFamilyStore to TableStoer
> 
>
> Key: CASSANDRA-14340
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14340
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Major
>
> This end result of this should change the ColumnFamily store, 
> ColumnFamilyStoreMBean, and tests that reference them by name.
> Deserves a note in news as this will break JMX compatibility and affect 
> scripts which change log level by class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14340) Refactor ColumnFamilyStore to TableStoer

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14340:
---

If you do - which I'd still rather you didn't - then maybe consider renaming to 
{{Table}} instead? We don't have a {{KeyspaceStore}} after all.

> Refactor ColumnFamilyStore to TableStoer
> 
>
> Key: CASSANDRA-14340
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14340
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Major
>
> This end result of this should change the ColumnFamily store, 
> ColumnFamilyStoreMBean, and tests that reference them by name.
> Deserves a note in news as this will break JMX compatibility and affect 
> scripts which change log level by class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14343) CF -> Tablename Comment cleanup

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-14343:
--

 Summary: CF -> Tablename Comment cleanup
 Key: CASSANDRA-14343
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14343
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jon Haddad
Assignee: Jon Haddad


There's going to be sporadic comments in the codebase referring to column 
families, these should be updated to tables.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14342) Refactor getColumnFamilyStore() to getTableStore()

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-14342:
--

 Summary: Refactor getColumnFamilyStore() to getTableStore()
 Key: CASSANDRA-14342
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14342
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jon Haddad
Assignee: Jon Haddad






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14341) Refactor org.apache.cassandra.cql3.CFName to TableName

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-14341:
--

 Summary: Refactor org.apache.cassandra.cql3.CFName to TableName
 Key: CASSANDRA-14341
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14341
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Jon Haddad
Assignee: Jon Haddad






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14340) Refactor ColumnFamilyStore to TableStoer

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-14340:
--

 Summary: Refactor ColumnFamilyStore to TableStoer
 Key: CASSANDRA-14340
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14340
 Project: Cassandra
  Issue Type: Sub-task
  Components: Core
Reporter: Jon Haddad
Assignee: Jon Haddad


This end result of this should change the ColumnFamily store, 
ColumnFamilyStoreMBean, and tests that reference them by name.

Deserves a note in news as this will break JMX compatibility and affect scripts 
which change log level by class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14339) Modernize Internal Vocabulary

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-14339:
--

 Summary: Modernize Internal Vocabulary
 Key: CASSANDRA-14339
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14339
 Project: Cassandra
  Issue Type: Task
  Components: Core
Reporter: Jon Haddad
Assignee: Jon Haddad
 Fix For: 4.x


This is an umbrella ticket for all modifications necessary to update the code 
base from old Thrift-centric terminology to CQL terminology.  References to 
Column families should be completely removed at the close of this issue, rows 
should mean CQL rows, and "wide row" = partition.  

Each sub ticket should be as small of a refactor as possible.  For instance, 
the rename of a single class should only touch the class, with a follow up 
ticket for the variable names, methods, etc, to keep the scope of each refactor 
to a minimum.  The exception to this are the comments that are associated with 
a block of code, which should be addressed with the ticket.

Ensure changes that affect JMX are thoroughly tested, this should be covered by 
our utests & dtests, but care should be taken in case they are not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14058) Refactor read executor and response resolver, abstract read repair

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-14058:
-

Thanks [~iamaleksey], I'll open a Jira next week to fix

> Refactor read executor and response resolver, abstract read repair
> --
>
> Key: CASSANDRA-14058
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14058
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Major
> Fix For: 4.0
>
>
> CASSANDRA-10726 is stuck right now because the state of 
> {{AbstractReadExecutor}} and {{DataResolver}} make it difficult to cleanly 
> implement. It also looks like some additional read repair strategies might be 
> added. This goal of this ticket is to clean up the structure of some of the 
> read path components to make CASSANDRA-10726 doable, and additional read 
> repair strategies possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-7622) Implement virtual tables

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-7622:
--

[~cnlwsu] that's a fair point. Still, I want to outline the purist vision 
anyway - if you don't mind. Maybe then we can meet somewhere in the middle, or 
at least make sure that we don't commit to anything sticky that would be hard 
to undo/redo.

> Implement virtual tables
> 
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Chris Lohfink
>Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14252) Use zero as default score in DynamicEndpointSnitch

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-14252:
---

sure, will do.

> Use zero as default score in DynamicEndpointSnitch
> --
>
> Key: CASSANDRA-14252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14252
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Major
> Fix For: 4.0, 3.0.17, 3.11.3
>
> Attachments: IMG_3180.jpg
>
>
> The problem I want to solve is that I found in our deployment, one slow but 
> alive data node can slow down the whole cluster, even caused timeout of our 
> requests. 
> We are using DynamicEndpointSnitch, with badness_threshold 0.1. I expect the 
> DynamicEndpointSnitch switch to sortByProximityWithScore, if local data node 
> latency is too high.
> I added some debug log, and figured out that in a lot of cases, the score 
> from remote data node was not populated, so the fallback to 
> sortByProximityWithScore never happened. That's why a single slow data node, 
> can cause huge problems to the whole cluster.
> In this jira, I'd like to use zero as default score, so that we will get a 
> chance to try remote data node, if local one is slow. 
> I tested it in our test cluster, it improved the client latency in single 
> slow data node case significantly.  
> I flag this as a Bug, because it caused problems to our use cases multiple 
> times.
>   logs ===
> _2018-02-21_23:08:57.54145 WARN 23:08:57 [RPC-Thread:978]: 
> sortByProximityWithBadness: after sorting by proximity, addresses order 
> change to [ip1, ip2], with scores [1.0]_
>  _2018-02-21_23:08:57.54319 WARN 23:08:57 [RPC-Thread:967]: 
> sortByProximityWithBadness: after sorting by proximity, addresses order 
> change to [ip1, ip2], with scores [0.0]_
>  _2018-02-21_23:08:57.55111 WARN 23:08:57 [RPC-Thread:453]: 
> sortByProximityWithBadness: after sorting by proximity, addresses order 
> change to [ip1, ip2], with scores [1.0]_
>  _2018-02-21_23:08:57.55687 WARN 23:08:57 [RPC-Thread:753]: 
> sortByProximityWithBadness: after sorting by proximity, addresses order 
> change to [ip1, ip2], with scores [1.0]_
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-7622) Implement virtual tables

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-7622:
--

I was actually thinking of after pluggable storage jira, giving this another 
shot as it will definitely provide a cleaner interface to attach this too. 
Waiting possibly year(s) for that to get finished, merged and then rebuilding 
this however would be unfortunate. 

Maybe just for the operational purpose virtual tables being able to expose the 
internals via cql would be great. Even if it means a bit of work to rework them 
later with a better interface.

> Implement virtual tables
> 
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Chris Lohfink
>Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-7622) Implement virtual tables

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-7622:
--

I like what this exposes, but I'm not sure I'm a fan of the abstraction level 
it operates on. Doing this in a way that I would consider proper would involve 
quite a bit more change - starting with exposing schema itself as a virtual 
keyspace. This is probably the first genuine use case for hypothetical 
pluggable storage engine implementation, now that I think of it.

 

I'll make a more detail comment some time next week.

> Implement virtual tables
> 
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Chris Lohfink
>Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Claude Warren (JIRA)]

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

Claude Warren commented on CASSANDRA-13396:
---

Scanning through the solution it looks good to me.  However, I have not merged 
it or tried it.  I have no objections to applying it.

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14330) Handle repeat open bound from SRP in read repair

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-14330:
--
   Resolution: Fixed
Fix Version/s: (was: 3.11.x)
   (was: 4.x)
   (was: 3.0.x)
   3.11.3
   3.0.17
   4.0
   Status: Resolved  (was: Patch Available)

> Handle repeat open bound from SRP in read repair
> 
>
> Key: CASSANDRA-14330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14330
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0, 3.0.17, 3.11.3
>
>
> If there is an open range tombstone in an iterator, a short read protection 
> request for it will include a repeat open bound. Currently, {{DataResolver}} 
> doesn't expect this, and will raise an assertion, timing out the request:
> {code}
> java.lang.AssertionError: Error merging RTs on test.test: merged=null, 
> versions=[Marker EXCL_START_BOUND(0)@0, null], sources={[/127.0.0.1, 
> /127.0.0.2]}, responses:
> /127.0.0.1 => [test.test] key=0 
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
> columns=[[] | []]
>Row[info=[ts=1] ]: ck=0 | ,
>/127.0.0.2 => [test.test] key=0 
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
> columns=[[] | []]
>Row[info=[ts=-9223372036854775808] del=deletedAt=1, 
> localDeletion=1521572669 ]: ck=0 |
>Row[info=[ts=1] ]: ck=1 | 
> {code}
> As this is a completely normal/common scenario, we should allow for this, and 
> relax the assertion.
> Additionally, the linked branch makes the re-trhowing {{AssertionError}} more 
> detailed and more correct: the responses are now printed out in the correct 
> order, respecting {{isReversed}}, the command causing the assertion is now 
> logged, as is {{isReversed}} itself, and local deletion times for RTs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14330) Handle repeat open bound from SRP in read repair

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14330:
---

Thanks for the prompt review, [~slebresne]

Committed as 
[3153c630c499edf3c523d8e5a3db6f1d6c52ad4c|https://github.com/apache/cassandra/commit/3153c630c499edf3c523d8e5a3db6f1d6c52ad4c]
 to 3.0 and merged upwards. Committed the dtest as 
[dac3d7535cc120a6615257fb9dd05988e9901dc4|https://github.com/apache/cassandra-dtest/commit/dac3d7535cc120a6615257fb9dd05988e9901dc4].

> Handle repeat open bound from SRP in read repair
> 
>
> Key: CASSANDRA-14330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14330
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0, 3.0.17, 3.11.3
>
>
> If there is an open range tombstone in an iterator, a short read protection 
> request for it will include a repeat open bound. Currently, {{DataResolver}} 
> doesn't expect this, and will raise an assertion, timing out the request:
> {code}
> java.lang.AssertionError: Error merging RTs on test.test: merged=null, 
> versions=[Marker EXCL_START_BOUND(0)@0, null], sources={[/127.0.0.1, 
> /127.0.0.2]}, responses:
> /127.0.0.1 => [test.test] key=0 
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
> columns=[[] | []]
>Row[info=[ts=1] ]: ck=0 | ,
>/127.0.0.2 => [test.test] key=0 
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
> columns=[[] | []]
>Row[info=[ts=-9223372036854775808] del=deletedAt=1, 
> localDeletion=1521572669 ]: ck=0 |
>Row[info=[ts=1] ]: ck=1 | 
> {code}
> As this is a completely normal/common scenario, we should allow for this, and 
> relax the assertion.
> Additionally, the linked branch makes the re-trhowing {{AssertionError}} more 
> detailed and more correct: the responses are now printed out in the correct 
> order, respecting {{isReversed}}, the command causing the assertion is now 
> logged, as is {{isReversed}} itself, and local deletion times for RTs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

cassandra-dtest git commit: Add regression test for CASSANDRA-14330

[aleksey]

Repository: cassandra-dtest
Updated Branches:
  refs/heads/master 0b4f34a9a -> dac3d7535


Add regression test for CASSANDRA-14330


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

Branch: refs/heads/master
Commit: dac3d7535cc120a6615257fb9dd05988e9901dc4
Parents: 0b4f34a
Author: Aleksey Yeschenko 
Authored: Tue Mar 20 17:54:48 2018 +
Committer: Aleksey Yeschenko 
Committed: Fri Mar 23 14:55:29 2018 +

--
 consistency_test.py | 54 
 1 file changed, 54 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/dac3d753/consistency_test.py
--
diff --git a/consistency_test.py b/consistency_test.py
index 368dba0..9a09b01 100644
--- a/consistency_test.py
+++ b/consistency_test.py
@@ -765,6 +765,60 @@ class TestAccuracy(TestHelper):
 class TestConsistency(Tester):
 
 @since('3.0')
+def test_14330(self):
+"""
+@jira_ticket CASSANDRA-14330
+
+A regression test to prove that we no longer trigger
+AssertionError during read repair in DataResolver
+when encountering a repeat open RT bound from short
+read protection responses.
+"""
+cluster = self.cluster
+
+# disable hinted handoff and set batch commit log so this doesn't 
interfere with the test
+cluster.set_configuration_options(values={'hinted_handoff_enabled': 
False})
+cluster.set_batch_commitlog(enabled=True)
+
+cluster.populate(2).start(wait_other_notice=True)
+node1, node2 = cluster.nodelist()
+
+session = self.patient_cql_connection(node2)
+
+query = "CREATE KEYSPACE test WITH replication = {'class': 
'NetworkTopologyStrategy', 'datacenter1': 2};"
+session.execute(query)
+
+query = 'CREATE TABLE test.test (pk int, ck int, PRIMARY KEY (pk, 
ck));'
+session.execute(query)
+
+# with all nodes up, insert an RT and 2 rows on every node
+#
+# node1 | RT[0...] 0 1
+# node2 | RT[0...] 0 1
+
+session.execute('DELETE FROM test.test USING TIMESTAMP 0 WHERE pk = 0 
AND ck >= 0;')
+session.execute('INSERT INTO test.test (pk, ck) VALUES (0, 0) USING 
TIMESTAMP 1;')
+session.execute('INSERT INTO test.test (pk, ck) VALUES (0, 1) USING 
TIMESTAMP 1;')
+
+# with node1 down, delete row 0 on node2
+#
+# node1 | RT[0...] 0 1
+# node2 | RT[0...] x 1
+
+node1.stop(wait_other_notice=True)
+session.execute('DELETE FROM test.test USING TIMESTAMP 1 WHERE pk = 0 
AND ck = 0;')
+node1.start(wait_other_notice=True, wait_for_binary_proto=True)
+
+# with both nodes up, make a LIMIT 1 read that would trigger a short 
read protection
+# request, which in turn will trigger the AssertionError in 
DataResolver (prior to
+# CASSANDRA-14330 fix)
+
+assert_all(session,
+   'SELECT ck FROM test.test WHERE pk = 0 LIMIT 1;',
+   [[1]],
+   cl=ConsistencyLevel.ALL)
+
+@since('3.0')
 def test_13911(self):
 """
 @jira_ticket CASSANDRA-13911


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

[jira] [Commented] (CASSANDRA-14252) Use zero as default score in DynamicEndpointSnitch

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14252:
---

I fixed the incorrect CHANGES.txt. Please follow the agreed upon process when 
committing things, or ask around if you aren't sure how to do it next time. 
Thanks.

> Use zero as default score in DynamicEndpointSnitch
> --
>
> Key: CASSANDRA-14252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14252
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Major
> Fix For: 4.0, 3.0.17, 3.11.3
>
> Attachments: IMG_3180.jpg
>
>
> The problem I want to solve is that I found in our deployment, one slow but 
> alive data node can slow down the whole cluster, even caused timeout of our 
> requests. 
> We are using DynamicEndpointSnitch, with badness_threshold 0.1. I expect the 
> DynamicEndpointSnitch switch to sortByProximityWithScore, if local data node 
> latency is too high.
> I added some debug log, and figured out that in a lot of cases, the score 
> from remote data node was not populated, so the fallback to 
> sortByProximityWithScore never happened. That's why a single slow data node, 
> can cause huge problems to the whole cluster.
> In this jira, I'd like to use zero as default score, so that we will get a 
> chance to try remote data node, if local one is slow. 
> I tested it in our test cluster, it improved the client latency in single 
> slow data node case significantly.  
> I flag this as a Bug, because it caused problems to our use cases multiple 
> times.
>   logs ===
> _2018-02-21_23:08:57.54145 WARN 23:08:57 [RPC-Thread:978]: 
> sortByProximityWithBadness: after sorting by proximity, addresses order 
> change to [ip1, ip2], with scores [1.0]_
>  _2018-02-21_23:08:57.54319 WARN 23:08:57 [RPC-Thread:967]: 
> sortByProximityWithBadness: after sorting by proximity, addresses order 
> change to [ip1, ip2], with scores [0.0]_
>  _2018-02-21_23:08:57.55111 WARN 23:08:57 [RPC-Thread:453]: 
> sortByProximityWithBadness: after sorting by proximity, addresses order 
> change to [ip1, ip2], with scores [1.0]_
>  _2018-02-21_23:08:57.55687 WARN 23:08:57 [RPC-Thread:753]: 
> sortByProximityWithBadness: after sorting by proximity, addresses order 
> change to [ip1, ip2], with scores [1.0]_
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[1/9] cassandra git commit: use zero as default score in DynamicEndpointSnitch

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 15bd10afb -> 3153c630c
  refs/heads/cassandra-3.11 29d6237a0 -> d2248f206
  refs/heads/trunk 8b7e96761 -> 39bcdcd32


use zero as default score in DynamicEndpointSnitch


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

Branch: refs/heads/cassandra-3.11
Commit: 15bd10afbfc5eda024e7048438b00bfc81a9e3ea
Parents: cccaf7c
Author: Dikang Gu 
Authored: Wed Feb 21 15:48:11 2018 -0800
Committer: Dikang Gu 
Committed: Tue Mar 20 15:09:32 2018 -0700

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 2 +-
 .../org/apache/cassandra/locator/DynamicEndpointSnitchTest.java| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/15bd10af/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6099b01..b967580 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.17
+ * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
  * Respect max hint window when hinting for LWT (CASSANDRA-14215)
  * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)
  * Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15bd10af/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 8c255f5..5356e8c 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -186,7 +186,7 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 {
 Double score = scores.get(inet);
 if (score == null)
-continue;
+score = 0.0;
 subsnitchOrderedScores.add(score);
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15bd10af/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java 
b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
index af7dc17..866cd82 100644
--- a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
+++ b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
@@ -92,7 +92,7 @@ public class DynamicEndpointSnitchTest
 assertEquals(order, dsnitch.getSortedListByProximity(self, 
Arrays.asList(host1, host2, host3, host4)));
 
 setScores(dsnitch, 20, hosts, 10, 10, 10);
-order = Arrays.asList(host1, host2, host3, host4);
+order = Arrays.asList(host4, host1, host2, host3);
 assertEquals(order, dsnitch.getSortedListByProximity(self, 
Arrays.asList(host1, host2, host3, host4)));
 }
 }


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

[8/9] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[aleksey]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: d2248f20641ac589e25293919963e3f43f377f55
Parents: 29d6237 3153c63
Author: Aleksey Yeshchenko 
Authored: Fri Mar 23 14:41:15 2018 +
Committer: Aleksey Yeshchenko 
Committed: Fri Mar 23 14:41:15 2018 +

--
 CHANGES.txt |  3 ++-
 .../org/apache/cassandra/db/ReadResponse.java   | 22 +++-
 .../db/rows/RangeTombstoneBoundMarker.java  |  2 +-
 .../db/rows/RangeTombstoneBoundaryMarker.java   |  5 +++-
 .../apache/cassandra/service/DataResolver.java  | 27 +++-
 5 files changed, 49 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/CHANGES.txt
--
diff --cc CHANGES.txt
index 27a25cc,d701a22..987b9f7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,10 -1,6 +1,11 @@@
 -3.0.17
 +3.11.3
-  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
 + * SASI tokenizer for simple delimiter based entries (CASSANDRA-14247)
 + * Fix Loss of digits when doing CAST from varint/bigint to decimal 
(CASSANDRA-14170)
 + * RateBasedBackPressure unnecessarily invokes a lock on the Guava 
RateLimiter (CASSANDRA-14163)
 + * Fix wildcard GROUP BY queries (CASSANDRA-14209)
 +Merged from 3.0:
+  * Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
+  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
   * Respect max hint window when hinting for LWT (CASSANDRA-14215)
   * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)
   * Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/src/java/org/apache/cassandra/db/ReadResponse.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
--
diff --cc src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
index fb94da3,0079114..f6ba149
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
@@@ -133,15 -138,9 +133,15 @@@ public class RangeTombstoneBoundMarker 
  deletion.digest(digest);
  }
  
 +@Override
 +public void digest(MessageDigest digest, Set columnsToExclude)
 +{
 +digest(digest);
 +}
 +
  public String toString(CFMetaData metadata)
  {
- return "Marker " + bound.toString(metadata) + '@' + 
deletion.markedForDeleteAt();
+ return String.format("Marker %s@%d/%d", bound.toString(metadata), 
deletion.markedForDeleteAt(), deletion.localDeletionTime());
  }
  
  @Override

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
diff --cc 
src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
index 9190ecf,c4bc2f2..f183309
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
@@@ -152,15 -151,12 +152,18 @@@ public class RangeTombstoneBoundaryMark
  startDeletion.digest(digest);
  }
  
 +@Override
 +public void digest(MessageDigest digest, Set columnsToExclude)
 +{
 +digest(digest);
 +}
 +
  public String toString(CFMetaData metadata)
  {
- return String.format("Marker %s@%d-%d", bound.toString(metadata), 
endDeletion.markedForDeleteAt(), startDeletion.markedForDeleteAt());
+ return String.format("Marker %s@%d/%d-%d/%d",
+  bound.toString(metadata),
+  endDeletion.markedForDeleteAt(), 
endDeletion.localDeletionTime(),
+  startDeletion.markedForDeleteAt(), 
startDeletion.localDeletionTime());
  }
  
  @Override

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/src/java/org/apache/cassandra/service/DataResolver.java
--


-
To unsubscribe, e-mail: 

[7/9] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[aleksey]

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: d2248f20641ac589e25293919963e3f43f377f55
Parents: 29d6237 3153c63
Author: Aleksey Yeshchenko 
Authored: Fri Mar 23 14:41:15 2018 +
Committer: Aleksey Yeshchenko 
Committed: Fri Mar 23 14:41:15 2018 +

--
 CHANGES.txt |  3 ++-
 .../org/apache/cassandra/db/ReadResponse.java   | 22 +++-
 .../db/rows/RangeTombstoneBoundMarker.java  |  2 +-
 .../db/rows/RangeTombstoneBoundaryMarker.java   |  5 +++-
 .../apache/cassandra/service/DataResolver.java  | 27 +++-
 5 files changed, 49 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/CHANGES.txt
--
diff --cc CHANGES.txt
index 27a25cc,d701a22..987b9f7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,10 -1,6 +1,11 @@@
 -3.0.17
 +3.11.3
-  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
 + * SASI tokenizer for simple delimiter based entries (CASSANDRA-14247)
 + * Fix Loss of digits when doing CAST from varint/bigint to decimal 
(CASSANDRA-14170)
 + * RateBasedBackPressure unnecessarily invokes a lock on the Guava 
RateLimiter (CASSANDRA-14163)
 + * Fix wildcard GROUP BY queries (CASSANDRA-14209)
 +Merged from 3.0:
+  * Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
+  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
   * Respect max hint window when hinting for LWT (CASSANDRA-14215)
   * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)
   * Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/src/java/org/apache/cassandra/db/ReadResponse.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
--
diff --cc src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
index fb94da3,0079114..f6ba149
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
@@@ -133,15 -138,9 +133,15 @@@ public class RangeTombstoneBoundMarker 
  deletion.digest(digest);
  }
  
 +@Override
 +public void digest(MessageDigest digest, Set columnsToExclude)
 +{
 +digest(digest);
 +}
 +
  public String toString(CFMetaData metadata)
  {
- return "Marker " + bound.toString(metadata) + '@' + 
deletion.markedForDeleteAt();
+ return String.format("Marker %s@%d/%d", bound.toString(metadata), 
deletion.markedForDeleteAt(), deletion.localDeletionTime());
  }
  
  @Override

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
diff --cc 
src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
index 9190ecf,c4bc2f2..f183309
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
@@@ -152,15 -151,12 +152,18 @@@ public class RangeTombstoneBoundaryMark
  startDeletion.digest(digest);
  }
  
 +@Override
 +public void digest(MessageDigest digest, Set columnsToExclude)
 +{
 +digest(digest);
 +}
 +
  public String toString(CFMetaData metadata)
  {
- return String.format("Marker %s@%d-%d", bound.toString(metadata), 
endDeletion.markedForDeleteAt(), startDeletion.markedForDeleteAt());
+ return String.format("Marker %s@%d/%d-%d/%d",
+  bound.toString(metadata),
+  endDeletion.markedForDeleteAt(), 
endDeletion.localDeletionTime(),
+  startDeletion.markedForDeleteAt(), 
startDeletion.localDeletionTime());
  }
  
  @Override

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d2248f20/src/java/org/apache/cassandra/service/DataResolver.java
--


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

[5/9] cassandra git commit: Handle repeat open bound from SRP in read repair

[aleksey]

Handle repeat open bound from SRP in read repair

patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-14330


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

Branch: refs/heads/trunk
Commit: 3153c630c499edf3c523d8e5a3db6f1d6c52ad4c
Parents: 15bd10a
Author: Aleksey Yeschenko 
Authored: Sat Mar 10 22:28:07 2018 +
Committer: Aleksey Yeshchenko 
Committed: Wed Mar 21 15:10:12 2018 +

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/db/ReadResponse.java   | 22 +++-
 .../db/rows/RangeTombstoneBoundMarker.java  |  2 +-
 .../db/rows/RangeTombstoneBoundaryMarker.java   |  5 +++-
 .../apache/cassandra/service/DataResolver.java  | 27 +++-
 5 files changed, 48 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b967580..d701a22 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.17
+ * Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
  * Respect max hint window when hinting for LWT (CASSANDRA-14215)
  * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/ReadResponse.java
--
diff --git a/src/java/org/apache/cassandra/db/ReadResponse.java 
b/src/java/org/apache/cassandra/db/ReadResponse.java
index c59d00a..bc44a1b 100644
--- a/src/java/org/apache/cassandra/db/ReadResponse.java
+++ b/src/java/org/apache/cassandra/db/ReadResponse.java
@@ -107,13 +107,33 @@ public abstract class ReadResponse
 try (UnfilteredRowIterator partition = iter.next())
 {
 if (partition.partitionKey().equals(key))
-return 
ImmutableBTreePartition.create(partition).toString();
+return toDebugString(partition, command.metadata());
 }
 }
 }
 return "";
 }
 
+private String toDebugString(UnfilteredRowIterator partition, CFMetaData 
metadata)
+{
+StringBuilder sb = new StringBuilder();
+
+sb.append(String.format("[%s.%s] key=%s partition_deletion=%s 
columns=%s",
+metadata.ksName,
+metadata.cfName,
+
metadata.getKeyValidator().getString(partition.partitionKey().getKey()),
+partition.partitionLevelDeletion(),
+partition.columns()));
+
+if (partition.staticRow() != Rows.EMPTY_STATIC_ROW)
+sb.append("\n
").append(partition.staticRow().toString(metadata, true));
+
+while (partition.hasNext())
+sb.append("\n").append(partition.next().toString(metadata, 
true));
+
+return sb.toString();
+}
+
 protected static ByteBuffer makeDigest(UnfilteredPartitionIterator 
iterator, ReadCommand command)
 {
 MessageDigest digest = FBUtilities.threadLocalMD5Digest();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
--
diff --git 
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java 
b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
index 6f4afa5..0079114 100644
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
@@ -140,7 +140,7 @@ public class RangeTombstoneBoundMarker extends 
AbstractRangeTombstoneMarker
 
 public String toString(CFMetaData metadata)
 {
-return "Marker " + bound.toString(metadata) + '@' + 
deletion.markedForDeleteAt();
+return String.format("Marker %s@%d/%d", bound.toString(metadata), 
deletion.markedForDeleteAt(), deletion.localDeletionTime());
 }
 
 @Override

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
diff --git 
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java 

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

[aleksey]

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/39bcdcd3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/39bcdcd3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/39bcdcd3

Branch: refs/heads/trunk
Commit: 39bcdcd32ea5dcfd372d4b3eaf10c1c3de0547fb
Parents: 8b7e967 d2248f2
Author: Aleksey Yeshchenko 
Authored: Fri Mar 23 14:49:51 2018 +
Committer: Aleksey Yeshchenko 
Committed: Fri Mar 23 14:49:51 2018 +

--
 CHANGES.txt |  3 ++-
 .../org/apache/cassandra/db/ReadResponse.java   | 22 +++-
 .../db/rows/RangeTombstoneBoundMarker.java  |  2 +-
 .../db/rows/RangeTombstoneBoundaryMarker.java   |  5 +++-
 .../reads/repair/RowIteratorMergeListener.java  | 27 +++-
 5 files changed, 49 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/39bcdcd3/CHANGES.txt
--
diff --cc CHANGES.txt
index d4e5e37,987b9f7..76803a8
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,213 -1,3 +1,212 @@@
 +4.0
 + * Fix scheduling of speculative retry threshold recalculation 
(CASSANDRA-14338)
 + * Add support for hybrid MIN(), MAX() speculative retry policies 
(CASSANDRA-14293)
 + * Correct and clarify SSLFactory.getSslContext method and call sites 
(CASSANDRA-14314)
-  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
 + * Handle static and partition deletion properly on 
ThrottledUnfilteredIterator (CASSANDRA-14315)
 + * NodeTool clientstats should show SSL Cipher (CASSANDRA-14322)
 + * Add ability to specify driver name and version (CASSANDRA-14275)
 + * Abstract streaming for pluggable storage (CASSANDRA-14115)
 + * Forced incremental repairs should promote sstables if they can 
(CASSANDRA-14294)
 + * Use Murmur3 for validation compactions (CASSANDRA-14002)
 + * Comma at the end of the seed list is interpretated as localhost 
(CASSANDRA-14285)
 + * Refactor read executor and response resolver, abstract read repair 
(CASSANDRA-14058)
 + * Add optional startup delay to wait until peers are ready (CASSANDRA-13993)
 + * Add a few options to nodetool verify (CASSANDRA-14201)
 + * CVE-2017-5929 Security vulnerability and redefine default log rotation 
policy (CASSANDRA-14183)
 + * Use JVM default SSL validation algorithm instead of custom default 
(CASSANDRA-13259)
 + * Better document in code InetAddressAndPort usage post 7544, incorporate 
port into UUIDGen node (CASSANDRA-14226)
 + * Fix sstablemetadata date string for minLocalDeletionTime (CASSANDRA-14132)
 + * Make it possible to change neverPurgeTombstones during runtime 
(CASSANDRA-14214)
 + * Remove GossipDigestSynVerbHandler#doSort() (CASSANDRA-14174)
 + * Add nodetool clientlist (CASSANDRA-13665)
 + * Revert ProtocolVersion changes from CASSANDRA-7544 (CASSANDRA-14211)
 + * Non-disruptive seed node list reload (CASSANDRA-14190)
 + * Nodetool tablehistograms to print statics for all the tables 
(CASSANDRA-14185)
 + * Migrate dtests to use pytest and python3 (CASSANDRA-14134)
 + * Allow storage port to be configurable per node (CASSANDRA-7544)
 + * Make sub-range selection for non-frozen collections return null instead of 
empty (CASSANDRA-14182)
 + * BloomFilter serialization format should not change byte ordering 
(CASSANDRA-9067)
 + * Remove unused on-heap BloomFilter implementation (CASSANDRA-14152)
 + * Delete temp test files on exit (CASSANDRA-14153)
 + * Make PartitionUpdate and Mutation immutable (CASSANDRA-13867)
 + * Fix CommitLogReplayer exception for CDC data (CASSANDRA-14066)
 + * Fix cassandra-stress startup failure (CASSANDRA-14106)
 + * Remove initialDirectories from CFS (CASSANDRA-13928)
 + * Fix trivial log format error (CASSANDRA-14015)
 + * Allow sstabledump to do a json object per partition (CASSANDRA-13848)
 + * Add option to optimise merkle tree comparison across replicas 
(CASSANDRA-3200)
 + * Remove unused and deprecated methods from AbstractCompactionStrategy 
(CASSANDRA-14081)
 + * Fix Distribution.average in cassandra-stress (CASSANDRA-14090)
 + * Support a means of logging all queries as they were invoked 
(CASSANDRA-13983)
 + * Presize collections (CASSANDRA-13760)
 + * Add GroupCommitLogService (CASSANDRA-13530)
 + * Parallelize initial materialized view build (CASSANDRA-12245)
 + * Fix flaky SecondaryIndexManagerTest.assert[Not]MarkedAsBuilt 
(CASSANDRA-13965)
 + * Make LWTs send resultset metadata on every request (CASSANDRA-13992)
 + * Fix flaky indexWithFailedInitializationIsNotQueryableAfterPartialRebuild 
(CASSANDRA-13963)
 + * Introduce leaf-only iterator (CASSANDRA-9988)
 + * Upgrade Guava to 23.3 and Airline to 0.8 (CASSANDRA-13997)
 + * 

[2/9] cassandra git commit: use zero as default score in DynamicEndpointSnitch

[aleksey]

use zero as default score in DynamicEndpointSnitch


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

Branch: refs/heads/trunk
Commit: 15bd10afbfc5eda024e7048438b00bfc81a9e3ea
Parents: cccaf7c
Author: Dikang Gu 
Authored: Wed Feb 21 15:48:11 2018 -0800
Committer: Dikang Gu 
Committed: Tue Mar 20 15:09:32 2018 -0700

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 2 +-
 .../org/apache/cassandra/locator/DynamicEndpointSnitchTest.java| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/15bd10af/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6099b01..b967580 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.17
+ * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
  * Respect max hint window when hinting for LWT (CASSANDRA-14215)
  * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)
  * Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15bd10af/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 8c255f5..5356e8c 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -186,7 +186,7 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 {
 Double score = scores.get(inet);
 if (score == null)
-continue;
+score = 0.0;
 subsnitchOrderedScores.add(score);
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15bd10af/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java 
b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
index af7dc17..866cd82 100644
--- a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
+++ b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
@@ -92,7 +92,7 @@ public class DynamicEndpointSnitchTest
 assertEquals(order, dsnitch.getSortedListByProximity(self, 
Arrays.asList(host1, host2, host3, host4)));
 
 setScores(dsnitch, 20, hosts, 10, 10, 10);
-order = Arrays.asList(host1, host2, host3, host4);
+order = Arrays.asList(host4, host1, host2, host3);
 assertEquals(order, dsnitch.getSortedListByProximity(self, 
Arrays.asList(host1, host2, host3, host4)));
 }
 }


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

[4/9] cassandra git commit: Handle repeat open bound from SRP in read repair

[aleksey]

Handle repeat open bound from SRP in read repair

patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-14330


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

Branch: refs/heads/cassandra-3.11
Commit: 3153c630c499edf3c523d8e5a3db6f1d6c52ad4c
Parents: 15bd10a
Author: Aleksey Yeschenko 
Authored: Sat Mar 10 22:28:07 2018 +
Committer: Aleksey Yeshchenko 
Committed: Wed Mar 21 15:10:12 2018 +

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/db/ReadResponse.java   | 22 +++-
 .../db/rows/RangeTombstoneBoundMarker.java  |  2 +-
 .../db/rows/RangeTombstoneBoundaryMarker.java   |  5 +++-
 .../apache/cassandra/service/DataResolver.java  | 27 +++-
 5 files changed, 48 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b967580..d701a22 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.17
+ * Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
  * Respect max hint window when hinting for LWT (CASSANDRA-14215)
  * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/ReadResponse.java
--
diff --git a/src/java/org/apache/cassandra/db/ReadResponse.java 
b/src/java/org/apache/cassandra/db/ReadResponse.java
index c59d00a..bc44a1b 100644
--- a/src/java/org/apache/cassandra/db/ReadResponse.java
+++ b/src/java/org/apache/cassandra/db/ReadResponse.java
@@ -107,13 +107,33 @@ public abstract class ReadResponse
 try (UnfilteredRowIterator partition = iter.next())
 {
 if (partition.partitionKey().equals(key))
-return 
ImmutableBTreePartition.create(partition).toString();
+return toDebugString(partition, command.metadata());
 }
 }
 }
 return "";
 }
 
+private String toDebugString(UnfilteredRowIterator partition, CFMetaData 
metadata)
+{
+StringBuilder sb = new StringBuilder();
+
+sb.append(String.format("[%s.%s] key=%s partition_deletion=%s 
columns=%s",
+metadata.ksName,
+metadata.cfName,
+
metadata.getKeyValidator().getString(partition.partitionKey().getKey()),
+partition.partitionLevelDeletion(),
+partition.columns()));
+
+if (partition.staticRow() != Rows.EMPTY_STATIC_ROW)
+sb.append("\n
").append(partition.staticRow().toString(metadata, true));
+
+while (partition.hasNext())
+sb.append("\n").append(partition.next().toString(metadata, 
true));
+
+return sb.toString();
+}
+
 protected static ByteBuffer makeDigest(UnfilteredPartitionIterator 
iterator, ReadCommand command)
 {
 MessageDigest digest = FBUtilities.threadLocalMD5Digest();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
--
diff --git 
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java 
b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
index 6f4afa5..0079114 100644
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
@@ -140,7 +140,7 @@ public class RangeTombstoneBoundMarker extends 
AbstractRangeTombstoneMarker
 
 public String toString(CFMetaData metadata)
 {
-return "Marker " + bound.toString(metadata) + '@' + 
deletion.markedForDeleteAt();
+return String.format("Marker %s@%d/%d", bound.toString(metadata), 
deletion.markedForDeleteAt(), deletion.localDeletionTime());
 }
 
 @Override

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
diff --git 
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java 

[6/9] cassandra git commit: Handle repeat open bound from SRP in read repair

[aleksey]

Handle repeat open bound from SRP in read repair

patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-14330


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

Branch: refs/heads/cassandra-3.0
Commit: 3153c630c499edf3c523d8e5a3db6f1d6c52ad4c
Parents: 15bd10a
Author: Aleksey Yeschenko 
Authored: Sat Mar 10 22:28:07 2018 +
Committer: Aleksey Yeshchenko 
Committed: Wed Mar 21 15:10:12 2018 +

--
 CHANGES.txt |  1 +
 .../org/apache/cassandra/db/ReadResponse.java   | 22 +++-
 .../db/rows/RangeTombstoneBoundMarker.java  |  2 +-
 .../db/rows/RangeTombstoneBoundaryMarker.java   |  5 +++-
 .../apache/cassandra/service/DataResolver.java  | 27 +++-
 5 files changed, 48 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b967580..d701a22 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.17
+ * Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
  * Respect max hint window when hinting for LWT (CASSANDRA-14215)
  * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/ReadResponse.java
--
diff --git a/src/java/org/apache/cassandra/db/ReadResponse.java 
b/src/java/org/apache/cassandra/db/ReadResponse.java
index c59d00a..bc44a1b 100644
--- a/src/java/org/apache/cassandra/db/ReadResponse.java
+++ b/src/java/org/apache/cassandra/db/ReadResponse.java
@@ -107,13 +107,33 @@ public abstract class ReadResponse
 try (UnfilteredRowIterator partition = iter.next())
 {
 if (partition.partitionKey().equals(key))
-return 
ImmutableBTreePartition.create(partition).toString();
+return toDebugString(partition, command.metadata());
 }
 }
 }
 return "";
 }
 
+private String toDebugString(UnfilteredRowIterator partition, CFMetaData 
metadata)
+{
+StringBuilder sb = new StringBuilder();
+
+sb.append(String.format("[%s.%s] key=%s partition_deletion=%s 
columns=%s",
+metadata.ksName,
+metadata.cfName,
+
metadata.getKeyValidator().getString(partition.partitionKey().getKey()),
+partition.partitionLevelDeletion(),
+partition.columns()));
+
+if (partition.staticRow() != Rows.EMPTY_STATIC_ROW)
+sb.append("\n
").append(partition.staticRow().toString(metadata, true));
+
+while (partition.hasNext())
+sb.append("\n").append(partition.next().toString(metadata, 
true));
+
+return sb.toString();
+}
+
 protected static ByteBuffer makeDigest(UnfilteredPartitionIterator 
iterator, ReadCommand command)
 {
 MessageDigest digest = FBUtilities.threadLocalMD5Digest();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
--
diff --git 
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java 
b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
index 6f4afa5..0079114 100644
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundMarker.java
@@ -140,7 +140,7 @@ public class RangeTombstoneBoundMarker extends 
AbstractRangeTombstoneMarker
 
 public String toString(CFMetaData metadata)
 {
-return "Marker " + bound.toString(metadata) + '@' + 
deletion.markedForDeleteAt();
+return String.format("Marker %s@%d/%d", bound.toString(metadata), 
deletion.markedForDeleteAt(), deletion.localDeletionTime());
 }
 
 @Override

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3153c630/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
diff --git 
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java 

[3/9] cassandra git commit: Use zero as default score in DynamicEndpointSnitch

[aleksey]

Use zero as default score in DynamicEndpointSnitch


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

Branch: refs/heads/trunk
Commit: 29d6237a00b577400c4b4a63989d41f1baa2aa60
Parents: 656cca7
Author: Dikang Gu 
Authored: Thu Feb 22 14:35:20 2018 -0800
Committer: Dikang Gu 
Committed: Tue Mar 20 15:10:06 2018 -0700

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java   | 2 +-
 .../org/apache/cassandra/locator/DynamicEndpointSnitchTest.java| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/29d6237a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bae967f..27a25cc 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.11.3
+ * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
  * SASI tokenizer for simple delimiter based entries (CASSANDRA-14247)
  * Fix Loss of digits when doing CAST from varint/bigint to decimal 
(CASSANDRA-14170)
  * RateBasedBackPressure unnecessarily invokes a lock on the Guava RateLimiter 
(CASSANDRA-14163)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/29d6237a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 42fc26c..dce25ee 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -234,7 +234,7 @@ public class DynamicEndpointSnitch extends 
AbstractEndpointSnitch implements ILa
 {
 Double score = scores.get(inet);
 if (score == null)
-continue;
+score = 0.0;
 subsnitchOrderedScores.add(score);
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/29d6237a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java 
b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
index 8a59a4a..051d2c2 100644
--- a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
+++ b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
@@ -101,7 +101,7 @@ public class DynamicEndpointSnitchTest
 assertEquals(order, dsnitch.getSortedListByProximity(self, 
Arrays.asList(host1, host2, host3, host4)));
 
 setScores(dsnitch, 20, hosts, 10, 10, 10);
-order = Arrays.asList(host1, host2, host3, host4);
+order = Arrays.asList(host4, host1, host2, host3);
 assertEquals(order, dsnitch.getSortedListByProximity(self, 
Arrays.asList(host1, host2, host3, host4)));
 }
 }


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

[jira] [Commented] (CASSANDRA-14330) Handle repeat open bound from SRP in read repair

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-14330:
--

+1, fix lgtm. Nice job tracking that down and on the minimal test.

> Handle repeat open bound from SRP in read repair
> 
>
> Key: CASSANDRA-14330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14330
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> If there is an open range tombstone in an iterator, a short read protection 
> request for it will include a repeat open bound. Currently, {{DataResolver}} 
> doesn't expect this, and will raise an assertion, timing out the request:
> {code}
> java.lang.AssertionError: Error merging RTs on test.test: merged=null, 
> versions=[Marker EXCL_START_BOUND(0)@0, null], sources={[/127.0.0.1, 
> /127.0.0.2]}, responses:
> /127.0.0.1 => [test.test] key=0 
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
> columns=[[] | []]
>Row[info=[ts=1] ]: ck=0 | ,
>/127.0.0.2 => [test.test] key=0 
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 
> columns=[[] | []]
>Row[info=[ts=-9223372036854775808] del=deletedAt=1, 
> localDeletion=1521572669 ]: ck=0 |
>Row[info=[ts=1] ]: ck=1 | 
> {code}
> As this is a completely normal/common scenario, we should allow for this, and 
> relax the assertion.
> Additionally, the linked branch makes the re-trhowing {{AssertionError}} more 
> detailed and more correct: the responses are now printed out in the correct 
> order, respecting {{isReversed}}, the command causing the assertion is now 
> logged, as is {{isReversed}} itself, and local deletion times for RTs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-14338:
--
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

> Fix scheduling of speculative retry threshold recalculation
> ---
>
> Key: CASSANDRA-14338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> Realized after committing CASSANDRA-14293 that it's slightly broken: when 
> updating from a static to a dynamic speculative retry policy, the refresher 
> will never be scheduled.
> Also realised that the whole thing is a bit dumb. We don't need a latency 
> calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
> that does in batch refresh thresholds for every table. It's one fewer thing 
> to manage, and allows to get rid of {{isDynamic()}} method in 
> {{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-14338:
--
Priority: Minor  (was: Major)

> Fix scheduling of speculative retry threshold recalculation
> ---
>
> Key: CASSANDRA-14338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 4.0
>
>
> Realized after committing CASSANDRA-14293 that it's slightly broken: when 
> updating from a static to a dynamic speculative retry policy, the refresher 
> will never be scheduled.
> Also realised that the whole thing is a bit dumb. We don't need a latency 
> calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
> that does in batch refresh thresholds for every table. It's one fewer thing 
> to manage, and allows to get rid of {{isDynamic()}} method in 
> {{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14338:
---

Committed as 
[8b7e96761f968b346aed08c0c201a8d40d801b19|https://github.com/apache/cassandra/commit/8b7e96761f968b346aed08c0c201a8d40d801b19],
 thanks.

> Fix scheduling of speculative retry threshold recalculation
> ---
>
> Key: CASSANDRA-14338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> Realized after committing CASSANDRA-14293 that it's slightly broken: when 
> updating from a static to a dynamic speculative retry policy, the refresher 
> will never be scheduled.
> Also realised that the whole thing is a bit dumb. We don't need a latency 
> calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
> that does in batch refresh thresholds for every table. It's one fewer thing 
> to manage, and allows to get rid of {{isDynamic()}} method in 
> {{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

cassandra git commit: Fix scheduling of speculative retry threshold recalculation

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk d6a67598f -> 8b7e96761


Fix scheduling of speculative retry threshold recalculation

patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe for
CASSANDRA-14338


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

Branch: refs/heads/trunk
Commit: 8b7e96761f968b346aed08c0c201a8d40d801b19
Parents: d6a6759
Author: Aleksey Yeshchenko 
Authored: Fri Mar 23 13:08:39 2018 +
Committer: Aleksey Yeshchenko 
Committed: Fri Mar 23 13:43:00 2018 +

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/ColumnFamilyStore.java  | 37 +++-
 .../cassandra/service/CassandraDaemon.java  |  8 +
 .../reads/AlwaysSpeculativeRetryPolicy.java |  6 
 .../reads/FixedSpeculativeRetryPolicy.java  |  6 
 .../reads/HybridSpeculativeRetryPolicy.java |  6 
 .../reads/NeverSpeculativeRetryPolicy.java  |  6 
 .../reads/PercentileSpeculativeRetryPolicy.java |  6 
 .../service/reads/SpeculativeRetryPolicy.java   |  2 --
 9 files changed, 21 insertions(+), 57 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8b7e9676/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ac5269c..d4e5e37 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Fix scheduling of speculative retry threshold recalculation 
(CASSANDRA-14338)
  * Add support for hybrid MIN(), MAX() speculative retry policies 
(CASSANDRA-14293)
  * Correct and clarify SSLFactory.getSslContext method and call sites 
(CASSANDRA-14314)
  * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8b7e9676/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java 
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index 52c280c..4f74667 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -77,7 +77,6 @@ import org.apache.cassandra.metrics.TableMetrics;
 import org.apache.cassandra.metrics.TableMetrics.Sampler;
 import org.apache.cassandra.schema.*;
 import org.apache.cassandra.schema.CompactionParams.TombstoneOption;
-import org.apache.cassandra.service.reads.SpeculativeRetryPolicy;
 import org.apache.cassandra.service.CacheService;
 import org.apache.cassandra.service.StorageService;
 import org.apache.cassandra.streaming.TableStreamManager;
@@ -214,7 +213,6 @@ public class ColumnFamilyStore implements 
ColumnFamilyStoreMBean
 
 public final TableMetrics metric;
 public volatile long sampleLatencyNanos;
-private final ScheduledFuture latencyCalculator;
 
 private final CassandraStreamManager streamManager;
 
@@ -442,35 +440,27 @@ public class ColumnFamilyStore implements 
ColumnFamilyStoreMBean
 {
 throw new RuntimeException(e);
 }
-
-SpeculativeRetryPolicy retryPolicy = 
metadata.get().params.speculativeRetry;
-logger.trace("retryPolicy for {} is {}", name, retryPolicy);
-if (!retryPolicy.isDynamic())
-{
-// avoid scheduling the task in the first place for 
non-dynamic speculative retry policies
-// e.g. always and never speculative policies will never 
change so we can just calculate once
-// and avoid doing unnecessary work every ReadRpcTimeout()
-sampleLatencyNanos = 
retryPolicy.calculateThreshold(metric.coordinatorReadLatency);
-latencyCalculator = null;
-}
-else
-{
-latencyCalculator = 
ScheduledExecutors.optionalTasks.scheduleWithFixedDelay(() ->
-{
-SpeculativeRetryPolicy retryPolicy1 = 
metadata.get().params.speculativeRetry;
-sampleLatencyNanos = 
retryPolicy1.calculateThreshold(metric.coordinatorReadLatency);
-}, DatabaseDescriptor.getReadRpcTimeout(), 
DatabaseDescriptor.getReadRpcTimeout(), TimeUnit.MILLISECONDS);
-}
 }
 else
 {
-latencyCalculator = 
ScheduledExecutors.optionalTasks.schedule(Runnables.doNothing(), 0, 
TimeUnit.NANOSECONDS);
 mbeanName = null;
 oldMBeanName= null;
 }
 streamManager = new CassandraStreamManager(this);
 }
 
+

[jira] [Commented] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14338:
---

Good call. I'd say in 3.0 this also should be fixed, so that a single exception 
there doesn't stop recalculating percentiles for the affected table.

Thanks for the review. Will commit once Circle is happy.

> Fix scheduling of speculative retry threshold recalculation
> ---
>
> Key: CASSANDRA-14338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> Realized after committing CASSANDRA-14293 that it's slightly broken: when 
> updating from a static to a dynamic speculative retry policy, the refresher 
> will never be scheduled.
> Also realised that the whole thing is a bit dumb. We don't need a latency 
> calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
> that does in batch refresh thresholds for every table. It's one fewer thing 
> to manage, and allows to get rid of {{isDynamic()}} method in 
> {{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-14338:
-

+1 LGTM.

I would just wrap the calculation in {{CFS::updateSpeculationThreshold}} in a 
try/catch so that an exception there doesn't cause future executions of the 
task to be suppressed.

> Fix scheduling of speculative retry threshold recalculation
> ---
>
> Key: CASSANDRA-14338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> Realized after committing CASSANDRA-14293 that it's slightly broken: when 
> updating from a static to a dynamic speculative retry policy, the refresher 
> will never be scheduled.
> Also realised that the whole thing is a bit dumb. We don't need a latency 
> calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
> that does in batch refresh thresholds for every table. It's one fewer thing 
> to manage, and allows to get rid of {{isDynamic()}} method in 
> {{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-14338:

Status: Ready to Commit  (was: Patch Available)

> Fix scheduling of speculative retry threshold recalculation
> ---
>
> Key: CASSANDRA-14338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> Realized after committing CASSANDRA-14293 that it's slightly broken: when 
> updating from a static to a dynamic speculative retry policy, the refresher 
> will never be scheduled.
> Also realised that the whole thing is a bit dumb. We don't need a latency 
> calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
> that does in batch refresh thresholds for every table. It's one fewer thing 
> to manage, and allows to get rid of {{isDynamic()}} method in 
> {{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-14338:
--
 Reviewer: Sam Tunnicliffe
Fix Version/s: (was: 4.x)
   4.0
   Status: Patch Available  (was: Open)

> Fix scheduling of speculative retry threshold recalculation
> ---
>
> Key: CASSANDRA-14338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> Realized after committing CASSANDRA-14293 that it's slightly broken: when 
> updating from a static to a dynamic speculative retry policy, the refresher 
> will never be scheduled.
> Also realised that the whole thing is a bit dumb. We don't need a latency 
> calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
> that does in batch refresh thresholds for every table. It's one fewer thing 
> to manage, and allows to get rid of {{isDynamic()}} method in 
> {{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14338:
---

4.0 branch: https://github.com/iamaleksey/cassandra/tree/14338-4.0

> Fix scheduling of speculative retry threshold recalculation
> ---
>
> Key: CASSANDRA-14338
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.x
>
>
> Realized after committing CASSANDRA-14293 that it's slightly broken: when 
> updating from a static to a dynamic speculative retry policy, the refresher 
> will never be scheduled.
> Also realised that the whole thing is a bit dumb. We don't need a latency 
> calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
> that does in batch refresh thresholds for every table. It's one fewer thing 
> to manage, and allows to get rid of {{isDynamic()}} method in 
> {{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (CASSANDRA-14338) Fix scheduling of speculative retry threshold recalculation

[Aleksey Yeschenko (JIRA)]

Aleksey Yeschenko created CASSANDRA-14338:
-

 Summary: Fix scheduling of speculative retry threshold 
recalculation
 Key: CASSANDRA-14338
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14338
 Project: Cassandra
  Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
 Fix For: 4.x


Realized after committing CASSANDRA-14293 that it's slightly broken: when 
updating from a static to a dynamic speculative retry policy, the refresher 
will never be scheduled.

Also realised that the whole thing is a bit dumb. We don't need a latency 
calculator runnable per {{ColumnFamilyStore}}, we should have one per node, 
that does in batch refresh thresholds for every table. It's one fewer thing to 
manage, and allows to get rid of {{isDynamic()}} method in 
{{SpeculativeRetryPolicy}}, which I thought was clever at the time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-13939) Mishandling of cells for removed/dropped columns when reading legacy files

[Gonzalo Maria de Salas (JIRA)]

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

Gonzalo Maria de Salas commented on CASSANDRA-13939:


Hi Sylvain 

can you help me to understand if this particular issue is solved in version 
3.11.1 please?

We are now in version 3.0.9 and planning next week to move to 3.11.1 because of 
this particular issue

I´ll appreciate your comments

thank you in advance

Regards

 

> Mishandling of cells for removed/dropped columns when reading legacy files
> --
>
> Key: CASSANDRA-13939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13939
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Major
> Fix For: 3.0.16, 3.11.2
>
>
> The tl;dr is that there is a bug in reading legacy files that can manifests 
> itself with a trace looking like this:
> {noformat}
> Exception (java.lang.IllegalStateException) encountered during startup: One 
> row required, 2 found
> java.lang.IllegalStateException: One row required, 2 found
> at 
> org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:84)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTableTimestamp(LegacySchemaMigrator.java:254)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTable(LegacySchemaMigrator.java:244)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readTables$7(LegacySchemaMigrator.java:238)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator$$Lambda$126/591203139.accept(Unknown
>  Source)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readTables(LegacySchemaMigrator.java:238)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readKeyspace(LegacySchemaMigrator.java:187)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.lambda$readSchema$4(LegacySchemaMigrator.java:178)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator$$Lambda$123/1612073393.accept(Unknown
>  Source)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at 
> org.apache.cassandra.schema.LegacySchemaMigrator.readSchema(LegacySchemaMigrator.java:178)
> {noformat}
> The reason this can happen has to do with the handling of legacy files. 
> Legacy files are cell based while the 3.0 storage engine is primarily row 
> based, so we group those cells into rows early in the deserialization process 
> (in {{UnfilteredDeserializer.OldFormatDeserializer}}), but in doing so, we 
> can only consider a row finished when we've either reach the end of the 
> partition/file, or when we've read a cell that doesn't belong to that row.  
> That second case means that when the deserializer returns a given row, the 
> underlying file pointer may actually not positioned at the end of that row, 
> but rather it may be past the first cell of the next row (which the 
> deserializer remembers for future use). Long story short, when we try to 
> detect if we're logically past our current index block in 
> {{AbstractIterator.IndexState#isPastCurrentBlock(}}), we can't simply rely on 
> the file pointer, which again may be a bit more advanced that we logically 
> are, and that's the reason for the "correction" in that method. That 
> correction is really just the amount of bytes remembered but not yet used in 
> the deserializer.
> That "correction" is sometimes wrong however and that's due to the fact that 
> in {{LegacyLayout#readLegacyAtom}}, if we get a cell for an dropped or 
> removed cell, we ignore that cell (which, in itself, is fine). Problem is 
> that this skipping is done within the {{LegacyLayout#readLegacyAtom}} method 
> but without {{UnfilteredDeserializer.OldFormatDeserializer}} knowing about 
> it. As such, the size of the skipped cell ends up being accounted in the 
> "correction" bytes for the next cell we read. Lo and behold, if such cell for 
> a removed/dropped column is both the last cell of a CQL row and just before 
> an index boundary (pretty unlikely in general btw, but definitively 
> possible), then the deserializer will count its size with the first cell of 
> the next row, which happens to also be the first cell of the next index 
> block.  And when the code then tries to figure out if it crossed an index 
> boundary, it will over-correct. That is, the {{indexState.updateBlock()}} 
> call at the start of {{SSTableIterator.ForwardIndexedReader#computeNext}} 
> will not work correctly.  This can then make the code return a row that is 
> after the requested slice end (and should thus not be returned) because it 
> doesn't compare that row to said 

[jira] [Commented] (CASSANDRA-13396) Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager

[Eric Hubert (JIRA)]

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

Eric Hubert commented on CASSANDRA-13396:
-

Anyone with some feedback on my submitted patch? I may have some time tomorrow 
to incorporate feedback/make adjustments etc, but next week might become rather 
busy.

> Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager
> 
>
> Key: CASSANDRA-13396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13396
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Eugene Fedotov
>Priority: Minor
> Attachments: CASSANDRA-13396_ehubert_1.patch
>
>
> https://www.mail-archive.com/user@cassandra.apache.org/msg51603.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY

[Francisco Fernandez (JIRA)]

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

Francisco Fernandez edited comment on CASSANDRA-14286 at 3/23/18 8:23 AM:
--

The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch|https://github.com/apache/cassandra/compare/cassandra-2.2...fcofdez:CASSANDRA-14286-2?expand=1]
 


was (Author: fcofdezc):
The problem was that columns were serialized as json and then discarded, while 
{{OrderingComparator}} expected those columns to be present. With this patch, 
all columns are present and only the json column is sent back to clients. It 
uses the same mechanism as the regular ordering of non-selected columns.

[Patch|https://github.com/apache/cassandra/compare/cassandra-2.2...fcofdez:CASSANDRA-14286?expand=1]
 

> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
> 
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b 
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM 
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
>   at java.util.Collections$SingletonList.get(Collections.java:4815) 
> ~[na:1.8.0_151]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
>  ~[apache-cassandra-3.11.1.jar:3.11.1]
>   at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) 
> ~[na:1.8.0_151]
>   at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
>   at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
>   at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON 
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual 
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (CASSANDRA-14337) cast function is not working in INSERT statement

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-14337:


This is not a bug. {{CAST}} function are for the moment only supported in the 
selection part of the {{SELECT}} statement.

Which is why I moved the ticket from {{bug}} to {{improvement.}}

> cast function is not working in INSERT statement
> 
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Priority: Major
> Fix For: 4.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>  
> fails with error 
> *no viable alternative at input '('*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14337) cast function is not working in INSERT statement

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-14337:
---
Fix Version/s: (was: 3.11.x)
   4.0

> cast function is not working in INSERT statement
> 
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Priority: Major
> Fix For: 4.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>  
> fails with error 
> *no viable alternative at input '('*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14337) cast function is not working in INSERT statement

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-14337:
---
Component/s: CQL

> cast function is not working in INSERT statement
> 
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Priority: Major
> Fix For: 4.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>  
> fails with error 
> *no viable alternative at input '('*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14337) cast function is not working in INSERT statement

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-14337:
---
Fix Version/s: (was: 4.0)
   4.x

> cast function is not working in INSERT statement
> 
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Priority: Major
> Fix For: 4.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>  
> fails with error 
> *no viable alternative at input '('*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (CASSANDRA-14337) cast function is not working in INSERT statement

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-14337:
---
Issue Type: Improvement  (was: Bug)

> cast function is not working in INSERT statement
> 
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
>  Issue Type: Improvement
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Priority: Major
> Fix For: 3.11.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>  
> fails with error 
> *no viable alternative at input '('*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (CASSANDRA-14336) sstableloader fails if sstables contains removed columns

[JIRA]

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

Hannu Kröger edited comment on CASSANDRA-14336 at 3/23/18 6:30 AM:
---

If this is really expected behaviour, then following flow won't always work:
 # Take snapshot on cluster A
 # Dump schema on cluster A
 # Load schema on cluster B
 # Load data with sstableloader on cluster B

I'm not 100% sure it would work even on if we were to load snapshot back to 
cluster A.

 

Here the step 4 will work only if

1) No columns were ever dropped

OR

2) Compactions have been run on all affected sstables after columns have been 
dropped

OR

3) nodetool upgradesstable --all was executed on cluster A

 

And I think this is not very practical. Also I don't think documented?


was (Author: hkroger):
If this is really expected behaviour, then following flow won't always work:

1) Take snapshot on cluster A

2) Dump schema on cluster A

3) Load schema on cluster B

4) Load data with sstableloader on cluster B

 

I'm not 100% sure it would work even on if we were to load snapshot back to 
cluster A.

 

Here the step 4 will work only if

1) No columns were ever dropped

OR

2) Compactions have been run on all affected sstables after columns have been 
dropped

OR

3) nodetool upgradesstable --all was executed on cluster A

 

And I think this is not very practical. Also I don't think documented?

> sstableloader fails if sstables contains removed columns
> 
>
> Key: CASSANDRA-14336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14336
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Jaydeepkumar Chovatia
>Priority: Major
>
> If I copy the schema and try to load in sstables with sstableloader, loading 
> sometimes fails with
> {code:java}
> Exception in thread "main" org.apache.cassandra.tools.BulkLoadException: 
> java.lang.RuntimeException: Failed to list files in /tmp/test/bug3_dest-acdc
>     at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:93)
>     at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:48)
> Caused by: java.lang.RuntimeException: Failed to list files in 
> /tmp/test/bug3_dest-acdc
>     at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:77)
>     at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:561)
>     at 
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:76)
>     at 
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:165)
>     at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:80)
>     ... 1 more
> Caused by: java.lang.RuntimeException: Unknown column d during deserialization
>     at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:321)
>     at 
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:440)
>     at 
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:121)
>     at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
>     at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
>     at java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:2969)
>     at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>     at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>     at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
>     at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>     at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
>     at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
>     at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
>     ... 5 more{code}
> This requires that we have dropped columns in the source table and sstables 
> exist from the "old schema" time.
> This can be very easily reproduced. I used following script:
> {code:java}
> KS=test
> SRCTABLE=bug3_source
> DESTTABLE=bug3_dest
> DATADIR=/usr/local/var/lib/cassandra/data
> TMPDIR=/tmp
> cqlsh -e "CREATE TABLE $KS.$SRCTABLE(a int primary key, b int, c int, d int);"
> cqlsh -e "CREATE TABLE $KS.$DESTTABLE(a int primary key, b int, c int);"
> cqlsh -e "INSERT INTO $KS.$SRCTABLE(a,b,c,d) values(1,2,3,4);"
> nodetool flush $KS $SRCTABLE
> cqlsh -e "ALTER TABLE $KS.$SRCTABLE DROP d;"
> nodetool flush $KS $SRCTABLE
> mkdir -p $TMPDIR/$KS/$DESTTABLE-acdc
> cp $DATADIR/$KS/$SRCTABLE-*/* $TMPDIR/$KS/$DESTTABLE-acdc
> sstableloader -d 127.0.0.1 

[jira] [Commented] (CASSANDRA-14336) sstableloader fails if sstables contains removed columns

[JIRA]

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

Hannu Kröger commented on CASSANDRA-14336:
--

If this is really expected behaviour, then following flow won't always work:

1) Take snapshot on cluster A

2) Dump schema on cluster A

3) Load schema on cluster B

4) Load data with sstableloader on cluster B

 

I'm not 100% sure it would work even on if we were to load snapshot back to 
cluster A.

 

Here the step 4 will work only if

1) No columns were ever dropped

OR

2) Compactions have been run on all affected sstables after columns have been 
dropped

OR

3) nodetool upgradesstable --all was executed on cluster A

 

And I think this is not very practical. Also I don't think documented?

> sstableloader fails if sstables contains removed columns
> 
>
> Key: CASSANDRA-14336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14336
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: Jaydeepkumar Chovatia
>Priority: Major
>
> If I copy the schema and try to load in sstables with sstableloader, loading 
> sometimes fails with
> {code:java}
> Exception in thread "main" org.apache.cassandra.tools.BulkLoadException: 
> java.lang.RuntimeException: Failed to list files in /tmp/test/bug3_dest-acdc
>     at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:93)
>     at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:48)
> Caused by: java.lang.RuntimeException: Failed to list files in 
> /tmp/test/bug3_dest-acdc
>     at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:77)
>     at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:561)
>     at 
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:76)
>     at 
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:165)
>     at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:80)
>     ... 1 more
> Caused by: java.lang.RuntimeException: Unknown column d during deserialization
>     at 
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:321)
>     at 
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:440)
>     at 
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:121)
>     at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
>     at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
>     at java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:2969)
>     at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>     at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>     at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
>     at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>     at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
>     at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
>     at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
>     ... 5 more{code}
> This requires that we have dropped columns in the source table and sstables 
> exist from the "old schema" time.
> This can be very easily reproduced. I used following script:
> {code:java}
> KS=test
> SRCTABLE=bug3_source
> DESTTABLE=bug3_dest
> DATADIR=/usr/local/var/lib/cassandra/data
> TMPDIR=/tmp
> cqlsh -e "CREATE TABLE $KS.$SRCTABLE(a int primary key, b int, c int, d int);"
> cqlsh -e "CREATE TABLE $KS.$DESTTABLE(a int primary key, b int, c int);"
> cqlsh -e "INSERT INTO $KS.$SRCTABLE(a,b,c,d) values(1,2,3,4);"
> nodetool flush $KS $SRCTABLE
> cqlsh -e "ALTER TABLE $KS.$SRCTABLE DROP d;"
> nodetool flush $KS $SRCTABLE
> mkdir -p $TMPDIR/$KS/$DESTTABLE-acdc
> cp $DATADIR/$KS/$SRCTABLE-*/* $TMPDIR/$KS/$DESTTABLE-acdc
> sstableloader -d 127.0.0.1 $TMPDIR/$KS/$DESTTABLE-acdc{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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