[jira] [Commented] (CASSANDRA-14655) Upgrade C* to use latest guava (27.0)
[
https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936427#comment-16936427
]
mck commented on CASSANDRA-14655:
-
[~sumanth.pasupuleti],
- unit tests look good,
- i think the {{"cassandra-driver-core"}} lines in the build.xml can now be
updated and uncommented, see {{"UPDATE AND UNCOMMENT"}} sections,
- for LoaderOptions and CqlConfigHelper are there docs we want to update? (ie
to use `host:`port`?
- is the {{nativePort}} parameter needed anymore in
{{NativeSSTableLoaderClient}}'s constructor? the caller can put that into the
{{hosts}} parameter, (and then in the {{init(..)}} method (line 73) the cluster
builder called instead with {{addContactPointsWithPorts(hosts)}},
- i am still looking into the dtests…
> Upgrade C* to use latest guava (27.0)
> -
>
> Key: CASSANDRA-14655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14655
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
>
> C* currently uses guava 23.3. This JIRA is about changing C* to use latest
> guava (26.0). Originated from a discussion in the mailing list.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936398#comment-16936398 ] mck commented on CASSANDRA-14655: - bq. thanks for bringing this back into light, would be really nice to get this into 4.0 it's breaks a number of coding practices to cut releases with such a binary included, imo. > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936351#comment-16936351 ] Zephyr Guo commented on CASSANDRA-15295: I am sorry to reply you so late [~jrwest]. I had updated the PR. Please see: https://github.com/apache/cassandra/pull/347 > Running into deadlock when do CommitLog initialization > -- > > Key: CASSANDRA-15295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15295 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: jstack.log, pstack.log, screenshot-1.png, > screenshot-2.png, screenshot-3.png > > > Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a > long time. > I used jstack to saw what happened. The main thread stuck in > *AbstractCommitLogSegmentManager.awaitAvailableSegment* > !screenshot-1.png! > The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it > was not actually running. > !screenshot-2.png! > And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on > java class initialization. > !screenshot-3.png! > This is a deadlock obviously. CommitLog waits for a CommitLogSegment when > initializing. In this moment, the CommitLog class is not initialized and the > main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a > CommitLogSegment with exception and call *CommitLog.handleCommitError*(static > method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog > class is still initializing. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936222#comment-16936222 ] Andy Tolbert commented on CASSANDRA-14655: -- (y) thanks for bringing this back into light, would be really nice to get this into 4.0 > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936164#comment-16936164
]
Shalom commented on CASSANDRA-15172:
Hi [~benedict]
I tried the patch. It didn't do the trick, however, I was able to fully
reproduce the bug.
tl;dr
The bug does occur when running queries on range tombstones, but on top of
that, those queries have to specifically be range queries.
*+Steps to Reproduce:
+*
CREATE KEYSPACE ks1 WITH replication = \{'class': 'NetworkTopologyStrategy',
'DC1': '3'} AND durable_writes = true;
+*TABLE:*+
CREATE TABLE ks1.table1 (
col1 text,
col2 text,
col3 text,
col4 text,
col5 text,
col6 timestamp,
data text,
PRIMARY KEY ((col1, col2, col3), col4, col5, col6)
);
Inserted ~4 million rows and created range tombstones by deleting ~1 million
rows.
+*Create Data*+
_insert into ks1.table1 (col1, col2 , col3 , col4 , col5 , col6 , data ) VALUES
( '1', '11', '21', '1', 'a', 1231231230, 'data');_
_insert into ks1.table1 (col1, col2 , col3 , col4 , col5 , col6 , data ) VALUES
( '1', '11', '21', '2', 'a', 1231231230, 'data');_
_insert into ks1.table1 (col1, col2 , col3 , col4 , col5 , col6 , data ) VALUES
( '1', '11', '21', '3', 'a', 1231231230, 'data');_
_insert into ks1.table1 (col1, col2 , col3 , col4 , col5 , col6 , data ) VALUES
( '1', '11', '21', '4', 'a', 1231231230, 'data');_
_insert into ks1.table1 (col1, col2 , col3 , col4 , col5 , col6 , data ) VALUES
( '1', '11', '21', '5', 'a', 1231231230, 'data');_
+*Create Range Tombstones*+
delete from ks1.table1 where col1='1' and col2='11' and col3='21' and col4='1';
+*Query Live Rows (no tombstones)*+
_select * from ks1.table1 where col1='1' and col2='201' and col3='21' and
col4='1' and col5='a' and *col6>1231231230*;_
No issues found, everything is running properly.
+*Query Range Tombstones*+
_select * from ks1.table1 where col1='1' and col2='11' and col3='21' and
col4='1' and col5='a' and *col6=1231231230*;_
No issues found, everything is running properly.
+BUT when running range queries:+
_select * from ks1.table1 where col1='1' and col2='11' and col3='21' and
col4='1' and col5='a' and *col6>1231231220;*_
WARN [ReadStage-1] 2019-09-23 14:17:10,281
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.ArrayIndexOutOfBoundsException: 2
at
org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
at
org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
at
org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
at
org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
at
org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
at
org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
at
org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
at
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
at
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
at
org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
at
org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:114)
at java.lang.Thread.run(Thread.java:745)
This WARN is constantly generated until I stop the range queries script.
Hope this helps..
Thanks!
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Shalom
>Assignee: Benedict
>Priority: Normal
> Fix For: 3.0.19, 3.11.5
>
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of
[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.
[ https://issues.apache.org/jira/browse/CASSANDRA-15319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15319: - Reviewers: Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi) Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi) Status: Review In Progress (was: Patch Available) Hi [~jmeredithco], overall the code looks good. There were some minor changes that I have mocked up in my branch. The diff is [here|https://github.com/jonmeredith/cassandra/compare/CASSANDRA-15319-trunk...dineshjoshi:CASSANDRA-15319-trunk-review?expand=1]. > Add support for network topology and tracing to in-JVM dtests. > -- > > Key: CASSANDRA-15319 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15319 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > While working on CASSANDRA-15318, testing it properly with an in-JVM test > requires setting up the network topology and tracing requests to check which > nodes performed forwarding. > > In support of testing, make it possible to create in-JVM clusters with nodes > appearing in different datacenter/racks and add support for executing queries > with tracing enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.
[ https://issues.apache.org/jira/browse/CASSANDRA-15319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15319: - Reviewers: Dinesh Joshi > Add support for network topology and tracing to in-JVM dtests. > -- > > Key: CASSANDRA-15319 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15319 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > While working on CASSANDRA-15318, testing it properly with an in-JVM test > requires setting up the network topology and tracing requests to check which > nodes performed forwarding. > > In support of testing, make it possible to create in-JVM clusters with nodes > appearing in different datacenter/racks and add support for executing queries > with tracing enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936019#comment-16936019 ] Jordan West commented on CASSANDRA-15295: - [~gzh1992n] Thanks! If you would like me to go ahead and make the changes let me know. It would be great to get this into the future 4.0-alpha2 release as well as the 3.11 branch. > Running into deadlock when do CommitLog initialization > -- > > Key: CASSANDRA-15295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15295 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: jstack.log, pstack.log, screenshot-1.png, > screenshot-2.png, screenshot-3.png > > > Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a > long time. > I used jstack to saw what happened. The main thread stuck in > *AbstractCommitLogSegmentManager.awaitAvailableSegment* > !screenshot-1.png! > The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it > was not actually running. > !screenshot-2.png! > And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on > java class initialization. > !screenshot-3.png! > This is a deadlock obviously. CommitLog waits for a CommitLogSegment when > initializing. In this moment, the CommitLog class is not initialized and the > main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a > CommitLogSegment with exception and call *CommitLog.handleCommitError*(static > method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog > class is still initializing. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935930#comment-16935930 ] mck commented on CASSANDRA-14655: - ||branch||circleci||asf jenkins testall||asf jenkins dtests|| |[trunk|https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:guava_27_trunk]|[circleci|https://circleci.com/gh/sumanth-pasupuleti/workflows/cassandra/tree/guava_27_trunk]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/47//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/47/]|[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/680//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/680]| > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15334) Restore java-driver back to upstream code, using new implementation for dynamic port discovery
[
https://issues.apache.org/jira/browse/CASSANDRA-15334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-15334:
Resolution: Duplicate
Status: Resolved (was: Open)
[~sumanth.pasupuleti] has done the work, ready for review, for this ticket
already in CASSANDRA-14655.
Specifically, for this concern raised in this issue, [~andrew.tolbert] mentions
the problem
[here|https://issues.apache.org/jira/browse/CASSANDRA-14655?focusedCommentId=16678661=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16678661].
> Restore java-driver back to upstream code, using new implementation for
> dynamic port discovery
> --
>
> Key: CASSANDRA-15334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15334
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: mck
>Assignee: mck
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> In Cassandra multiple ports per node was implemented in
> [CASSANDRA-7544|https://issues.apache.org/jira/browse/CASSANDRA-7544] and in
> the java-driver implemented under
> [JAVA-1388|https://datastax-oss.atlassian.net/browse/JAVA-1388]. What's
> currently included in {{lib/cassandra-driver-core-3.4.0-shaded.jar}} is a
> custom build of code that is not found in any of the github repo's code
> (branches or tags). It was built off a [forked
> branch|https://github.com/datastax/java-driver/pull/931] that was never
> accepted into the driver. It was implemented instead by the java-driver team
> in [way|https://github.com/datastax/java-driver/pull/1065].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14655) Upgrade C* to use latest guava (27.0)
[ https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14655: Reviewers: mck, mck (was: mck) mck, mck Status: Review In Progress (was: Patch Available) > Upgrade C* to use latest guava (27.0) > - > > Key: CASSANDRA-14655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14655 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Low > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > C* currently uses guava 23.3. This JIRA is about changing C* to use latest > guava (26.0). Originated from a discussion in the mailing list. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
