[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