[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942624#comment-16942624
]
Benedict Elliott Smith commented on CASSANDRA-14825:
FWIW, I personally think it was a bit rude to produce a patch in replacement of
Chris' patch, when his was blocked only on community consensus on approach. I
would prefer to offer Chris the opportunity to modify his patch to implement
{{DESCRIBE}}, as this is only polite given the time and effort he put into it.
> Expose table schema for drivers
> ---
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Chris Lohfink
>Assignee: Robert Stupp
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
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] [Comment Edited] (CASSANDRA-14825) Expose table schema for drivers
[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942624#comment-16942624
]
Benedict Elliott Smith edited comment on CASSANDRA-14825 at 10/2/19 9:06 AM:
-
FWIW, I personally think it was a bit rude to produce a patch in replacement of
Chris' patch, when his was blocked only on the community reaching a consensus
on the desired approach. I would prefer to offer Chris the opportunity to
modify his patch to implement {{DESCRIBE}}, as this is only polite given the
time and effort he put into it, having filed the ticket over a year ago, and
having been participating in the discussion and responding to feedback that
entire time.
was (Author: benedict):
FWIW, I personally think it was a bit rude to produce a patch in replacement of
Chris' patch, when his was blocked only on community consensus on approach. I
would prefer to offer Chris the opportunity to modify his patch to implement
{{DESCRIBE}}, as this is only polite given the time and effort he put into it.
> Expose table schema for drivers
> ---
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Chris Lohfink
>Assignee: Robert Stupp
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
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-14825) Expose table schema for drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942659#comment-16942659 ] Robert Stupp commented on CASSANDRA-14825: -- It's not. Chris and I discussed the approach in person at ApacheCon. > Expose table schema for drivers > --- > > Key: CASSANDRA-14825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14825 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Chris Lohfink >Assignee: Robert Stupp >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the drivers recreate the CQL for the tables by putting together the > system table values. This is very difficult to keep up to date and buggy > enough that its only even supported in Java and Python drivers. Cassandra > already has some limited output available for snapshots that we could provide > in a virtual table or new query that the drivers can fetch. This can greatly > reduce the complexity of drivers while also reducing bugs like > CASSANDRA-14822 as the underlying schema and properties change. -- 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-14825) Expose table schema for drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942660#comment-16942660 ] Benedict Elliott Smith commented on CASSANDRA-14825: I am aware of that. I think you have a different understanding of what that achieved than I do. That knowledge is incorporated into my reading of the situation, and view of how we should proceed, as stated above. > Expose table schema for drivers > --- > > Key: CASSANDRA-14825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14825 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Chris Lohfink >Assignee: Robert Stupp >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the drivers recreate the CQL for the tables by putting together the > system table values. This is very difficult to keep up to date and buggy > enough that its only even supported in Java and Python drivers. Cassandra > already has some limited output available for snapshots that we could provide > in a virtual table or new query that the drivers can fetch. This can greatly > reduce the complexity of drivers while also reducing bugs like > CASSANDRA-14822 as the underlying schema and properties change. -- 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-13974) Bad prefix matching when figuring out data directory for an sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-13974: Reviewers: Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) > Bad prefix matching when figuring out data directory for an sstable > --- > > Key: CASSANDRA-13974 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13974 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > We do a "startsWith" check when getting data directory for an sstable, we > should match including File.separator -- 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-13974) Bad prefix matching when figuring out data directory for an sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-13974:
Status: Changes Suggested (was: Review In Progress)
Although most of the changes to 3.11+ aren't applicable to 3.0, the change to
{{Directories::getLocationForDisk}} is.
In {{FileUtils::isContained}}, have you considered using {{Path::startsWith}}
rather than string wrangling?
Comparing the strings is probably faster/more efficient, but using paths is a
bit clearer. e.g.:
{code}
Path folderPath = Paths.get(getCanonicalPath(folder));
Path filePath = Paths.get(getCanonicalPath(file));
return filePath.startsWith(folderPath);
{code}
The difference isn't huge though, so I'll leave it to you to decide.
> Bad prefix matching when figuring out data directory for an sstable
> ---
>
> Key: CASSANDRA-13974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13974
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We do a "startsWith" check when getting data directory for an sstable, we
> should match including File.separator
--
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-13974) Bad prefix matching when figuring out data directory for an sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942804#comment-16942804 ] Marcus Eriksson commented on CASSANDRA-13974: - thanks, pushed fixes to the branches above, tests running here: [3.0|https://circleci.com/workflow-run/b588038a-dd03-45bb-bec8-a4ab7801ca1e] [3.11|https://circleci.com/workflow-run/dd658826-41c0-4d2e-b6c3-1cda1a935444] [trunk|https://circleci.com/workflow-run/7f922026-26f7-447a-9adb-7f7cf91c1543] > Bad prefix matching when figuring out data directory for an sstable > --- > > Key: CASSANDRA-13974 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13974 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > We do a "startsWith" check when getting data directory for an sstable, we > should match including File.separator -- 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-13974) Bad prefix matching when figuring out data directory for an sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942822#comment-16942822 ] Marcus Eriksson commented on CASSANDRA-13974: - though, it seems using canonical paths doesn't work: CASSANDRA-5185 - I'll investigate > Bad prefix matching when figuring out data directory for an sstable > --- > > Key: CASSANDRA-13974 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13974 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > > We do a "startsWith" check when getting data directory for an sstable, we > should match including File.separator -- 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-15336) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException When Running Range Queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942902#comment-16942902
]
Shalom commented on CASSANDRA-15336:
[~benedict] I'm running v2.1.21 and wish to upgrade to v3.11.4.
I'm pretty sure I upgraded using the patch but I'll double check.
One question though, I see that the branch you used is 3.0 (
https://github.com/belliottsmith/cassandra/blob/{color:#FF}*15172-3.0*{color}/src/java/org/apache/cassandra/db/LegacyLayout.java)
Is this the correct branch or should it be a 3.11 branch?
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException When Running
> Range Queries
> ---
>
> Key: CASSANDRA-15336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15336
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> Hi All,
> This bug is similar to https://issues.apache.org/jira/browse/CASSANDRA-15172
> but relates specifically to range queries running over range tombstones.
>
>
> *+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(AbstractLocalAwareExecutorS
[jira] [Commented] (CASSANDRA-15336) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException When Running Range Queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942929#comment-16942929
]
Benedict Elliott Smith commented on CASSANDRA-15336:
The bug is fixed in 3.11.5, which has not been released yet. You could try
building from
[cassandra-3.11|https://github.com/apache/cassandra/tree/cassandra-3.11], which
is likely to be fairly close to the eventual 3.11.5 release.
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException When Running
> Range Queries
> ---
>
> Key: CASSANDRA-15336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15336
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> Hi All,
> This bug is similar to https://issues.apache.org/jira/browse/CASSANDRA-15172
> but relates specifically to range queries running over range tombstones.
>
>
> *+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
[jira] [Updated] (CASSANDRA-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15295: Reviewers: Dinesh Joshi, Jordan West (was: Jordan West) > 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-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&focusedCommentId=16943187#comment-16943187
]
Jordan West commented on CASSANDRA-15295:
-
Took a closer look at {{DatabaseDescriptorRefTest}}. Thank you for ensuring
that was updated. [~djoshi] is going to help w/ a second review so we can get
this committed.
Test runs can be found here:
https://circleci.com/gh/jrwest/cassandra/tree/bug-commitlog-deadlock
> 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
