[jira] [Comment Edited] (CASSANDRA-13561) Purge TTL on expiration

[Andrew Whang (JIRA)]

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

Andrew Whang edited comment on CASSANDRA-13561 at 11/10/17 2:16 AM:


CASSANDRA-13643 seems to do something similar, but safer. I think we can close 
this out.


was (Author: whangsf):
CASSANDRA-13643 seems to do something similar, but safer. Closing this out.

> Purge TTL on expiration
> ---
>
> Key: CASSANDRA-13561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13561
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Andrew Whang
>Assignee: Andrew Whang
>Priority: Minor
> Fix For: 4.0
>
>
> Tables with mostly TTL columns tend to suffer from high droppable tombstone 
> ratio, which results in higher read latency, cpu utilization, and disk usage. 
> Expired TTL data become tombstones, and the nature of purging tombstones 
> during compaction (due to checking for overlapping SSTables) make them 
> susceptible to surviving much longer than expected. A table option to purge 
> TTL on expiration would address this issue, by preventing them from becoming 
> tombstones. A boolean purge_ttl_on_expiration table setting would allow users 
> to easily turn the feature on or off. 
> Being more aggressive with gc_grace could also address the problem of long 
> lasting tombstones, but that would affect tombstones from deletes as well. 
> Even if a purged [expired] cell is revived via repair from a node that hasn't 
> yet compacted away the cell, it would be revived as an expiring cell with the 
> same localDeletionTime, so reads should properly handle them. As well, it 
> would be purged in the next compaction. 



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

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

[jira] [Commented] (CASSANDRA-13561) Purge TTL on expiration

[Andrew Whang (JIRA)]

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

Andrew Whang commented on CASSANDRA-13561:
--

CASSANDRA-13643 seems to do something similar, but safer. Closing this out.

> Purge TTL on expiration
> ---
>
> Key: CASSANDRA-13561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13561
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Andrew Whang
>Assignee: Andrew Whang
>Priority: Minor
> Fix For: 4.0
>
>
> Tables with mostly TTL columns tend to suffer from high droppable tombstone 
> ratio, which results in higher read latency, cpu utilization, and disk usage. 
> Expired TTL data become tombstones, and the nature of purging tombstones 
> during compaction (due to checking for overlapping SSTables) make them 
> susceptible to surviving much longer than expected. A table option to purge 
> TTL on expiration would address this issue, by preventing them from becoming 
> tombstones. A boolean purge_ttl_on_expiration table setting would allow users 
> to easily turn the feature on or off. 
> Being more aggressive with gc_grace could also address the problem of long 
> lasting tombstones, but that would affect tombstones from deletes as well. 
> Even if a purged [expired] cell is revived via repair from a node that hasn't 
> yet compacted away the cell, it would be revived as an expiring cell with the 
> same localDeletionTime, so reads should properly handle them. As well, it 
> would be purged in the next compaction. 



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

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

[jira] [Commented] (CASSANDRA-13992) Don't send new_metadata_id for conditional updates

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-13992:
--

