[jira] [Commented] (CASSANDRA-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892972#comment-16892972 ] Andy Tolbert commented on CASSANDRA-15248: -- [~sumanth.pasupuleti] had provided a patch for upgrading to Guava 27.0 in [CASSANDRA-14655]. There may be some follow on work to do with Guava 28 out and other code changing since then but that may be a good starting point. > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15248: -- Complexity: Low Hanging Fruit Change Category: Code Clarity Status: Open (was: Triage Needed) > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15243) removenode can cause QUORUM write queries to fail
[ https://issues.apache.org/jira/browse/CASSANDRA-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892911#comment-16892911 ] Tom van der Woerdt commented on CASSANDRA-15243: [~benedict] Interesting, good to know it was already on the radar :) One thing that the other issue doesn't seem to consider is that this can lead to an outage (like in my case, where an outage in one DC spread to the other two because of this issue). WDYT? > removenode can cause QUORUM write queries to fail > - > > Key: CASSANDRA-15243 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15243 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Tom van der Woerdt >Priority: Normal > > Looks like nobody found this yet so this may be a ticking time bomb for > some... :( > This happened to me earlier today. On a Cassandra 3.11.4 cluster with three > DCs, one DC had three servers fail due to unexpected external circumstances. > Replication was NTS configured with 2:2:2. > Cassandra dealt with the failures just fine - great! However, the nodes > failed in a way that would make bringing them back impossible, so I tried to > remove them using 'removenode'. > Suddenly, the application started experiencing a large number of QUORUM write > timeouts. My first reflex was to lower the streaming throughput and > compaction throughput, since timeouts indicated some overload was happening. > No luck, though. > I tried a bunch of other things to reroute queries away from the affected > datacenter, like changing the Severity field on the dynamic snitch. Still, no > luck. > After a while I noticed one strange thing: the WriteTimeoutException listed > that five replicas were required, instead of the four you would expect to see > in a 2:2:2 replication configuration. I shrugged it off as some weird > inconsistency that was probably because of the use of batches. > Skip ahead a bit, I decided to let the streams run again and just wait the > issue out, since nothing I did was working, and maybe just letting the > streams finish would resolve this overload. Magically, as soon as the streams > finished, the errors stopped. > > There are two issues here, both in AbstractWriteResponseHandler.java. > h3. Cassandra sometimes waits for too many replicas on writes > In > [totalBlockFor|https://github.com/apache/cassandra/blob/71cb0616b7710366a8cd364348c864d656dc5542/src/java/org/apache/cassandra/service/AbstractWriteResponseHandler.java#L124] > Cassandra will *always* include pending nodes in `blockfor`. In the case of > a quorum query on a 2:2:2 replication factor, with two replicas in one DC > down, this results in a blockfor of 5. If the pending replica is then also > down (as can happen in a case where removenode is used and not all > destination hosts are up), only 4 of the 5 hosts are available, and quorum > queries will never succeed. > h3. UnavailableException not thrown > While debugging this, I spent all my time focusing on this issue as if it was > a timeout. However, Cassandra was doing queries that could never succeed, > because insufficient hosts were available. Throwing an UnavailableException > would have been more helpful. The issue here is caused by > [assureSufficientLiveNodes|https://github.com/apache/cassandra/blob/71cb0616b7710366a8cd364348c864d656dc5542/src/java/org/apache/cassandra/service/AbstractWriteResponseHandler.java#L155] > which merely concats the lists of available nodes, and won't consider the > special-case behavior of a pending node that's down. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15248) Upgrade Guava to latest on master branch
Abhijit Sarkar created CASSANDRA-15248: -- Summary: Upgrade Guava to latest on master branch Key: CASSANDRA-15248 URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 Project: Cassandra Issue Type: Task Components: Build, Dependencies, Packaging Reporter: Abhijit Sarkar Upgrade Guava to latest on master branch. See https://issues.apache.org/jira/browse/CASSANDRA-15245. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15245) cassandra-all| library uses non-existent Guava classes
[
https://issues.apache.org/jira/browse/CASSANDRA-15245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892907#comment-16892907
]
Abhijit Sarkar commented on CASSANDRA-15245:
[~cnlwsu] Filed task https://issues.apache.org/jira/browse/CASSANDRA-15248
> cassandra-all| library uses non-existent Guava classes
> --
>
> Key: CASSANDRA-15245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15245
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Dependencies, Packaging
>Reporter: Abhijit Sarkar
>Priority: Normal
>
> The
> [cassandra-all|https://search.maven.org/artifact/org.apache.cassandra/cassandra-all/3.11.4/jar]
> library references classes that have been removed from Guava, for example
> {{com.google.common.base.CharMatcher.DIGIT}}. This causes runtime errors like
> {code}
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.cassandra.io.sstable.format.SSTableFormat$Type
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15245) cassandra-all| library uses non-existent Guava classes
[
https://issues.apache.org/jira/browse/CASSANDRA-15245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892859#comment-16892859
]
Chris Lohfink commented on CASSANDRA-15245:
---
I think updating guava on trunk makes sense, should be pretty straight forward
patch. Perhaps change title of Jira or open a new one as the
{{NoClassDefFoundError}} is just a dependency conflict from putting projects
requiring different versions of guava in classpath. {{cassandra-all}} isnt
really a client library and has no shading available for netty/guava/commons
etc so importing it into your project will likely have many conflicts.
> cassandra-all| library uses non-existent Guava classes
> --
>
> Key: CASSANDRA-15245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15245
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Dependencies, Packaging
>Reporter: Abhijit Sarkar
>Priority: Normal
>
> The
> [cassandra-all|https://search.maven.org/artifact/org.apache.cassandra/cassandra-all/3.11.4/jar]
> library references classes that have been removed from Guava, for example
> {{com.google.common.base.CharMatcher.DIGIT}}. This causes runtime errors like
> {code}
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.cassandra.io.sstable.format.SSTableFormat$Type
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15247) Avoid iterating the memtable contents when doing range queries with `only_purge_repaired_tombstones` enabled
Marcus Eriksson created CASSANDRA-15247:
---
Summary: Avoid iterating the memtable contents when doing range
queries with `only_purge_repaired_tombstones` enabled
Key: CASSANDRA-15247
URL: https://issues.apache.org/jira/browse/CASSANDRA-15247
Project: Cassandra
Issue Type: Improvement
Components: Local/Memtable
Reporter: Marcus Eriksson
Currently we
[iterate|https://github.com/apache/cassandra/blob/893908e2dc1fe011e38c847395cb39be4ca53d89/src/java/org/apache/cassandra/db/Memtable.java#L360]
over the subrange of the memtable contents we are querying for to find the
oldest unrepaired tombstone, we could probably just track the oldest tombstone
globally for the memtable without any big drawbacks (we might include a few
more tombstones when doing the read).
Also noted that we use {{EncodingStats#minLocalDeletionTime}} without checking
for the {{DELETION_TIME_EPOCH}} value in a few places, this can make us include
too many expired tombstones during reads.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15243) removenode can cause QUORUM write queries to fail
[ https://issues.apache.org/jira/browse/CASSANDRA-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892576#comment-16892576 ] Benedict commented on CASSANDRA-15243: -- See CASSANDRA-14723 > removenode can cause QUORUM write queries to fail > - > > Key: CASSANDRA-15243 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15243 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Tom van der Woerdt >Priority: Normal > > Looks like nobody found this yet so this may be a ticking time bomb for > some... :( > This happened to me earlier today. On a Cassandra 3.11.4 cluster with three > DCs, one DC had three servers fail due to unexpected external circumstances. > Replication was NTS configured with 2:2:2. > Cassandra dealt with the failures just fine - great! However, the nodes > failed in a way that would make bringing them back impossible, so I tried to > remove them using 'removenode'. > Suddenly, the application started experiencing a large number of QUORUM write > timeouts. My first reflex was to lower the streaming throughput and > compaction throughput, since timeouts indicated some overload was happening. > No luck, though. > I tried a bunch of other things to reroute queries away from the affected > datacenter, like changing the Severity field on the dynamic snitch. Still, no > luck. > After a while I noticed one strange thing: the WriteTimeoutException listed > that five replicas were required, instead of the four you would expect to see > in a 2:2:2 replication configuration. I shrugged it off as some weird > inconsistency that was probably because of the use of batches. > Skip ahead a bit, I decided to let the streams run again and just wait the > issue out, since nothing I did was working, and maybe just letting the > streams finish would resolve this overload. Magically, as soon as the streams > finished, the errors stopped. > > There are two issues here, both in AbstractWriteResponseHandler.java. > h3. Cassandra sometimes waits for too many replicas on writes > In > [totalBlockFor|https://github.com/apache/cassandra/blob/71cb0616b7710366a8cd364348c864d656dc5542/src/java/org/apache/cassandra/service/AbstractWriteResponseHandler.java#L124] > Cassandra will *always* include pending nodes in `blockfor`. In the case of > a quorum query on a 2:2:2 replication factor, with two replicas in one DC > down, this results in a blockfor of 5. If the pending replica is then also > down (as can happen in a case where removenode is used and not all > destination hosts are up), only 4 of the 5 hosts are available, and quorum > queries will never succeed. > h3. UnavailableException not thrown > While debugging this, I spent all my time focusing on this issue as if it was > a timeout. However, Cassandra was doing queries that could never succeed, > because insufficient hosts were available. Throwing an UnavailableException > would have been more helpful. The issue here is caused by > [assureSufficientLiveNodes|https://github.com/apache/cassandra/blob/71cb0616b7710366a8cd364348c864d656dc5542/src/java/org/apache/cassandra/service/AbstractWriteResponseHandler.java#L155] > which merely concats the lists of available nodes, and won't consider the > special-case behavior of a pending node that's down. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15245) cassandra-all| library uses non-existent Guava classes
[
https://issues.apache.org/jira/browse/CASSANDRA-15245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892539#comment-16892539
]
Abhijit Sarkar commented on CASSANDRA-15245:
[~zznate] Guava v23.3-jre in master does remove {{DIGIT}} but as far as
compatibility with latest code is concerned, is almost 2 years old. Latest is
28.0-jre.
I'm not sure about your comment about upgrading within a stable major release;
as long as no API is changed, there's nothing in [SEMVER|https://semver.org]
that says transitive dependencies would have to be frozen.
> cassandra-all| library uses non-existent Guava classes
> --
>
> Key: CASSANDRA-15245
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15245
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Dependencies, Packaging
>Reporter: Abhijit Sarkar
>Priority: Normal
>
> The
> [cassandra-all|https://search.maven.org/artifact/org.apache.cassandra/cassandra-all/3.11.4/jar]
> library references classes that have been removed from Guava, for example
> {{com.google.common.base.CharMatcher.DIGIT}}. This causes runtime errors like
> {code}
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.cassandra.io.sstable.format.SSTableFormat$Type
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