So it seems that prepare does return an empty digest, however 
{{ResultSet.ResultMetadata.EMPTY}} is created with {{compute}} and is thus a 
thread local digest, which will get a different hash. From what I can see EMPTY 
is only ever used in one place worth mentioning, and that's in 
{{org.apache.cassandra.cql3.ResultSet.ResultMetadata#fromPrepared}} (it's also 
used in {{org.apache.cassandra.transport.Message.Codec#decode}} but only for 
protocol versions prior to V1), and will be used for anything that's not a 
{{SELECT}} statement. 

Now, what I'm wondering is there any significant reason the ID for an "EMPTY" 
metadata ID is created as a thread local digest?
If we can change empty to instead use {{MD5Digest.wrap()}} we solve the 
prepared problem.

[~omichallat] Before I waste a lot of time figuring out how to test this in the 
driver, can you point me at how you did it?

bq. Since in this case it seems what will happen is when table is ALTER'ed, 
metadata won't update (I haven't checked it though)
Yes we'll probably need to do something about this. I'll write up some tests 
first. 


> Don't send new_metadata_id for conditional updates
> --
>
> Key: CASSANDRA-13992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13992
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Olivier Michallat
>Assignee: Kurt Greaves
>Priority: Minor
>
> This is a follow-up to CASSANDRA-10786.
> Given the table
> {code}
> CREATE TABLE foo (k int PRIMARY KEY)
> {code}
> And the prepared statement
> {code}
> INSERT INTO foo (k) VALUES (?) IF NOT EXISTS
> {code}
> The result set metadata changes depending on the outcome of the update:
> * if the row didn't exist, there is only a single column \[applied] = true
> * if it did, the result contains \[applied] = false, plus the current value 
> of column k.
> The way this was handled so far is that the PREPARED response contains no 
> result set metadata, and therefore all EXECUTE messages have SKIP_METADATA = 
> false, and the responses always include the full (and correct) metadata.
> CASSANDRA-10786 still sends the PREPARED response with no metadata, *but the 
> response to EXECUTE now contains a {{new_metadata_id}}*. The driver thinks it 
> is because of a schema change, and updates its local copy of the prepared 
> statement's result metadata.
> The next EXECUTE is sent with SKIP_METADATA = true, but the server appears to 
> ignore that, and still sends the metadata in the response. So each response 
> includes the correct metadata, the driver uses it, and there is no visible 
> issue for client code.
> The only drawback is that the driver updates its local copy of the metadata 
> unnecessarily, every time. We can work around that by only updating if we had 
> metadata before, at the cost of an extra volatile read. But I think the best 
> thing to do would be to never send a {{new_metadata_id}} in for a conditional 
> update.



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

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

[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms

[Kirk True (JIRA)]

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

Kirk True commented on CASSANDRA-13976:
---

Is it possible to use the {{DatabaseDescriptor.applySimpleConfig}} to convert 
from milliseconds to minutes so that the code can just use minutes everywhere?

> introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
> -
>
> Key: CASSANDRA-13976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13976
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Kirk True
>Priority: Minor
>  Labels: lhf
> Fix For: 4.0
>
>
> Milliseconds is unnecessarily precise.  At most, minutes would be used.  
> Config in 4.0 should default to a minute granularity, but if the 
> max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms 
> and emit a warning.
> max_hint_window_in_min: 180 # new default, still at 3 hours.



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

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

[jira] [Commented] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms

[Kirk True (JIRA)]

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

Kirk True commented on CASSANDRA-13976:
---

After thinking about this a little bit, it would seem that we need to support 
both {{max_hint_window_in_ms}} and {{max_hint_window_in_min}} everywhere. We 
would need to add:

# {{max_hint_window_in_min}} to {{Config}}
# {{getMaxHintWindowInMin}}/{{setMaxHintWindowInMin}} methods in 
{{DatabaseDescriptor}}, {{NodeProbe}}, {{StorageProxy}}, {{StorageProxyMBean}}, 
etc.
# A new {{GetMaxHintWindowInMin}} class to match {{GetMaxHintWindow}} to get 
the value via {{nodetool}}
# A new {{SetMaxHintWindowInMin}} class to match {{SetMaxHintWindow}} to set 
the value via {{nodetool}}

There would need to be a decision about which of {{max_hint_window_in_ms}} or 
{{max_hint_window_in_min}} to actually use internally. Regardless of whichever 
unit we used internally we'd likely have to convert from and to the other unit 
to maintain a coherent interface. For example, if we used minutes internally, 
the {{shouldHint}} method in {{StorageProxy}} would need to convert back to 
milliseconds from minutes anyway. Also, we'd need to convert back and forth for 
users of JMX and {{nodetool}}.

I'm not trying to argue that it's not a good change, I'm just wondering how to 
do it in a way that doesn't introduce complexity and confusion for end users 
and developers.

> introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
> -
>
> Key: CASSANDRA-13976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13976
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Kirk True
>Priority: Minor
>  Labels: lhf
> Fix For: 4.0
>
>
> Milliseconds is unnecessarily precise.  At most, minutes would be used.  
> Config in 4.0 should default to a minute granularity, but if the 
> max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms 
> and emit a warning.
> max_hint_window_in_min: 180 # new default, still at 3 hours.



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

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

[jira] [Assigned] (CASSANDRA-13976) introduce max_hint_window_in_min, deprecate max_hint_window_in_ms

[Kirk True (JIRA)]

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

Kirk True reassigned CASSANDRA-13976:
-

Assignee: Kirk True

> introduce max_hint_window_in_min, deprecate max_hint_window_in_ms
> -
>
> Key: CASSANDRA-13976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13976
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jon Haddad
>Assignee: Kirk True
>Priority: Minor
>  Labels: lhf
> Fix For: 4.0
>
>
> Milliseconds is unnecessarily precise.  At most, minutes would be used.  
> Config in 4.0 should default to a minute granularity, but if the 
> max_hint_window_in_min isn't set should fall back on max_hint_window_in_ms 
> and emit a warning.
> max_hint_window_in_min: 180 # new default, still at 3 hours.



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

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

[jira] [Commented] (CASSANDRA-13924) Continuous/Infectious Repair

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-13924:
---

for mutation tracking, will you ack back to replicas if hint succeeds in a 
reasonable time? 

> Continuous/Infectious Repair
> 
>
> Key: CASSANDRA-13924
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13924
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Repair
>Reporter: Joseph Lynch
>Priority: Minor
>  Labels: CommunityFeedbackRequested
>
> eI've been working on a way to keep data consistent without 
> scheduled/external/manual repair, because for large datasets repair is 
> extremely expensive. The basic gist is to introduce a new kind of hint that 
> keeps just the primary key of the mutation (indicating that PK needs repair) 
> and is recorded on replicas instead of coordinators during write time. Then a 
> periodic background task can issue read repairs to just the PKs that were 
> mutated. The initial performance degradation of this approach is non trivial, 
> but I believe that I can optimize it so that we are doing very little 
> additional work (see below in the design doc for some proposed optimizations).
> My extremely rough proof of concept (uses a local table instead of 
> HintStorage, etc) so far is [in a 
> branch|https://github.com/apache/cassandra/compare/cassandra-3.11...jolynch:continuous_repair]
>  and has a rough [design 
> document|https://github.com/jolynch/cassandra/blob/continuous_repair/doc/source/architecture/continuous_repair.rst].
>  I'm working on getting benchmarks of the various optimizations, but I 
> figured I should start this ticket before I got too deep into it.
> I believe this approach is particularly good for high read rate clusters 
> requiring consistent low latency, and for clusters that mutate a relatively 
> small proportion of their data (since you never have to read the whole 
> dataset, just what's being mutated). I view this as something that works 
> _with_ incremental repair to reduce work required because with this technique 
> we could potentially flush repaired + unrepaired sstables directly from the 
> memtable. I also see this as something that would be enabled or disabled per 
> table since it is so use case specific (e.g. some tables don't need repair at 
> all). I think this is somewhat of a hybrid approach based on incremental 
> repair, ticklers (read all partitions @ ALL), mutation based repair 
> (CASSANDRA-8911), and hinted handoff. There are lots of tradeoffs, but I 
> think it's worth talking about.
> If anyone has feedback on the idea, I'd love to chat about it. 
> [~bdeggleston], [~aweisberg] I chatted with you guys a bit about this at 
> NGCC; if you have time I'd love to continue that conversation here.



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

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

[jira] [Commented] (CASSANDRA-13924) Continuous/Infectious Repair

[Joseph Lynch (JIRA)]

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

Joseph Lynch commented on CASSANDRA-13924:
--

Sure, I can certainly start working on the part that tracks mutations that are 
fully acked first since that's useful whether we do the back half (read repair) 
or not. If we can get the repair service re-written for 4.0 so that 
incrementals are automatically scheduled by Cassandra itself, that would 
fulfill much of the second half of this idea (continuous, always on repair). My 
only concern with keeping the markers in memory is that we can't re-create them 
on a crash / shutdown (without drain), so you'd end up with a bunch of 
unrepaired tables, but that's probably worth the performance tradeoff.

If we do decide that read-repairing is faster/safer than a run of incremental 
repair, then I can just make something which reads the partitions out of the 
non repaired tables, reads @ ALL, and marks the table as repaired (or does a 
anticompaction) etc .. but that can be later work if we like that. My main 
reason for advocating for the read @ ALL technique is that I find reading the 
data to calculate a merkle tree seems potentially harder to manage from a 
consistent performance perspective than just reading the data. 

I'll start working on the mutation tracking bit and the flushing part.

> Continuous/Infectious Repair
> 
>
> Key: CASSANDRA-13924
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13924
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Repair
>Reporter: Joseph Lynch
>Priority: Minor
>  Labels: CommunityFeedbackRequested
>
> eI've been working on a way to keep data consistent without 
> scheduled/external/manual repair, because for large datasets repair is 
> extremely expensive. The basic gist is to introduce a new kind of hint that 
> keeps just the primary key of the mutation (indicating that PK needs repair) 
> and is recorded on replicas instead of coordinators during write time. Then a 
> periodic background task can issue read repairs to just the PKs that were 
> mutated. The initial performance degradation of this approach is non trivial, 
> but I believe that I can optimize it so that we are doing very little 
> additional work (see below in the design doc for some proposed optimizations).
> My extremely rough proof of concept (uses a local table instead of 
> HintStorage, etc) so far is [in a 
> branch|https://github.com/apache/cassandra/compare/cassandra-3.11...jolynch:continuous_repair]
>  and has a rough [design 
> document|https://github.com/jolynch/cassandra/blob/continuous_repair/doc/source/architecture/continuous_repair.rst].
>  I'm working on getting benchmarks of the various optimizations, but I 
> figured I should start this ticket before I got too deep into it.
> I believe this approach is particularly good for high read rate clusters 
> requiring consistent low latency, and for clusters that mutate a relatively 
> small proportion of their data (since you never have to read the whole 
> dataset, just what's being mutated). I view this as something that works 
> _with_ incremental repair to reduce work required because with this technique 
> we could potentially flush repaired + unrepaired sstables directly from the 
> memtable. I also see this as something that would be enabled or disabled per 
> table since it is so use case specific (e.g. some tables don't need repair at 
> all). I think this is somewhat of a hybrid approach based on incremental 
> repair, ticklers (read all partitions @ ALL), mutation based repair 
> (CASSANDRA-8911), and hinted handoff. There are lots of tradeoffs, but I 
> think it's worth talking about.
> If anyone has feedback on the idea, I'd love to chat about it. 
> [~bdeggleston], [~aweisberg] I chatted with you guys a bit about this at 
> NGCC; if you have time I'd love to continue that conversation here.



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

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

[jira] [Created] (CASSANDRA-14007) cqlshlib tests fail due to compact table

[Joel Knighton (JIRA)]

Joel Knighton created CASSANDRA-14007:
-

 Summary: cqlshlib tests fail due to compact table
 Key: CASSANDRA-14007
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14007
 Project: Cassandra
  Issue Type: Bug
  Components: Testing
Reporter: Joel Knighton


The pylib/cqlshlib tests fail on initialization with the error 
{{SyntaxException: }}. 

The table {{dynamic_columns}} is created {{WITH COMPACT STORAGE}}. Since 
[CASSANDRA-10857], this is no longer supported. It looks like dropping the 
COMPACT STORAGE modifier is enough for the tests to run, but I haven't looked 
if we should instead remove the table and all related tests entirely, or if 
there's an interesting code path covered by this that we should test in a 
different way now. [~ifesdjeen] might know at a glance.



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

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

[jira] [Updated] (CASSANDRA-13987) Multithreaded commitlog subtly changed durability

[Jason Brown (JIRA)]

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

Jason Brown updated CASSANDRA-13987:

Reviewer: Blake Eggleston

> Multithreaded commitlog subtly changed durability
> -
>
> Key: CASSANDRA-13987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13987
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jason Brown
>Assignee: Jason Brown
> Fix For: 4.x
>
>
> When multithreaded commitlog was introduced in CASSANDRA-3578, we subtly 
> changed the way that commitlog durability worked. Everything still gets 
> written to an mmap file. However, not everything is replayable from the 
> mmaped file after a process crash, in periodic mode.
> In brief, the reason this changesd is due to the chained markers that are 
> required for the multithreaded commit log. At each msync, we wait for 
> outstanding mutations to serialize into the commitlog, and update a marker 
> before and after the commits that have accumluated since the last sync. With 
> those markers, we can safely replay that section of the commitlog. Without 
> the markers, we have no guarantee that the commits in that section were 
> successfully written, thus we abandon those commits on replay.
> If you have correlated process failures of multiple nodes at "nearly" the 
> same time (see ["There Is No 
> Now"|http://queue.acm.org/detail.cfm?id=2745385]), it is possible to have 
> data loss if none of the nodes msync the commitlog. For example, with RF=3, 
> if quorum write succeeds on two nodes (and we acknowledge the write back to 
> the client), and then the process on both nodes OOMs (say, due to reading the 
> index for a 100GB partition), the write will be lost if neither process 
> msync'ed the commitlog. More exactly, the commitlog cannot be fully replayed. 
> The reason why this data is silently lost is due to the chained markers that 
> were introduced with CASSANDRA-3578.
> The problem we are addressing with this ticket is incrementally improving 
> 'durability' due to process crash, not host crash. (Note: operators should 
> use batch mode to ensure greater durability, but batch mode in it's current 
> implementation is a) borked, and b) will burn through, *very* rapidly, SSDs 
> that don't have a non-volatile write cache sitting in front.) 
> The current default for {{commitlog_sync_period_in_ms}} is 10 seconds, which 
> means that a node could lose up to ten seconds of data due to process crash. 
> The unfortunate thing is that the data is still avaialble, in the mmap file, 
> but we can't replay it due to incomplete chained markers.
> ftr, I don't believe we've ever had a stated policy about commitlog 
> durability wrt process crash. Pre-2.0 we naturally piggy-backed off the 
> memory mapped file and the fact that every mutation was acquired a lock and 
> wrote into the mmap buffer, and the ability to replay everything out of it 
> came for free. With CASSANDRA-3578, that was subtly changed. 
> Something [~jjirsa] pointed out to me is that [MySQL provides a way to adjust 
> the durability 
> guarantees|https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit]
>  of each commit in innodb via the {{innodb_flush_log_at_trx_commit}}. I'm 
> using that idea as a loose springboard for what to do here.



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

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

[jira] [Resolved] (CASSANDRA-13999) Segfault during memtable flush

[mck (JIRA)]

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

mck resolved CASSANDRA-13999.
-
   Resolution: Duplicate
Fix Version/s: 3.10

> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Fix For: 3.10
>
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated, 
> cassandra_config.yaml, compaction_exception_debug_fragment.obfuscated.log, 
> flush_exception_debug_fragment.obfuscated.log
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c [0x7f8e9f168400+0x16c]
> J 6720 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 
> 0x7f8e9def73c4 [0x7f8e9def72c0+0x104]
> J 22079 C2 java.lang.Thread.run()V (17 bytes) @ 0x7f8e9e67c4ac 
> [0x7f8e9e67c460+0x4c]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x691d16]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x692221]  JavaCalls::call_virtual(JavaValue*, KlassHandle, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x6926c7]  JavaCalls::call_virtual(JavaValue*, Handle, 
> KlassHandle, Symbol*, Symbol*, Thread*)+0x47
> V  [libjvm.so+0x72da50]  thread_entry(JavaThread*, Thread*)+0xa0
> V  [libjvm.so+0xa76833]  JavaThread::thread_main_inner()+0x103
> V  [libjvm.so+0xa7697c]  JavaThread::run()+0x11c
> V  [libjvm.so+0x927568]  java_start(Thread*)+0x108
> C  [libpthread.so.0+0x7de5]  start_thread+0xc5
> {code}
> For further details, we attached:
> * JVM error file with all details
> * cassandra config file (we are using offheap_buffers as 
> memtable_allocation_method)
> * some lines printed in debug.log when the JVM error file was created and 
> process died
> h5. Reproducing the issue
> So far we have been unable to reproduce it. It happens once/twice a week on 
> single nodes. It happens either during high load or low load times. We have 
> seen that when we replace EC2 instances and bootstrap new ones, due to 
> compactions happening on source nodes before stream starts, sometimes more 
> than a single node was affected by this, letting us with 2 out of 3 replicas 
> out and UnavailableExceptions in the cluster.
> This issue might have relation with CASSANDRA-12590 (Segfault reading 
> secondary index) even this is the write path. Can someone confirm if both 
> issues could be related? 
> h5. Specifics of our scenario:
> * Cassandra 3.9 on Amazon Linux (previous to this, we were running Cassandra 
> 2.0.9 and there are no records of this also happening, even I was not working 
> on Cassandra)
> * 12 x i3.2xlarge EC2 instances (8 core, 64GB RAM)
> * a total of 176 keyspaces (there is a per-customer pattern)
> ** Some keyspaces have a single table, while others have 2 or 5 tables
> ** There is a table that uses standard Secondary Indexes ("emailindex" on 
> "user_info" table)
> * It happens on both Oracle JDK 1.8.0_112 and 1.8.0_131
> * It happens in both kernel 4.9.43-17.38.amzn1.x86_64 and 
> 3.14.35-28.38.amzn1.x86_64
> h5. Possible workarounds/solutions that we have in mind (to be validated yet)
> * switching 

[jira] [Commented] (CASSANDRA-13999) Segfault during memtable flush

[mck (JIRA)]

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

mck commented on CASSANDRA-13999:
-

The stack in {{cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated}} is
{noformat}
=252k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 16029 C2 
org.apache.cassandra.dht.LocalPartitioner$LocalToken.compareTo(Ljava/lang/Object;)I
 (9 bytes) @ 0x7f29f745a869 [0x7f29f745a700+0x169]
J 6225 C2 org.apache.cassandra.db.DecoratedKey.compareTo(Ljava/lang/Object;)I 
(9 bytes) @ 0x7f29f615bd20 [0x7f29f615b9e0+0x340]
J 22036 C2 
java.util.concurrent.ConcurrentSkipListMap.doGet(Ljava/lang/Object;)Ljava/lang/Object;
 (142 bytes) @ 0x7f29f7e5960c [0x7f29f7e59040+0x5cc]
J 24226 C2 
org.apache.cassandra.db.Memtable.getPartition(Lorg/apache/cassandra/db/DecoratedKey;)Lorg/apache/cassandra/db/partitions/Partition;
 (14 bytes) @ 0x7f29f65842c8 [0x7f29f6584280+0x48]
J 15118 C2 
org.apache.cassandra.db.compaction.CompactionIterator$Purger.getMaxPurgeableTimestamp()J
 (32 bytes) @ 0x7f29f73b24bc [0x7f29f73b1e40+0x67c]
J 11869 C2 
org.apache.cassandra.db.rows.BTreeRow.purge(Lorg/apache/cassandra/db/DeletionPurger;I)Lorg/apache/cassandra/db/rows/Row;
 (78 bytes) @ 0x7f29f6c3f0a0 [0x7f29f6c3eb20+0x580]
J 11280 C2 
org.apache.cassandra.db.partitions.PurgeFunction.applyToRow(Lorg/apache/cassandra/db/rows/Row;)Lorg/apache/cassandra/db/rows/Row;
 (19 bytes) @ 0x7f29f69ef0cc [0x7f29f69ef000+0xcc]
J 12718 C2 
org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(Lorg/apache/cassandra/db/rows/BaseRowIterator;)Lorg/apache/cassandra/db/rows/BaseRowIterator;
 (9 bytes) @ 0x7f29f5a3f824 [0x7f29f5a3ee60+0x9c4]
J 23545 C2 org.apache.cassandra.db.compaction.CompactionTask.runMayThrow()V 
(1523 bytes) @ 0x7f29f8395778 [0x7f29f8394120+0x1658]
J 23641 C1 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(Lorg/apache/cassandra/db/compaction/CompactionManager$CompactionExecutorStatsCollector;)I
 (22 bytes) @ 0x7f29f83c22ec [0x7f29f83c2100+0x1ec]
J 23875 C1 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(Lorg/apache/cassandra/db/compaction/CompactionManager$CompactionExecutorStatsCollector;)I
 (25 bytes) @ 0x7f29f61de66c [0x7f29f61de560+0x10c]
J 22667 C2 
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run()V
 (185 bytes) @ 0x7f29f5dccf80 [0x7f29f5dccba0+0x3e0]
{noformat}

Crashing in {{LocalPartitioner$LocalToken.compareTo(..)}} , ie 
{{org.apache.cassandra.dht.LocalPartitioner:139}}, confirms this is a duplicate 
of CASSANDRA-12590 and CASSANDRA-12651. Resolving the issue as such.

> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated, 
> cassandra_config.yaml, compaction_exception_debug_fragment.obfuscated.log, 
> flush_exception_debug_fragment.obfuscated.log
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c 

[jira] [Commented] (CASSANDRA-13999) Segfault during memtable flush

[mck (JIRA)]

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

mck commented on CASSANDRA-13999:
-

{quote}We'll do the PRO cluster next week because tomorrow is Friday and 
because we want to give time to the switch to heap_buffers to see results and 
start introducing other changes.{quote}
(y)

{quote}given that offheap_buffers uses Java NIO and because of the bug in 
LocalPartitioner.java we get the segfault, switching to heap_buffers should 
mitigate the problem so far, right?{quote}
That's correct. And switching to heap_buffers shouldn't have any dramatic 
negative effect on performance/gc if you're not storing large objects in any 
columns.



> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated, 
> cassandra_config.yaml, compaction_exception_debug_fragment.obfuscated.log, 
> flush_exception_debug_fragment.obfuscated.log
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c [0x7f8e9f168400+0x16c]
> J 6720 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 
> 0x7f8e9def73c4 [0x7f8e9def72c0+0x104]
> J 22079 C2 java.lang.Thread.run()V (17 bytes) @ 0x7f8e9e67c4ac 
> [0x7f8e9e67c460+0x4c]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x691d16]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x692221]  JavaCalls::call_virtual(JavaValue*, KlassHandle, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x6926c7]  JavaCalls::call_virtual(JavaValue*, Handle, 
> KlassHandle, Symbol*, Symbol*, Thread*)+0x47
> V  [libjvm.so+0x72da50]  thread_entry(JavaThread*, Thread*)+0xa0
> V  [libjvm.so+0xa76833]  JavaThread::thread_main_inner()+0x103
> V  [libjvm.so+0xa7697c]  JavaThread::run()+0x11c
> V  [libjvm.so+0x927568]  java_start(Thread*)+0x108
> C  [libpthread.so.0+0x7de5]  start_thread+0xc5
> {code}
> For further details, we attached:
> * JVM error file with all details
> * cassandra config file (we are using offheap_buffers as 
> memtable_allocation_method)
> * some lines printed in debug.log when the JVM error file was created and 
> process died
> h5. Reproducing the issue
> So far we have been unable to reproduce it. It happens once/twice a week on 
> single nodes. It happens either during high load or low load times. We have 
> seen that when we replace EC2 instances and bootstrap new ones, due to 
> compactions happening on source nodes before stream starts, sometimes more 
> than a single node was affected by this, letting us with 2 out of 3 replicas 
> out and UnavailableExceptions in the cluster.
> This issue might have relation with CASSANDRA-12590 (Segfault reading 
> secondary index) even this is the write path. Can someone confirm if both 
> issues could be related? 
> h5. Specifics of our scenario:
> * Cassandra 3.9 on Amazon Linux (previous to this, we were running Cassandra 
> 2.0.9 and there are no records of this also happening, even I was not working 
> on Cassandra)
> * 12 x 

[jira] [Commented] (CASSANDRA-14003) Correct logger message formatting in SSTableLoader

[Jaydeepkumar Chovatia (JIRA)]

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

Jaydeepkumar Chovatia commented on CASSANDRA-14003:
---

Thank You [~bdeggleston]!

> Correct logger message formatting in SSTableLoader
> --
>
> Key: CASSANDRA-14003
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14003
> Project: Cassandra
>  Issue Type: Task
>  Components: Tools
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Trivial
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> Correct logger message formatting inside SSTableLoader.java
> -outputHandler.output(String.format("Streaming relevant part of %sto 
> %s", names(sstables), endpointToRanges.keySet()));
> +outputHandler.output(String.format("Streaming relevant part of %s to 
> %s", names(sstables), endpointToRanges.keySet()));
>  



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

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

[jira] [Commented] (CASSANDRA-13924) Continuous/Infectious Repair

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-13924:
---

I like this idea but want to propose the following changes to it. 

We track in memtable at partition level what data was replicated to all 
replicas. This will require co-ordinator to update the replicas once data is 
acked from all replicas. 

We flush memtable as separate sstables containing repaired and non repaired 
data. Incremental repair will take care of non repaired data. 

Another optimization we can build on top of this is to flush only repaired data 
when we need to flush and keep non repaired for a little longer time. This will 
make sure they get ACKed from co-ordinator. Co-ordoinator can also ack back to 
replicas if hints were successfully delivered. 

> Continuous/Infectious Repair
> 
>
> Key: CASSANDRA-13924
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13924
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Repair
>Reporter: Joseph Lynch
>Priority: Minor
>  Labels: CommunityFeedbackRequested
>
> eI've been working on a way to keep data consistent without 
> scheduled/external/manual repair, because for large datasets repair is 
> extremely expensive. The basic gist is to introduce a new kind of hint that 
> keeps just the primary key of the mutation (indicating that PK needs repair) 
> and is recorded on replicas instead of coordinators during write time. Then a 
> periodic background task can issue read repairs to just the PKs that were 
> mutated. The initial performance degradation of this approach is non trivial, 
> but I believe that I can optimize it so that we are doing very little 
> additional work (see below in the design doc for some proposed optimizations).
> My extremely rough proof of concept (uses a local table instead of 
> HintStorage, etc) so far is [in a 
> branch|https://github.com/apache/cassandra/compare/cassandra-3.11...jolynch:continuous_repair]
>  and has a rough [design 
> document|https://github.com/jolynch/cassandra/blob/continuous_repair/doc/source/architecture/continuous_repair.rst].
>  I'm working on getting benchmarks of the various optimizations, but I 
> figured I should start this ticket before I got too deep into it.
> I believe this approach is particularly good for high read rate clusters 
> requiring consistent low latency, and for clusters that mutate a relatively 
> small proportion of their data (since you never have to read the whole 
> dataset, just what's being mutated). I view this as something that works 
> _with_ incremental repair to reduce work required because with this technique 
> we could potentially flush repaired + unrepaired sstables directly from the 
> memtable. I also see this as something that would be enabled or disabled per 
> table since it is so use case specific (e.g. some tables don't need repair at 
> all). I think this is somewhat of a hybrid approach based on incremental 
> repair, ticklers (read all partitions @ ALL), mutation based repair 
> (CASSANDRA-8911), and hinted handoff. There are lots of tradeoffs, but I 
> think it's worth talking about.
> If anyone has feedback on the idea, I'd love to chat about it. 
> [~bdeggleston], [~aweisberg] I chatted with you guys a bit about this at 
> NGCC; if you have time I'd love to continue that conversation here.



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

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

[jira] [Updated] (CASSANDRA-13924) Continuous/Infectious Repair

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-13924:
--
Description: 
eI've been working on a way to keep data consistent without 
scheduled/external/manual repair, because for large datasets repair is 
extremely expensive. The basic gist is to introduce a new kind of hint that 
keeps just the primary key of the mutation (indicating that PK needs repair) 
and is recorded on replicas instead of coordinators during write time. Then a 
periodic background task can issue read repairs to just the PKs that were 
mutated. The initial performance degradation of this approach is non trivial, 
but I believe that I can optimize it so that we are doing very little 
additional work (see below in the design doc for some proposed optimizations).

My extremely rough proof of concept (uses a local table instead of HintStorage, 
etc) so far is [in a 
branch|https://github.com/apache/cassandra/compare/cassandra-3.11...jolynch:continuous_repair]
 and has a rough [design 
document|https://github.com/jolynch/cassandra/blob/continuous_repair/doc/source/architecture/continuous_repair.rst].
 I'm working on getting benchmarks of the various optimizations, but I figured 
I should start this ticket before I got too deep into it.

I believe this approach is particularly good for high read rate clusters 
requiring consistent low latency, and for clusters that mutate a relatively 
small proportion of their data (since you never have to read the whole dataset, 
just what's being mutated). I view this as something that works _with_ 
incremental repair to reduce work required because with this technique we could 
potentially flush repaired + unrepaired sstables directly from the memtable. I 
also see this as something that would be enabled or disabled per table since it 
is so use case specific (e.g. some tables don't need repair at all). I think 
this is somewhat of a hybrid approach based on incremental repair, ticklers 
(read all partitions @ ALL), mutation based repair (CASSANDRA-8911), and hinted 
handoff. There are lots of tradeoffs, but I think it's worth talking about.

If anyone has feedback on the idea, I'd love to chat about it. [~bdeggleston], 
[~aweisberg] I chatted with you guys a bit about this at NGCC; if you have time 
I'd love to continue that conversation here.

  was:
I've been working on a way to keep data consistent without 
scheduled/external/manual repair, because for large datasets repair is 
extremely expensive. The basic gist is to introduce a new kind of hint that 
keeps just the primary key of the mutation (indicating that PK needs repair) 
and is recorded on replicas instead of coordinators during write time. Then a 
periodic background task can issue read repairs to just the PKs that were 
mutated. The initial performance degradation of this approach is non trivial, 
but I believe that I can optimize it so that we are doing very little 
additional work (see below in the design doc for some proposed optimizations).

My extremely rough proof of concept (uses a local table instead of HintStorage, 
etc) so far is [in a 
branch|https://github.com/apache/cassandra/compare/cassandra-3.11...jolynch:continuous_repair]
 and has a rough [design 
document|https://github.com/jolynch/cassandra/blob/continuous_repair/doc/source/architecture/continuous_repair.rst].
 I'm working on getting benchmarks of the various optimizations, but I figured 
I should start this ticket before I got too deep into it.

I believe this approach is particularly good for high read rate clusters 
requiring consistent low latency, and for clusters that mutate a relatively 
small proportion of their data (since you never have to read the whole dataset, 
just what's being mutated). I view this as something that works _with_ 
incremental repair to reduce work required because with this technique we could 
potentially flush repaired + unrepaired sstables directly from the memtable. I 
also see this as something that would be enabled or disabled per table since it 
is so use case specific (e.g. some tables don't need repair at all). I think 
this is somewhat of a hybrid approach based on incremental repair, ticklers 
(read all partitions @ ALL), mutation based repair (CASSANDRA-8911), and hinted 
handoff. There are lots of tradeoffs, but I think it's worth talking about.

If anyone has feedback on the idea, I'd love to chat about it. [~bdeggleston], 
[~aweisberg] I chatted with you guys a bit about this at NGCC; if you have time 
I'd love to continue that conversation here.


> Continuous/Infectious Repair
> 
>
> Key: CASSANDRA-13924
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13924
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Repair
>Reporter: Joseph Lynch
>

[jira] [Created] (CASSANDRA-14006) Migration task failed completes bootstrap but it didn't stream any data.

[Tania S Engel (JIRA)]

Tania S Engel created CASSANDRA-14006:
-

 Summary: Migration task failed completes bootstrap but it didn't 
stream any data.
 Key: CASSANDRA-14006
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14006
 Project: Cassandra
  Issue Type: Bug
  Components: Streaming and Messaging
Reporter: Tania S Engel


When joining just one node with very little data we often get "Migration task 
failed to complete" per 
https://github.com/apache/cassandra/commit/ae315b5ec944571342146867c51b2ceb50f3845e
 
We increased the timeout on *MIGRATION_TASK_WAIT_IN_SECONDS *to 15 minutes 
thinking there was some sort of auto retry mechanism in the underlying 
messaging. However all that does is increase the time to failure. When these 
migration tasks fail, the bootstrap is marked complete but it clearly wasn't 
complete because usage of the data results in a 
cassandra.db.*UnknownColumnFamilyException*. Also, it is evident in the logs 
that no data was streamed from the seed node to the newly bootstrapping node. 
We have had numerous tests showing that if a migration task times out, the node 
exits joining mode, the bootstrap logs complete, but it hasn't streamed any 
data and the only course of action seems to be a Cassandra restart. Our 
replication factor is set such that the bootstrapping node needs to get all the 
data. If we were to leave the Cassandra node running, would it eventually send 
another migration task and stream the necessary data?
 
On closer inspection of the code, it seems that the *MigrationTask.java* 
runMayThrow sends the migration request message using *sendRR*, which is a fire 
and forget. So, if the callback is not hit, it can leave you in a state where 
the CountdownLatch.countDown() is never invoked. So, I suppose that is the 
point of the timeout when waiting for the latch. But wouldn't it be better to 
resend the migration task? I certainly haven't learned all the messaging 
service but it seems that dropping a packet here and there could cause 
bootstrap to succeed in this misleading way. Would it make sense for the 
MigrationTask runMayThrow to create a IAsyncCallbackWithFailure for the 
callback and implement the OnFailure to also CountdownLatch.countDown() and 
generate another migration task? Or perhaps allow users of Cassandra to 
configure something like a MIGRATION_TASK_RETRY_ATTEMPTS?
 
When the MigrationTask does fail to complete, we see the log 3 times. Is this 
the resend of the same migration task …which is just schema version exchange? 
In which case if all 3 failed it means all attempts failed to reach the seed 
endpoint or the response failed to reach the bootstrapping endpoint. Are we 
correct in assuming this is a network error and there are no scenarios where 
the seed node would ignore the migration task from the bootstrapping node? 




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

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

[jira] [Updated] (CASSANDRA-14003) Correct logger message formatting in SSTableLoader

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-14003:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks [~chovatia.jayd...@gmail.com]. This was also a problem in 3.0, so I 
committed your patch there and merged it up through trunk. Committed as 
{{f767d35ae92ccc513684a484a895aeb1a2239734}}

> Correct logger message formatting in SSTableLoader
> --
>
> Key: CASSANDRA-14003
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14003
> Project: Cassandra
>  Issue Type: Task
>  Components: Tools
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Trivial
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> Correct logger message formatting inside SSTableLoader.java
> -outputHandler.output(String.format("Streaming relevant part of %sto 
> %s", names(sstables), endpointToRanges.keySet()));
> +outputHandler.output(String.format("Streaming relevant part of %s to 
> %s", names(sstables), endpointToRanges.keySet()));
>  



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

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

[1/6] cassandra git commit: Fix SSTableLoader logger message

[bdeggleston]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 49edd7074 -> f767d35ae
  refs/heads/cassandra-3.11 7d6474bb4 -> 387d3a4eb
  refs/heads/trunk ec6282242 -> 7707b736c


Fix SSTableLoader logger message

Patch by Jaydeepkumar Chovatia; Reviewed by Blake Eggleston for CASSANDRA-14003


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

Branch: refs/heads/cassandra-3.0
Commit: f767d35ae92ccc513684a484a895aeb1a2239734
Parents: 49edd70
Author: jaydeepkumar1984 
Authored: Wed Nov 8 16:26:33 2017 -0800
Committer: Blake Eggleston 
Committed: Thu Nov 9 10:05:56 2017 -0800

--
 CHANGES.txt | 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableLoader.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f767d35a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a94dbc9..e3026aa 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix SSTableLoader logger message (CASSANDRA-14003)
  * Fix repair race that caused gossip to block (CASSANDRA-13849)
  * Tracing interferes with digest requests when using RandomPartitioner 
(CASSANDRA-13964)
  * Add flag to disable materialized views, and warnings on creation 
(CASSANDRA-13959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f767d35a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
index 3286522..e597e54 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
@@ -169,7 +169,7 @@ public class SSTableLoader implements StreamEventHandler
 return plan.execute();
 }
 
-outputHandler.output(String.format("Streaming relevant part of %sto 
%s", names(sstables), endpointToRanges.keySet()));
+outputHandler.output(String.format("Streaming relevant part of %s to 
%s", names(sstables), endpointToRanges.keySet()));
 
 for (Map.Entry> entry : 
endpointToRanges.entrySet())
 {


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

[2/6] cassandra git commit: Fix SSTableLoader logger message

[bdeggleston]

Fix SSTableLoader logger message

Patch by Jaydeepkumar Chovatia; Reviewed by Blake Eggleston for CASSANDRA-14003


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

Branch: refs/heads/cassandra-3.11
Commit: f767d35ae92ccc513684a484a895aeb1a2239734
Parents: 49edd70
Author: jaydeepkumar1984 
Authored: Wed Nov 8 16:26:33 2017 -0800
Committer: Blake Eggleston 
Committed: Thu Nov 9 10:05:56 2017 -0800

--
 CHANGES.txt | 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableLoader.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f767d35a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a94dbc9..e3026aa 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix SSTableLoader logger message (CASSANDRA-14003)
  * Fix repair race that caused gossip to block (CASSANDRA-13849)
  * Tracing interferes with digest requests when using RandomPartitioner 
(CASSANDRA-13964)
  * Add flag to disable materialized views, and warnings on creation 
(CASSANDRA-13959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f767d35a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
index 3286522..e597e54 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
@@ -169,7 +169,7 @@ public class SSTableLoader implements StreamEventHandler
 return plan.execute();
 }
 
-outputHandler.output(String.format("Streaming relevant part of %sto 
%s", names(sstables), endpointToRanges.keySet()));
+outputHandler.output(String.format("Streaming relevant part of %s to 
%s", names(sstables), endpointToRanges.keySet()));
 
 for (Map.Entry> entry : 
endpointToRanges.entrySet())
 {


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

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

[bdeggleston]

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

Branch: refs/heads/trunk
Commit: 7707b736cd216a59f29dccdbabbb8398df95e020
Parents: ec62822 387d3a4
Author: Blake Eggleston 
Authored: Thu Nov 9 10:08:06 2017 -0800
Committer: Blake Eggleston 
Committed: Thu Nov 9 10:08:06 2017 -0800

--
 CHANGES.txt | 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableLoader.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7707b736/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/7707b736/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
--


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

[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[bdeggleston]

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

Branch: refs/heads/trunk
Commit: 387d3a4eba9fc1346266a30f27db6e29f049a82e
Parents: 7d6474b f767d35
Author: Blake Eggleston 
Authored: Thu Nov 9 10:07:53 2017 -0800
Committer: Blake Eggleston 
Committed: Thu Nov 9 10:07:53 2017 -0800

--
 CHANGES.txt | 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableLoader.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/387d3a4e/CHANGES.txt
--
diff --cc CHANGES.txt
index 6bd6de8,e3026aa..6a78b60
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 -3.0.16
 +3.11.2
 + * Add asm jar to build.xml for maven builds (CASSANDRA-11193)
 + * Round buffer size to powers of 2 for the chunk cache (CASSANDRA-13897)
 + * Update jackson JSON jars (CASSANDRA-13949)
 + * Avoid locks when checking LCS fanout and if we should defrag 
(CASSANDRA-13930)
 +Merged from 3.0:
+  * Fix SSTableLoader logger message (CASSANDRA-14003)
   * Fix repair race that caused gossip to block (CASSANDRA-13849)
   * Tracing interferes with digest requests when using RandomPartitioner 
(CASSANDRA-13964)
   * Add flag to disable materialized views, and warnings on creation 
(CASSANDRA-13959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/387d3a4e/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
--


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

[3/6] cassandra git commit: Fix SSTableLoader logger message

[bdeggleston]

Fix SSTableLoader logger message

Patch by Jaydeepkumar Chovatia; Reviewed by Blake Eggleston for CASSANDRA-14003


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

Branch: refs/heads/trunk
Commit: f767d35ae92ccc513684a484a895aeb1a2239734
Parents: 49edd70
Author: jaydeepkumar1984 
Authored: Wed Nov 8 16:26:33 2017 -0800
Committer: Blake Eggleston 
Committed: Thu Nov 9 10:05:56 2017 -0800

--
 CHANGES.txt | 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableLoader.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f767d35a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a94dbc9..e3026aa 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.16
+ * Fix SSTableLoader logger message (CASSANDRA-14003)
  * Fix repair race that caused gossip to block (CASSANDRA-13849)
  * Tracing interferes with digest requests when using RandomPartitioner 
(CASSANDRA-13964)
  * Add flag to disable materialized views, and warnings on creation 
(CASSANDRA-13959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f767d35a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java 
b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
index 3286522..e597e54 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
@@ -169,7 +169,7 @@ public class SSTableLoader implements StreamEventHandler
 return plan.execute();
 }
 
-outputHandler.output(String.format("Streaming relevant part of %sto 
%s", names(sstables), endpointToRanges.keySet()));
+outputHandler.output(String.format("Streaming relevant part of %s to 
%s", names(sstables), endpointToRanges.keySet()));
 
 for (Map.Entry> entry : 
endpointToRanges.entrySet())
 {


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

[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[bdeggleston]

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

Branch: refs/heads/cassandra-3.11
Commit: 387d3a4eba9fc1346266a30f27db6e29f049a82e
Parents: 7d6474b f767d35
Author: Blake Eggleston 
Authored: Thu Nov 9 10:07:53 2017 -0800
Committer: Blake Eggleston 
Committed: Thu Nov 9 10:07:53 2017 -0800

--
 CHANGES.txt | 1 +
 src/java/org/apache/cassandra/io/sstable/SSTableLoader.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/387d3a4e/CHANGES.txt
--
diff --cc CHANGES.txt
index 6bd6de8,e3026aa..6a78b60
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 -3.0.16
 +3.11.2
 + * Add asm jar to build.xml for maven builds (CASSANDRA-11193)
 + * Round buffer size to powers of 2 for the chunk cache (CASSANDRA-13897)
 + * Update jackson JSON jars (CASSANDRA-13949)
 + * Avoid locks when checking LCS fanout and if we should defrag 
(CASSANDRA-13930)
 +Merged from 3.0:
+  * Fix SSTableLoader logger message (CASSANDRA-14003)
   * Fix repair race that caused gossip to block (CASSANDRA-13849)
   * Tracing interferes with digest requests when using RandomPartitioner 
(CASSANDRA-13964)
   * Add flag to disable materialized views, and warnings on creation 
(CASSANDRA-13959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/387d3a4e/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java
--


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

[jira] [Commented] (CASSANDRA-13997) Upgrade Guava to 23.3 and Airline to 0.8

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-13997:
-

[~tjake] something like this? 
https://github.com/krummas/cassandra/commit/4d174989400126c8a4c206699b0abc6c09b30844

> Upgrade Guava to 23.3 and Airline to 0.8
> 
>
> Key: CASSANDRA-13997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13997
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.0
>
> Attachments: airline-0.8.jar.asc, guava-23.3-jre.jar.asc
>
>
> For 4.0 we should upgrade guava to the latest version
> patch here: https://github.com/krummas/cassandra/commits/marcuse/guava23
> A bunch of quite commonly used methods have been deprecated since guava 18 
> which we use now ({{Throwables.propagate}} for example), this patch mostly 
> updates uses where compilation fails. {{Futures.transform(ListenableFuture 
> ..., AsyncFunction ...}} was deprecated in Guava 19 and removed in 20 for 
> example, we should probably open new tickets to remove calls to all 
> deprecated guava methods.
> Also had to add a dependency on {{com.google.j2objc.j2objc-annotations}}, to 
> avoid some build-time warnings (maybe due to 
> https://github.com/google/guava/commit/fffd2b1f67d158c7b4052123c5032b0ba54a910d
>  ?)



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

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

[jira] [Updated] (CASSANDRA-14003) Correct logger message formatting in SSTableLoader

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-14003:

 Reviewer: Blake Eggleston
Fix Version/s: (was: 4.x)
   4.0
   3.11.2
   3.0.16

> Correct logger message formatting in SSTableLoader
> --
>
> Key: CASSANDRA-14003
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14003
> Project: Cassandra
>  Issue Type: Task
>  Components: Tools
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Trivial
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> Correct logger message formatting inside SSTableLoader.java
> -outputHandler.output(String.format("Streaming relevant part of %sto 
> %s", names(sstables), endpointToRanges.keySet()));
> +outputHandler.output(String.format("Streaming relevant part of %s to 
> %s", names(sstables), endpointToRanges.keySet()));
>  



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

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

[jira] [Commented] (CASSANDRA-13475) First version of pluggable storage engine API.

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-13475:
---

[~bdeggleston] okay, which one do you want to discuss at this moment? 

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> Here is a design quip we are currently working on:  
> https://quip.com/bhw5ABUCi3co
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



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

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

[jira] [Commented] (CASSANDRA-13997) Upgrade Guava to 23.3 and Airline to 0.8

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-13997:


[~krummas]  There's no need to add the j2objc to the lib dir.  You can simply 
add it to the build dep jars. An example of this is the 
compile-command-annotation entries in build.xml

> Upgrade Guava to 23.3 and Airline to 0.8
> 
>
> Key: CASSANDRA-13997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13997
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.0
>
> Attachments: airline-0.8.jar.asc, guava-23.3-jre.jar.asc
>
>
> For 4.0 we should upgrade guava to the latest version
> patch here: https://github.com/krummas/cassandra/commits/marcuse/guava23
> A bunch of quite commonly used methods have been deprecated since guava 18 
> which we use now ({{Throwables.propagate}} for example), this patch mostly 
> updates uses where compilation fails. {{Futures.transform(ListenableFuture 
> ..., AsyncFunction ...}} was deprecated in Guava 19 and removed in 20 for 
> example, we should probably open new tickets to remove calls to all 
> deprecated guava methods.
> Also had to add a dependency on {{com.google.j2objc.j2objc-annotations}}, to 
> avoid some build-time warnings (maybe due to 
> https://github.com/google/guava/commit/fffd2b1f67d158c7b4052123c5032b0ba54a910d
>  ?)



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

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

[jira] [Commented] (CASSANDRA-13999) Segfault during memtable flush

[Ricardo Bartolome (JIRA)]

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

Ricardo Bartolome commented on CASSANDRA-13999:
---

As of November 9th at 10:30 AM (CET) we have the 12 production nodes running 
heap_buffers with no performance degradation with our workload. We expect to 
see an improvement over the next days and this has been applied as a workaround.

Also, we got a Cassandra 3.9 version with a backported patch of the bug that we 
are talking about, and we are aiming to test it in our DEV, PRE and PRO 
cluster(s). We'll do the PRO cluster next week because tomorrow is Friday and 
because we want to give time to the switch to *heap_buffers* to see results and 
start introducing other changes.

As a long-term solution, upgrading to Cassandra 3.11.1 is the option.

Nevertheless, to be all in the same page: given that offheap_buffers uses Java 
NIO and because of the bug in LocalPartitioner.java we get the segfault, 
switching to heap_buffers should mitigate the problem so far, right? 

My rationale is the following:
* if with a config change (that proved no degradation) I can stop segfaults to 
happen, I'll put efforts into upgrading to 3.11.1 rather than monkey-patching a 
Cassandra 3.9
* we have 16 cluster that might be affected like this, so I prefer to have a 
sort-term solution AND a long-term solution



> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated, 
> cassandra_config.yaml, compaction_exception_debug_fragment.obfuscated.log, 
> flush_exception_debug_fragment.obfuscated.log
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c [0x7f8e9f168400+0x16c]
> J 6720 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 
> 0x7f8e9def73c4 [0x7f8e9def72c0+0x104]
> J 22079 C2 java.lang.Thread.run()V (17 bytes) @ 0x7f8e9e67c4ac 
> [0x7f8e9e67c460+0x4c]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x691d16]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x692221]  JavaCalls::call_virtual(JavaValue*, KlassHandle, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x6926c7]  JavaCalls::call_virtual(JavaValue*, Handle, 
> KlassHandle, Symbol*, Symbol*, Thread*)+0x47
> V  [libjvm.so+0x72da50]  thread_entry(JavaThread*, Thread*)+0xa0
> V  [libjvm.so+0xa76833]  JavaThread::thread_main_inner()+0x103
> V  [libjvm.so+0xa7697c]  JavaThread::run()+0x11c
> V  [libjvm.so+0x927568]  java_start(Thread*)+0x108
> C  [libpthread.so.0+0x7de5]  start_thread+0xc5
> {code}
> For further details, we attached:
> * JVM error file with all details
> * cassandra config file (we are using offheap_buffers as 
> memtable_allocation_method)
> * some lines printed in debug.log when the JVM error file was created and 
> process died
> h5. Reproducing the issue
> So far we have been unable to reproduce it. It happens once/twice a week on 
> single nodes. It happens either during high load or low load times. We have 
> 

[jira] [Commented] (CASSANDRA-13475) First version of pluggable storage engine API.

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13475:
-

No I don’t think we’ve agreed on the scope and boundaries of the project. There 
have been a few ideas thrown around, but we haven't agreed on anything concrete.

Also, let's try to keep the conversation focused on one thing at a time. We 
tentatively agreed on a rough plan last week, then we started talking about 
expectations, guidelines, and non technical stuff. Let’s finish talking about 
that. After that, let’s talk about the scope. If you want to revisit the 
tentative plan after that, that’s fine, but let’s avoid jumping around too much.

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> Here is a design quip we are currently working on:  
> https://quip.com/bhw5ABUCi3co
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



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

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

[jira] [Commented] (CASSANDRA-13475) First version of pluggable storage engine API.

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13475:
-

Steps 4-11 all involve moving stuff into something called the CQLStorageEngine. 
Earlier in the discussion, this was the native cassandra implementation of the 
proposed storage interface. I guess that might have changed, but it's not 
really clear what CQLStorageEngine is

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> Here is a design quip we are currently working on:  
> https://quip.com/bhw5ABUCi3co
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



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

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

[jira] [Commented] (CASSANDRA-13475) First version of pluggable storage engine API.

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-13475:
---

[~bdeggleston], I thought we already agreed on the scope and boundary of the 
storage engine layer. If that's true, then even when there is no storage engine 
api layer, we should create an CQLStorageEngine package, and start to move 
things belong to the storage engine into that package, right? It will be all 
the stuff within the storage engine layer, and we can create an interface from 
them at the end, in step 16.

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> Here is a design quip we are currently working on:  
> https://quip.com/bhw5ABUCi3co
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



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

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

[jira] [Commented] (CASSANDRA-13475) First version of pluggable storage engine API.

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-13475:
---

[~bdeggleston], sorry, I don't understand, I'm not adding a new storage engine 
api in the proposed plan, right?

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> Here is a design quip we are currently working on:  
> https://quip.com/bhw5ABUCi3co
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



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

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

[jira] [Commented] (CASSANDRA-13475) First version of pluggable storage engine API.

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-13475:
-

Personally, I’m pretty -1 on the idea of adding a new storage engine api. This 
should focus on fixing the leaks in the interfaces currently exposed by 
Keyspace and CFS, and using them as the primary extension points. Using these 2 
classes as extension points should also reduce the surface area of things 
you’ll need to refactor.

> First version of pluggable storage engine API.
> --
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> In order to support pluggable storage engine, we need to define a unified 
> interface/API, which can allow us to plug in different storage engines for 
> different requirements. 
> Here is a design quip we are currently working on:  
> https://quip.com/bhw5ABUCi3co
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.



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

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

[jira] [Commented] (CASSANDRA-13999) Segfault during memtable flush

[Ricardo Bartolome (JIRA)]

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

Ricardo Bartolome commented on CASSANDRA-13999:
---

Hi [~beobal]. We just realised the debug.log fragment we provided initially is 
wrong, because it's related with a different stacktrace that we got in the 
meanwhile and we think it's related.

So I did the following:
* Deleted node_crashing_debug.log to avoid confussion
* Upload flush_exception_debug_fragment.log.obfuscated which is what we get 
from our logging system (we no longer have the debug.log files. We'll custody 
them more carefully next time)

In regards with the other segfault we suffered, which we think it's related and 
stacktrace is very similar to CASSANDRA-12590
* Upload cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated
* Upload compaction_exception_debug_fragment.obfuscated.log, which is the 
debug.log fragment that you saw initially.

> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated, 
> cassandra_config.yaml, compaction_exception_debug_fragment.obfuscated.log, 
> flush_exception_debug_fragment.obfuscated.log
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c [0x7f8e9f168400+0x16c]
> J 6720 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 
> 0x7f8e9def73c4 [0x7f8e9def72c0+0x104]
> J 22079 C2 java.lang.Thread.run()V (17 bytes) @ 0x7f8e9e67c4ac 
> [0x7f8e9e67c460+0x4c]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x691d16]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x692221]  JavaCalls::call_virtual(JavaValue*, KlassHandle, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x6926c7]  JavaCalls::call_virtual(JavaValue*, Handle, 
> KlassHandle, Symbol*, Symbol*, Thread*)+0x47
> V  [libjvm.so+0x72da50]  thread_entry(JavaThread*, Thread*)+0xa0
> V  [libjvm.so+0xa76833]  JavaThread::thread_main_inner()+0x103
> V  [libjvm.so+0xa7697c]  JavaThread::run()+0x11c
> V  [libjvm.so+0x927568]  java_start(Thread*)+0x108
> C  [libpthread.so.0+0x7de5]  start_thread+0xc5
> {code}
> For further details, we attached:
> * JVM error file with all details
> * cassandra config file (we are using offheap_buffers as 
> memtable_allocation_method)
> * some lines printed in debug.log when the JVM error file was created and 
> process died
> h5. Reproducing the issue
> So far we have been unable to reproduce it. It happens once/twice a week on 
> single nodes. It happens either during high load or low load times. We have 
> seen that when we replace EC2 instances and bootstrap new ones, due to 
> compactions happening on source nodes before stream starts, sometimes more 
> than a single node was affected by this, letting us with 2 out of 3 replicas 
> out and UnavailableExceptions in the cluster.
> This issue might have relation with CASSANDRA-12590 (Segfault reading 
> secondary index) even this is the write path. Can someone confirm if both 
> issues 

[jira] [Updated] (CASSANDRA-13999) Segfault during memtable flush

[Ricardo Bartolome (JIRA)]

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

Ricardo Bartolome updated CASSANDRA-13999:
--
Attachment: flush_exception_debug_fragment.obfuscated.log
compaction_exception_debug_fragment.obfuscated.log
cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated

> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra-jvm-file-error-1509717499-pid10419.log.obfuscated, 
> cassandra_config.yaml, compaction_exception_debug_fragment.obfuscated.log, 
> flush_exception_debug_fragment.obfuscated.log
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c [0x7f8e9f168400+0x16c]
> J 6720 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 
> 0x7f8e9def73c4 [0x7f8e9def72c0+0x104]
> J 22079 C2 java.lang.Thread.run()V (17 bytes) @ 0x7f8e9e67c4ac 
> [0x7f8e9e67c460+0x4c]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x691d16]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x692221]  JavaCalls::call_virtual(JavaValue*, KlassHandle, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x6926c7]  JavaCalls::call_virtual(JavaValue*, Handle, 
> KlassHandle, Symbol*, Symbol*, Thread*)+0x47
> V  [libjvm.so+0x72da50]  thread_entry(JavaThread*, Thread*)+0xa0
> V  [libjvm.so+0xa76833]  JavaThread::thread_main_inner()+0x103
> V  [libjvm.so+0xa7697c]  JavaThread::run()+0x11c
> V  [libjvm.so+0x927568]  java_start(Thread*)+0x108
> C  [libpthread.so.0+0x7de5]  start_thread+0xc5
> {code}
> For further details, we attached:
> * JVM error file with all details
> * cassandra config file (we are using offheap_buffers as 
> memtable_allocation_method)
> * some lines printed in debug.log when the JVM error file was created and 
> process died
> h5. Reproducing the issue
> So far we have been unable to reproduce it. It happens once/twice a week on 
> single nodes. It happens either during high load or low load times. We have 
> seen that when we replace EC2 instances and bootstrap new ones, due to 
> compactions happening on source nodes before stream starts, sometimes more 
> than a single node was affected by this, letting us with 2 out of 3 replicas 
> out and UnavailableExceptions in the cluster.
> This issue might have relation with CASSANDRA-12590 (Segfault reading 
> secondary index) even this is the write path. Can someone confirm if both 
> issues could be related? 
> h5. Specifics of our scenario:
> * Cassandra 3.9 on Amazon Linux (previous to this, we were running Cassandra 
> 2.0.9 and there are no records of this also happening, even I was not working 
> on Cassandra)
> * 12 x i3.2xlarge EC2 instances (8 core, 64GB RAM)
> * a total of 176 keyspaces (there is a per-customer pattern)
> ** Some keyspaces have a single table, while others have 2 or 5 tables
> ** There is a table that uses standard Secondary Indexes ("emailindex" on 
> "user_info" table)
> * It happens on both Oracle JDK 1.8.0_112 and 1.8.0_131
> * It happens in both kernel 

[jira] [Updated] (CASSANDRA-13999) Segfault during memtable flush

[Ricardo Bartolome (JIRA)]

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

Ricardo Bartolome updated CASSANDRA-13999:
--
Attachment: (was: node_crashing_debug.log)

> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra_config.yaml
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c [0x7f8e9f168400+0x16c]
> J 6720 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 
> 0x7f8e9def73c4 [0x7f8e9def72c0+0x104]
> J 22079 C2 java.lang.Thread.run()V (17 bytes) @ 0x7f8e9e67c4ac 
> [0x7f8e9e67c460+0x4c]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x691d16]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x692221]  JavaCalls::call_virtual(JavaValue*, KlassHandle, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x6926c7]  JavaCalls::call_virtual(JavaValue*, Handle, 
> KlassHandle, Symbol*, Symbol*, Thread*)+0x47
> V  [libjvm.so+0x72da50]  thread_entry(JavaThread*, Thread*)+0xa0
> V  [libjvm.so+0xa76833]  JavaThread::thread_main_inner()+0x103
> V  [libjvm.so+0xa7697c]  JavaThread::run()+0x11c
> V  [libjvm.so+0x927568]  java_start(Thread*)+0x108
> C  [libpthread.so.0+0x7de5]  start_thread+0xc5
> {code}
> For further details, we attached:
> * JVM error file with all details
> * cassandra config file (we are using offheap_buffers as 
> memtable_allocation_method)
> * some lines printed in debug.log when the JVM error file was created and 
> process died
> h5. Reproducing the issue
> So far we have been unable to reproduce it. It happens once/twice a week on 
> single nodes. It happens either during high load or low load times. We have 
> seen that when we replace EC2 instances and bootstrap new ones, due to 
> compactions happening on source nodes before stream starts, sometimes more 
> than a single node was affected by this, letting us with 2 out of 3 replicas 
> out and UnavailableExceptions in the cluster.
> This issue might have relation with CASSANDRA-12590 (Segfault reading 
> secondary index) even this is the write path. Can someone confirm if both 
> issues could be related? 
> h5. Specifics of our scenario:
> * Cassandra 3.9 on Amazon Linux (previous to this, we were running Cassandra 
> 2.0.9 and there are no records of this also happening, even I was not working 
> on Cassandra)
> * 12 x i3.2xlarge EC2 instances (8 core, 64GB RAM)
> * a total of 176 keyspaces (there is a per-customer pattern)
> ** Some keyspaces have a single table, while others have 2 or 5 tables
> ** There is a table that uses standard Secondary Indexes ("emailindex" on 
> "user_info" table)
> * It happens on both Oracle JDK 1.8.0_112 and 1.8.0_131
> * It happens in both kernel 4.9.43-17.38.amzn1.x86_64 and 
> 3.14.35-28.38.amzn1.x86_64
> h5. Possible workarounds/solutions that we have in mind (to be validated yet)
> * switching to heap_buffers (in case offheap_buffers triggers the bug), even 
> we are still pending to measure performance degradation under that scenario.
> * removing secondary 

[jira] [Commented] (CASSANDRA-13999) Segfault during memtable flush

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-13999:
-

[~ricbartm] is it possible to attach some more context from the debug log? The 
snippet you posted includes a line indicating that the flush of an index table 
is complete, but this happens after the point at which the segfault occurs. 
There should be a log message printed before calling into the BigTableWriter 
too, so I want to verify which memtable is actually being written when the 
fault happens. 


> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra_config.yaml, node_crashing_debug.log
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c [0x7f8e9f168400+0x16c]
> J 6720 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 
> 0x7f8e9def73c4 [0x7f8e9def72c0+0x104]
> J 22079 C2 java.lang.Thread.run()V (17 bytes) @ 0x7f8e9e67c4ac 
> [0x7f8e9e67c460+0x4c]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x691d16]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x692221]  JavaCalls::call_virtual(JavaValue*, KlassHandle, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x6926c7]  JavaCalls::call_virtual(JavaValue*, Handle, 
> KlassHandle, Symbol*, Symbol*, Thread*)+0x47
> V  [libjvm.so+0x72da50]  thread_entry(JavaThread*, Thread*)+0xa0
> V  [libjvm.so+0xa76833]  JavaThread::thread_main_inner()+0x103
> V  [libjvm.so+0xa7697c]  JavaThread::run()+0x11c
> V  [libjvm.so+0x927568]  java_start(Thread*)+0x108
> C  [libpthread.so.0+0x7de5]  start_thread+0xc5
> {code}
> For further details, we attached:
> * JVM error file with all details
> * cassandra config file (we are using offheap_buffers as 
> memtable_allocation_method)
> * some lines printed in debug.log when the JVM error file was created and 
> process died
> h5. Reproducing the issue
> So far we have been unable to reproduce it. It happens once/twice a week on 
> single nodes. It happens either during high load or low load times. We have 
> seen that when we replace EC2 instances and bootstrap new ones, due to 
> compactions happening on source nodes before stream starts, sometimes more 
> than a single node was affected by this, letting us with 2 out of 3 replicas 
> out and UnavailableExceptions in the cluster.
> This issue might have relation with CASSANDRA-12590 (Segfault reading 
> secondary index) even this is the write path. Can someone confirm if both 
> issues could be related? 
> h5. Specifics of our scenario:
> * Cassandra 3.9 on Amazon Linux (previous to this, we were running Cassandra 
> 2.0.9 and there are no records of this also happening, even I was not working 
> on Cassandra)
> * 12 x i3.2xlarge EC2 instances (8 core, 64GB RAM)
> * a total of 176 keyspaces (there is a per-customer pattern)
> ** Some keyspaces have a single table, while others have 2 or 5 tables
> ** There is a table that uses standard Secondary Indexes ("emailindex" on 
> "user_info" 

cassandra-dtest git commit: Tests for CASSANDRA-10857

[ifesdjeen]

Repository: cassandra-dtest
Updated Branches:
  refs/heads/master 01df7c498 -> 8e65211b9


Tests for CASSANDRA-10857


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

Branch: refs/heads/master
Commit: 8e65211b9483f35f021c34a8bc7107c819eb0766
Parents: 01df7c4
Author: Alex Petrov 
Authored: Tue Oct 24 13:41:35 2017 +0200
Committer: Alex Petrov 
Committed: Thu Nov 9 13:37:03 2017 +0100

--
 consistency_test.py  |   2 +-
 counter_tests.py |   2 +
 cql_tests.py |  91 --
 dtest.py |   4 +
 materialized_views_test.py   |   4 +-
 paging_test.py   | 231 --
 schema_metadata_test.py  |   2 +
 schema_test.py   |   2 +
 secondary_indexes_test.py|  18 +-
 sstable_generation_loading_test.py   |   2 +-
 upgrade_tests/upgrade_compact_storage.py | 176 
 write_failures_test.py   |   6 +-
 12 files changed, 430 insertions(+), 110 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/8e65211b/consistency_test.py
--
diff --git a/consistency_test.py b/consistency_test.py
index ccc7ee6..40c794d 100644
--- a/consistency_test.py
+++ b/consistency_test.py
@@ -170,7 +170,7 @@ class TestHelper(Tester):
 firstname text,
 lastname text,
 age int
-) WITH COMPACT STORAGE"""
+)"""
 
 if requires_local_reads:
 create_cmd += " AND " + self.get_local_reads_properties()

http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/8e65211b/counter_tests.py
--
diff --git a/counter_tests.py b/counter_tests.py
index da2ed09..48985a9 100644
--- a/counter_tests.py
+++ b/counter_tests.py
@@ -334,6 +334,7 @@ class TestCounters(Tester):
 
 self.assertEqual(v, count[0][0])
 
+@since("2.0", max_version="3.X")
 def validate_empty_column_name_test(self):
 cluster = self.cluster
 cluster.populate(1).start()
@@ -379,6 +380,7 @@ class TestCounters(Tester):
 
 assert_invalid(session, "ALTER TABLE counter_bug add c counter", 
"Cannot re-add previously dropped counter column c")
 
+@since("2.0", max_version="3.X") # Compact Storage
 def compact_counter_cluster_test(self):
 """
 @jira_ticket CASSANDRA-12219

http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/8e65211b/cql_tests.py
--
diff --git a/cql_tests.py b/cql_tests.py
index 64d30ba..b4ac02f 100644
--- a/cql_tests.py
+++ b/cql_tests.py
@@ -19,6 +19,7 @@ from thrift_bindings.v22.ttypes import (CfDef, Column, 
ColumnOrSuperColumn,
 from thrift_tests import get_thrift_client
 from tools.assertions import (assert_all, assert_invalid, assert_length_equal,
   assert_none, assert_one, assert_unavailable)
+from tools.data import rows_to_list
 from tools.decorators import since
 from tools.metadata_wrapper import (UpdatingClusterMetadataWrapper,
 UpdatingKeyspaceMetadataWrapper,
@@ -106,11 +107,8 @@ class StorageProxyCQLTester(CQLTester):
 """
 Smoke test that basic table operations work:
 
-- create 2 tables, one with and one without COMPACT STORAGE
-- ALTER the table without COMPACT STORAGE, adding a column
-
-For each of those tables:
-
+- create a table
+- ALTER the table adding a column
 - insert 10 values
 - SELECT * and assert the values are there
 - TRUNCATE the table
@@ -125,8 +123,6 @@ class StorageProxyCQLTester(CQLTester):
 
 session.execute("CREATE TABLE test1 (k int PRIMARY KEY, v1 int)")
 self.assertIn('test1', ks_meta.tables)
-session.execute("CREATE TABLE test2 (k int, c1 int, v1 int, PRIMARY 
KEY (k, c1)) WITH COMPACT STORAGE")
-self.assertIn('test2', ks_meta.tables)
 
 t1_meta = UpdatingTableMetadataWrapper(session.cluster, ks_name='ks', 
table_name='test1')
 
@@ -135,21 +131,46 @@ class StorageProxyCQLTester(CQLTester):
 
 for i in range(0, 10):
 session.execute("INSERT INTO test1 (k, v1, v2) VALUES ({i}, {i}, 
{i})".format(i=i))
-session.execute("INSERT INTO test2 (k, c1, v1) VALUES ({i}, {i}, 

[jira] [Commented] (CASSANDRA-13975) Add a workaround for overly large read repair mutations

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-13975:
-

LGTM, modulo an exceeding minor nit about inconsistent whitespace at the top of 
{{sendRepairMutation}}, feel free to fix on commit.

> Add a workaround for overly large read repair mutations
> ---
>
> Key: CASSANDRA-13975
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13975
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.11.x
>
>
> It's currently possible for {{DataResolver}} to accumulate more changes to 
> read repair that would fit in a single serialized mutation. If that happens, 
> the node receiving the mutation would fail, and the read would time out, and 
> won't be able to proceed until the operator runs repair or manually drops the 
> affected partitions.
> Ideally we should either read repair iteratively, or at least split the 
> resulting mutation into smaller chunks in the end. In the meantime, for 
> 3.0.x, I suggest we add logging to catch this, and a -D flag to allow 
> proceeding with the requests as is when the mutation is too large, without 
> read repair.



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

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

[jira] [Updated] (CASSANDRA-13975) Add a workaround for overly large read repair mutations

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-13975:

Status: Ready to Commit  (was: Patch Available)

> Add a workaround for overly large read repair mutations
> ---
>
> Key: CASSANDRA-13975
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13975
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.11.x
>
>
> It's currently possible for {{DataResolver}} to accumulate more changes to 
> read repair that would fit in a single serialized mutation. If that happens, 
> the node receiving the mutation would fail, and the read would time out, and 
> won't be able to proceed until the operator runs repair or manually drops the 
> affected partitions.
> Ideally we should either read repair iteratively, or at least split the 
> resulting mutation into smaller chunks in the end. In the meantime, for 
> 3.0.x, I suggest we add logging to catch this, and a -D flag to allow 
> proceeding with the requests as is when the mutation is too large, without 
> read repair.



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

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

[jira] [Commented] (CASSANDRA-13999) Segfault during memtable flush

[mck (JIRA)]

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

mck commented on CASSANDRA-13999:
-

{quote}Upgrading to 3.11.1 is an option, but we are trying to keep it as last 
resort given that the cost of migrating is big and we don't have any guarantee 
that new bugs that affects nodes availability are not introduced.{quote}

This is of course advice the community will generally recommend, especially as 
3.9 to 3.11.1 is effectively three patch (bugfix) only releases.

{quote}Stack…{quote}

The native stack frame translates to
{noformat}
org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(..) 
org.apache.cassandra.db.Memtable:458
org.apache.cassandra.db.Memtable:493
{noformat}

The DecoratedKey from the iterator uses a LocalToken (because 2nd index) which 
was the ByteBuffer issue fixed in 
https://github.com/apache/cassandra/commit/820e7a8d810828d29f98a68dc35be33b40a5de62
 (CASSANDRA-12651)

[~beobal], [~ifesdjeen], does this seem valid? I'm unsure of the statement 
within BigTableWriter.append(..) that actually would be hitting key.token 



> Segfault during memtable flush
> --
>
> Key: CASSANDRA-13999
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13999
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: * Cassandra 3.9
> * Oracle JDK 1.8.0_112 and 1.8.0_131
> * Kernel 4.9.43-17.38.amzn1.x86_64 and 3.14.35-28.38.amzn1.x86_64
>Reporter: Ricardo Bartolome
>Priority: Critical
> Attachments: 
> cassandra-jvm-file-error-1509698372-pid16151.log.obfuscated, 
> cassandra_config.yaml, node_crashing_debug.log
>
>
> We are getting segfaults on a production Cassandra cluster, apparently caused 
> by Memtable flushes to disk.
> {code}
> Current thread (0x0cd77920):  JavaThread 
> "PerDiskMemtableFlushWriter_0:140" daemon [_thread_in_Java, id=28952, 
> stack(0x7f8b7aa53000,0x7f8b7aa94000)]
> {code}
> Stack
> {code}
> Stack: [0x7f8b7aa53000,0x7f8b7aa94000],  sp=0x7f8b7aa924a0,  free 
> space=253k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 21889 C2 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;)Lorg/apache/cassandra/db/RowIndexEntry;
>  (361 bytes) @ 0x7f8e9fcf75ac [0x7f8e9fcf42c0+0x32ec]
> J 22464 C2 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents()V (383 
> bytes) @ 0x7f8e9f17b988 [0x7f8e9f17b5c0+0x3c8]
> j  
> org.apache.cassandra.db.Memtable$FlushRunnable.call()Lorg/apache/cassandra/io/sstable/SSTableMultiWriter;+1
> j  org.apache.cassandra.db.Memtable$FlushRunnable.call()Ljava/lang/Object;+1
> J 18865 C2 java.util.concurrent.FutureTask.run()V (126 bytes) @ 
> 0x7f8e9d3c9540 [0x7f8e9d3c93a0+0x1a0]
> J 21832 C2 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
>  (225 bytes) @ 0x7f8e9f16856c [0x7f8e9f168400+0x16c]
> J 6720 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 
> 0x7f8e9def73c4 [0x7f8e9def72c0+0x104]
> J 22079 C2 java.lang.Thread.run()V (17 bytes) @ 0x7f8e9e67c4ac 
> [0x7f8e9e67c460+0x4c]
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x691d16]  JavaCalls::call_helper(JavaValue*, methodHandle*, 
> JavaCallArguments*, Thread*)+0x1056
> V  [libjvm.so+0x692221]  JavaCalls::call_virtual(JavaValue*, KlassHandle, 
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
> V  [libjvm.so+0x6926c7]  JavaCalls::call_virtual(JavaValue*, Handle, 
> KlassHandle, Symbol*, Symbol*, Thread*)+0x47
> V  [libjvm.so+0x72da50]  thread_entry(JavaThread*, Thread*)+0xa0
> V  [libjvm.so+0xa76833]  JavaThread::thread_main_inner()+0x103
> V  [libjvm.so+0xa7697c]  JavaThread::run()+0x11c
> V  [libjvm.so+0x927568]  java_start(Thread*)+0x108
> C  [libpthread.so.0+0x7de5]  start_thread+0xc5
> {code}
> For further details, we attached:
> * JVM error file with all details
> * cassandra config file (we are using offheap_buffers as 
> memtable_allocation_method)
> * some lines printed in debug.log when the JVM error file was created and 
> process died
> h5. Reproducing the issue
> So far we have been unable to reproduce it. It happens once/twice a week on 
> single nodes. It happens either during high load or low load times. We have 
> seen that when we replace EC2 instances and bootstrap new ones, due to 
> compactions happening on source nodes before stream starts, sometimes more 
> than a single node was affected by this, letting us with 2 out of 3 replicas 
> out and UnavailableExceptions in the cluster.
> This issue might have relation with CASSANDRA-12590 (Segfault reading 
> secondary index) even this is the write path. Can 

[jira] [Resolved] (CASSANDRA-14004) Increase Guava upstream version API compatibility

[Jason Brown (JIRA)]

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

Jason Brown resolved CASSANDRA-14004.
-
Resolution: Won't Fix

> Increase Guava upstream version API compatibility
> -
>
> Key: CASSANDRA-14004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14004
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Thibault Kruse
>Priority: Minor
>
> Using cassandra-all as a java library has the downside that it uses guava 18 
> methods that have been removed from more recent guava versions, causing users 
> to be forced to stick with Guava <= 19.0.
> It would be nice for us if such method calls to guava could be replaced with 
> code of higher compatibility, for Casandra versions as far back as 3.0.x
> As an example replacing code like this
> Iterators.emptyIterator()
> with
> Collections.emptyIterator()
> as done in
> https://github.com/krummas/cassandra/commits/marcuse/guava23
> Ensuring any cassandra-release is API compatible with several guava versions 
> is more painful, possibly a blacklist of method calls can be used via 
> checkstyle to reduce the risk of re-introducing version specific calls to 
> guava methods.
> Related to the Guava upgrade ticket: 
> https://issues.apache.org/jira/browse/CASSANDRA-13997



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

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

[jira] [Comment Edited] (CASSANDRA-13992) Don't send new_metadata_id for conditional updates

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-13992 at 11/9/17 10:29 AM:
---

If we take this patch, I'd definitely constantize the "empty" hash, as very 
least.

Other than that - I think we should add more tests with LWTs (preferably 
dtests) and check what happens when we actually alter the table. Since in this 
case it seems what will happen is when table is ALTER'ed, metadata won't update 
(I haven't checked it though). In the initial patch we've tried always forcing 
metadata transfer for LWTs. If the patch has the same effect (metadata is 
transferred every time). I'm not insisting on any particular solution here 
though.  


was (Author: ifesdjeen):
If we take this patch, I'd definitely constantize the "empty" hash, as very 
least.

Other than that - I think we should add more tests with LWTs (preferably 
dtests) and check what happens when we actually alter the table. In the initial 
patch we've tried always forcing metadata transfer for LWTs. If the patch has 
the same effect (metadata is transferred every time). I'm not insisting on any 
particular solution here though.  

> Don't send new_metadata_id for conditional updates
> --
>
> Key: CASSANDRA-13992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13992
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Olivier Michallat
>Assignee: Kurt Greaves
>Priority: Minor
>
> This is a follow-up to CASSANDRA-10786.
> Given the table
> {code}
> CREATE TABLE foo (k int PRIMARY KEY)
> {code}
> And the prepared statement
> {code}
> INSERT INTO foo (k) VALUES (?) IF NOT EXISTS
> {code}
> The result set metadata changes depending on the outcome of the update:
> * if the row didn't exist, there is only a single column \[applied] = true
> * if it did, the result contains \[applied] = false, plus the current value 
> of column k.
> The way this was handled so far is that the PREPARED response contains no 
> result set metadata, and therefore all EXECUTE messages have SKIP_METADATA = 
> false, and the responses always include the full (and correct) metadata.
> CASSANDRA-10786 still sends the PREPARED response with no metadata, *but the 
> response to EXECUTE now contains a {{new_metadata_id}}*. The driver thinks it 
> is because of a schema change, and updates its local copy of the prepared 
> statement's result metadata.
> The next EXECUTE is sent with SKIP_METADATA = true, but the server appears to 
> ignore that, and still sends the metadata in the response. So each response 
> includes the correct metadata, the driver uses it, and there is no visible 
> issue for client code.
> The only drawback is that the driver updates its local copy of the metadata 
> unnecessarily, every time. We can work around that by only updating if we had 
> metadata before, at the cost of an extra volatile read. But I think the best 
> thing to do would be to never send a {{new_metadata_id}} in for a conditional 
> update.



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

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

[jira] [Commented] (CASSANDRA-13992) Don't send new_metadata_id for conditional updates

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-13992:
-

If we take this patch, I'd definitely constantize the "empty" hash, as very 
least.

Other than that - I think we should add more tests with LWTs (preferably 
dtests) and check what happens when we actually alter the table. In the initial 
patch we've tried always forcing metadata transfer for LWTs. If the patch has 
the same effect (metadata is transferred every time). I'm not insisting on any 
particular solution here though.  

> Don't send new_metadata_id for conditional updates
> --
>
> Key: CASSANDRA-13992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13992
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Olivier Michallat
>Assignee: Kurt Greaves
>Priority: Minor
>
> This is a follow-up to CASSANDRA-10786.
> Given the table
> {code}
> CREATE TABLE foo (k int PRIMARY KEY)
> {code}
> And the prepared statement
> {code}
> INSERT INTO foo (k) VALUES (?) IF NOT EXISTS
> {code}
> The result set metadata changes depending on the outcome of the update:
> * if the row didn't exist, there is only a single column \[applied] = true
> * if it did, the result contains \[applied] = false, plus the current value 
> of column k.
> The way this was handled so far is that the PREPARED response contains no 
> result set metadata, and therefore all EXECUTE messages have SKIP_METADATA = 
> false, and the responses always include the full (and correct) metadata.
> CASSANDRA-10786 still sends the PREPARED response with no metadata, *but the 
> response to EXECUTE now contains a {{new_metadata_id}}*. The driver thinks it 
> is because of a schema change, and updates its local copy of the prepared 
> statement's result metadata.
> The next EXECUTE is sent with SKIP_METADATA = true, but the server appears to 
> ignore that, and still sends the metadata in the response. So each response 
> includes the correct metadata, the driver uses it, and there is no visible 
> issue for client code.
> The only drawback is that the driver updates its local copy of the metadata 
> unnecessarily, every time. We can work around that by only updating if we had 
> metadata before, at the cost of an extra volatile read. But I think the best 
> thing to do would be to never send a {{new_metadata_id}} in for a conditional 
> update.



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

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

[jira] [Commented] (CASSANDRA-14000) Remove v5 as a beta version from 3.11

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-14000:
-

As discussed on the dev mailing list, v5 was beta in 3.11, therefore it's ok to 
break it there. It was never intended to be feature-full, but rather it was 
suggested so push the features out in 3.11.

> Remove v5 as a beta version from 3.11 
> --
>
> Key: CASSANDRA-14000
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14000
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Blocker
>
> Currently, V5 has only two features (if anyone knows other ones, please 
> correct me): 
>   * [CASSANDRA-10786]
>   * [CASSANDRA-12838]
> V5 "beta" mode was suggested in [CASSANDRA-12142], hoping that we can release 
> more features quicker. However, we did not. 
> I suggest we remove v5 protocol support from 3.11, as all the new features go 
> into 4.0 anyways and protocol is on an early stage, so most likely there will 
> be a couple more changes.
> UPDATE: [CASSANDRA-12838] adds a {{DURATION}} type, which can not be done any 
> way other than bumping a protocol version. The problem is 



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

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

[jira] [Resolved] (CASSANDRA-14000) Remove v5 as a beta version from 3.11

[Alex Petrov (JIRA)]

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

Alex Petrov resolved CASSANDRA-14000.
-
Resolution: Won't Fix

> Remove v5 as a beta version from 3.11 
> --
>
> Key: CASSANDRA-14000
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14000
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Blocker
>
> Currently, V5 has only two features (if anyone knows other ones, please 
> correct me): 
>   * [CASSANDRA-10786]
>   * [CASSANDRA-12838]
> V5 "beta" mode was suggested in [CASSANDRA-12142], hoping that we can release 
> more features quicker. However, we did not. 
> I suggest we remove v5 protocol support from 3.11, as all the new features go 
> into 4.0 anyways and protocol is on an early stage, so most likely there will 
> be a couple more changes.
> UPDATE: [CASSANDRA-12838] adds a {{DURATION}} type, which can not be done any 
> way other than bumping a protocol version. The problem is 



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

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

[jira] [Comment Edited] (CASSANDRA-14002) Don't use SHA256 when building merkle trees

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson edited comment on CASSANDRA-14002 at 11/9/17 9:17 AM:
--

also pushed a new commit after rebasing on latest trunk (upgrade guava to 23.3) 
if you could have a look [~mkjellman] 
(https://github.com/krummas/cassandra/commits/marcuse/nosharepairs)


was (Author: krummas):
also pushed a new commit after rebasing on latest trunk (upgrade guava to 23.3) 
if you could have a look [~mkjellman]

> Don't use SHA256 when building merkle trees
> ---
>
> Key: CASSANDRA-14002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14002
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> We should avoid using SHA-2 when building merkle trees as we don't need a 
> cryptographic hash function for this.



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

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

[jira] [Commented] (CASSANDRA-14002) Don't use SHA256 when building merkle trees

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-14002:
-

also pushed a new commit after rebasing on latest trunk (upgrade guava to 23.3) 
if you could have a look [~mkjellman]

> Don't use SHA256 when building merkle trees
> ---
>
> Key: CASSANDRA-14002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14002
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> We should avoid using SHA-2 when building merkle trees as we don't need a 
> cryptographic hash function for this.



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

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

[jira] [Updated] (CASSANDRA-13997) Upgrade Guava to 23.3 and Airline to 0.8

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13997:
---
Attachment: airline-0.8.jar.asc
guava-23.3-jre.jar.asc

> Upgrade Guava to 23.3 and Airline to 0.8
> 
>
> Key: CASSANDRA-13997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13997
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.0
>
> Attachments: airline-0.8.jar.asc, guava-23.3-jre.jar.asc
>
>
> For 4.0 we should upgrade guava to the latest version
> patch here: https://github.com/krummas/cassandra/commits/marcuse/guava23
> A bunch of quite commonly used methods have been deprecated since guava 18 
> which we use now ({{Throwables.propagate}} for example), this patch mostly 
> updates uses where compilation fails. {{Futures.transform(ListenableFuture 
> ..., AsyncFunction ...}} was deprecated in Guava 19 and removed in 20 for 
> example, we should probably open new tickets to remove calls to all 
> deprecated guava methods.
> Also had to add a dependency on {{com.google.j2objc.j2objc-annotations}}, to 
> avoid some build-time warnings (maybe due to 
> https://github.com/google/guava/commit/fffd2b1f67d158c7b4052123c5032b0ba54a910d
>  ?)



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

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

[jira] [Updated] (CASSANDRA-13997) Upgrade Guava to 23.3 and Airline to 0.8

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13997:

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

Committed as {{ec6282242b806594d9d590aae4b494d56126075e}}, thanks!

> Upgrade Guava to 23.3 and Airline to 0.8
> 
>
> Key: CASSANDRA-13997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13997
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.0
>
>
> For 4.0 we should upgrade guava to the latest version
> patch here: https://github.com/krummas/cassandra/commits/marcuse/guava23
> A bunch of quite commonly used methods have been deprecated since guava 18 
> which we use now ({{Throwables.propagate}} for example), this patch mostly 
> updates uses where compilation fails. {{Futures.transform(ListenableFuture 
> ..., AsyncFunction ...}} was deprecated in Guava 19 and removed in 20 for 
> example, we should probably open new tickets to remove calls to all 
> deprecated guava methods.
> Also had to add a dependency on {{com.google.j2objc.j2objc-annotations}}, to 
> avoid some build-time warnings (maybe due to 
> https://github.com/google/guava/commit/fffd2b1f67d158c7b4052123c5032b0ba54a910d
>  ?)



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

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

[jira] [Updated] (CASSANDRA-13997) Upgrade Guava to 23.3 and Airline to 0.8

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-13997:

Summary: Upgrade Guava to 23.3 and Airline to 0.8  (was: Upgrade guava to 
23.3)

> Upgrade Guava to 23.3 and Airline to 0.8
> 
>
> Key: CASSANDRA-13997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13997
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> For 4.0 we should upgrade guava to the latest version
> patch here: https://github.com/krummas/cassandra/commits/marcuse/guava23
> A bunch of quite commonly used methods have been deprecated since guava 18 
> which we use now ({{Throwables.propagate}} for example), this patch mostly 
> updates uses where compilation fails. {{Futures.transform(ListenableFuture 
> ..., AsyncFunction ...}} was deprecated in Guava 19 and removed in 20 for 
> example, we should probably open new tickets to remove calls to all 
> deprecated guava methods.
> Also had to add a dependency on {{com.google.j2objc.j2objc-annotations}}, to 
> avoid some build-time warnings (maybe due to 
> https://github.com/google/guava/commit/fffd2b1f67d158c7b4052123c5032b0ba54a910d
>  ?)



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

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

cassandra git commit: Upgrade Guava to 23.3 and Airline to 0.8

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/trunk ba5f946e5 -> ec6282242


Upgrade Guava to 23.3 and Airline to 0.8

Patch by marcuse; reviewed by Stefan Podkowinski for CASSANDRA-13997


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

Branch: refs/heads/trunk
Commit: ec6282242b806594d9d590aae4b494d56126075e
Parents: ba5f946
Author: Marcus Eriksson 
Authored: Mon Nov 6 10:22:33 2017 +0100
Committer: Marcus Eriksson 
Committed: Thu Nov 9 09:51:05 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   4 +-
 lib/airline-0.7.jar | Bin 85912 -> 0 bytes
 lib/airline-0.8.jar | Bin 0 -> 78439 bytes
 lib/guava-18.0.jar  | Bin 2256213 -> 0 bytes
 lib/guava-23.3-jre.jar  | Bin 0 -> 2655564 bytes
 lib/j2objc-annotations-1.3.jar  | Bin 0 -> 8781 bytes
 lib/licenses/airline-0.6.txt| 202 ---
 lib/licenses/airline-0.8.txt| 202 +++
 lib/licenses/guava-18.0.txt | 202 ---
 lib/licenses/guava-23.3-jre.txt | 202 +++
 lib/licenses/j2objc-annotations-1.3.txt | 202 +++
 .../org/apache/cassandra/repair/RepairJob.java  |   4 +-
 .../apache/cassandra/repair/RepairRunnable.java |   6 +-
 .../org/apache/cassandra/repair/Validator.java  |   7 +
 .../repair/consistent/CoordinatorSession.java   |   9 +-
 .../consistent/PendingAntiCompaction.java   |   3 +-
 .../cassandra/service/ActiveRepairService.java  |   2 +-
 18 files changed, 629 insertions(+), 417 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec628224/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d627473..26cee74 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Upgrade Guava to 23.3 and Airline to 0.8 (CASSANDRA-13997)
  * Allow only one concurrent call to StatusLogger (CASSANDRA-12182)
  * Refactoring to specialised functional interfaces (CASSANDRA-13982)
  * Speculative retry should allow more friendly params (CASSANDRA-13876)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec628224/build.xml
--
diff --git a/build.xml b/build.xml
index 35f1375..1608fba 100644
--- a/build.xml
+++ b/build.xml
@@ -360,7 +360,7 @@
   
   
   
-  
+  
   
   
   
@@ -419,7 +419,7 @@
   
   
   
-  
+  
   
   
   

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec628224/lib/airline-0.7.jar
--
diff --git a/lib/airline-0.7.jar b/lib/airline-0.7.jar
deleted file mode 100644
index b5a7b01..000
Binary files a/lib/airline-0.7.jar and /dev/null differ

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec628224/lib/airline-0.8.jar
--
diff --git a/lib/airline-0.8.jar b/lib/airline-0.8.jar
new file mode 100644
index 000..a34c945
Binary files /dev/null and b/lib/airline-0.8.jar differ

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec628224/lib/guava-18.0.jar
--
diff --git a/lib/guava-18.0.jar b/lib/guava-18.0.jar
deleted file mode 100644
index 8f89e49..000
Binary files a/lib/guava-18.0.jar and /dev/null differ

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec628224/lib/guava-23.3-jre.jar
--
diff --git a/lib/guava-23.3-jre.jar b/lib/guava-23.3-jre.jar
new file mode 100644
index 000..b13e275
Binary files /dev/null and b/lib/guava-23.3-jre.jar differ

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec628224/lib/j2objc-annotations-1.3.jar
--
diff --git a/lib/j2objc-annotations-1.3.jar b/lib/j2objc-annotations-1.3.jar
new file mode 100644
index 000..a429c72
Binary files /dev/null and b/lib/j2objc-annotations-1.3.jar differ

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec628224/lib/licenses/airline-0.6.txt
--
diff --git a/lib/licenses/airline-0.6.txt 

[jira] [Commented] (CASSANDRA-13997) Upgrade guava to 23.3

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13997:


+1
Should get changes.txt entry, but looks fine otherwise.

> Upgrade guava to 23.3
> -
>
> Key: CASSANDRA-13997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13997
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> For 4.0 we should upgrade guava to the latest version
> patch here: https://github.com/krummas/cassandra/commits/marcuse/guava23
> A bunch of quite commonly used methods have been deprecated since guava 18 
> which we use now ({{Throwables.propagate}} for example), this patch mostly 
> updates uses where compilation fails. {{Futures.transform(ListenableFuture 
> ..., AsyncFunction ...}} was deprecated in Guava 19 and removed in 20 for 
> example, we should probably open new tickets to remove calls to all 
> deprecated guava methods.
> Also had to add a dependency on {{com.google.j2objc.j2objc-annotations}}, to 
> avoid some build-time warnings (maybe due to 
> https://github.com/google/guava/commit/fffd2b1f67d158c7b4052123c5032b0ba54a910d
>  ?)



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

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

[jira] [Updated] (CASSANDRA-13997) Upgrade guava to 23.3

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13997:
---
Component/s: Libraries

> Upgrade guava to 23.3
> -
>
> Key: CASSANDRA-13997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13997
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> For 4.0 we should upgrade guava to the latest version
> patch here: https://github.com/krummas/cassandra/commits/marcuse/guava23
> A bunch of quite commonly used methods have been deprecated since guava 18 
> which we use now ({{Throwables.propagate}} for example), this patch mostly 
> updates uses where compilation fails. {{Futures.transform(ListenableFuture 
> ..., AsyncFunction ...}} was deprecated in Guava 19 and removed in 20 for 
> example, we should probably open new tickets to remove calls to all 
> deprecated guava methods.
> Also had to add a dependency on {{com.google.j2objc.j2objc-annotations}}, to 
> avoid some build-time warnings (maybe due to 
> https://github.com/google/guava/commit/fffd2b1f67d158c7b4052123c5032b0ba54a910d
>  ?)



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

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

[jira] [Updated] (CASSANDRA-13997) Upgrade guava to 23.3

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13997:
---
Status: Ready to Commit  (was: Patch Available)

> Upgrade guava to 23.3
> -
>
> Key: CASSANDRA-13997
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13997
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> For 4.0 we should upgrade guava to the latest version
> patch here: https://github.com/krummas/cassandra/commits/marcuse/guava23
> A bunch of quite commonly used methods have been deprecated since guava 18 
> which we use now ({{Throwables.propagate}} for example), this patch mostly 
> updates uses where compilation fails. {{Futures.transform(ListenableFuture 
> ..., AsyncFunction ...}} was deprecated in Guava 19 and removed in 20 for 
> example, we should probably open new tickets to remove calls to all 
> deprecated guava methods.
> Also had to add a dependency on {{com.google.j2objc.j2objc-annotations}}, to 
> avoid some build-time warnings (maybe due to 
> https://github.com/google/guava/commit/fffd2b1f67d158c7b4052123c5032b0ba54a910d
>  ?)



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

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

[jira] [Commented] (CASSANDRA-14002) Don't use SHA256 when building merkle trees

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-14002:
-

thanks for the review!

bq. 50% faster is a bigger win than I expected when I saw it in profiling
yeah, I think the biggest win is actually that guavas streaming hashers 
actually buffer the data to be hashed instead of hashing them byte-for-byte: 
https://github.com/google/guava/blob/v23.3/guava/src/com/google/common/hash/AbstractStreamingHasher.java#L34

I'm rerunning the dtests 
[here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/424/]
 before committing

> Don't use SHA256 when building merkle trees
> ---
>
> Key: CASSANDRA-14002
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14002
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 4.x
>
>
> We should avoid using SHA-2 when building merkle trees as we don't need a 
> cryptographic hash function for this.



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

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