[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=16948205#comment-16948205
]
Shalom commented on CASSANDRA-15336:
Hi All,
I'll just update for anyone that might be experiencing the same issue, that
after all the binaries were upgraded, the issue was gone as it came.
Moreover, we did some preliminary actions to mitigate this issue by running
major compactions on "hazardous" tables, thus dropping potentially affecting
tombstones.
There were still errors, but not as many as before.
Thanks [~benedict] for your assistance on this matter!
> 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
>
[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
]
Dinesh Joshi updated CASSANDRA-15295:
-
Status: Changes Suggested (was: Review In Progress)
Hi [~gzh1992n], thanks for the patch. When I looked at the issue closely, the
deadlock can be avoided if we don't start a {{Thread}} in a static initializer
block and calling a method on an partially initialized object. This is a
classic concurrency issue. Now, the way you have solved it is by moving the
error handling to a different class but I think it is still needs to go a bit
further. I have mocked up a very minimal change here:
https://github.com/apache/cassandra/compare/trunk...dineshjoshi:15295-trunk?expand=1
It is the minimal set of changes required to avoid the deadlock and it also
ensures that we operate on a fully initialized object. We can incorporate your
refactor as well but I think it is important to get the correctness issue
resolved first. It also requires a bit more guarding in {{CommitLog::start()}}
so it's not started twice.
I have also not completed evaluating whether this change will cause any other
issues as we are changing initialization behavior.
> 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] [Created] (CASSANDRA-15353) Documentation Preview - Cassandra 4.0
DeepakVohra created CASSANDRA-15353: --- Summary: Documentation Preview - Cassandra 4.0 Key: CASSANDRA-15353 URL: https://issues.apache.org/jira/browse/CASSANDRA-15353 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: DeepakVohra Please review, and add comments to, some of the documentation preview for Apache Cassandra 4.0. *TODOs * _Read Repair_ https://docs.google.com/document/d/1qkyXPAYjkb2fFAP5WAOJ9KGTrRQ79Cl4nhuydf0m03U/edit?usp=sharing _Full Repair Example_ https://docs.google.com/document/d/1Hxncmze_KNhpDQjrvePMfhGnspZEuwW8tqgqrMAMp4Q/edit?usp=sharing *New Features * _Support for Java 11_ https://docs.google.com/document/d/1v7ffccqk_5Son4iwfuwZae8YUam41quewKi_6Z_PQGw/edit?usp=sharing *Improvements * _Improved Streaming_ https://docs.google.com/document/d/1zd6AuHBgC82v598cuDtVIkxJVDV9c0A2rrMEVFHyB4Y/edit?usp=sharing _Improved Internode Messaging_ https://docs.google.com/document/d/1ub2DBHE7hNEKe4tuCOpdbCZ7qGqCdMAYvSTC-YamuMA/edit?usp=sharing -- 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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947856#comment-16947856
]
Michael Semb Wever edited comment on CASSANDRA-15169 at 10/9/19 5:08 PM:
-
It makes sense that {{OnDiskIndex}}'s behaviour matches {{TrieMemIndex}}'s
({{is_literal}}) behaviour.
But, if {{checkFully=false}} is also not actually required in
{{isUpperSatisfiedBy}}, then why does the `{{Term.compareTo(..,checkFully)}}`
method exist at all?
was (Author: michaelsembwever):
It makes sense that {{OnDiskIndex}}'s behaviour matches {{TrieMemIndex}}'s
({{is_literal}}) behaviour.
But, if {{checkFully=false}} is also not actually required in
{{isUpperSatisfiedBy}}, then why does the {{Term.compareTo(..,checkFully)}}
method exist at all?
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947856#comment-16947856
]
Michael Semb Wever edited comment on CASSANDRA-15169 at 10/9/19 5:08 PM:
-
It makes sense that {{OnDiskIndex}}'s behaviour matches {{TrieMemIndex}}'s
({{is_literal}}) behaviour.
But, if {{checkFully=false}} is also not actually required in
{{isUpperSatisfiedBy}}, then why does the {{Term.compareTo(..,checkFully)}}
method exist at all?
was (Author: michaelsembwever):
It makes sense that {{OnDiskIndex}}'s behaviour matches {{TrieMemIndex}}'s
({{is_literal}} behaviour.
But, if {{checkFully=false}} is also not actually required in
{{isUpperSatisfiedBy}}, then why does the {{Term.compareTo(..,checkFully)}}
method exist at all?
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947856#comment-16947856
]
Michael Semb Wever commented on CASSANDRA-15169:
It makes sense that {{OnDiskIndex}}'s behaviour matches {{TrieMemIndex}}'s
({{is_literal}} behaviour.
But, if {{checkFully=false}} is also not actually required in
{{isUpperSatisfiedBy}}, then why does the {{Term.compareTo(..,checkFully)}}
method exist at all?
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15350: Labels: protocolv5 (was: ) > Add CAS “uncertainty” and “contention" messages that are currently propagated > as a WriteTimeoutException. > - > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Priority: Normal > Labels: protocolv5 > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- 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] [Created] (CASSANDRA-15352) Replica failure propagation to coordinator and client
Alex Petrov created CASSANDRA-15352: --- Summary: Replica failure propagation to coordinator and client Key: CASSANDRA-15352 URL: https://issues.apache.org/jira/browse/CASSANDRA-15352 Project: Cassandra Issue Type: New Feature Components: Messaging/Internode Reporter: Alex Petrov We should add early reporting of replica-side errors, since currently we just time-out requests. On normal read-write path this is not that important, but this is a protocol change we will need to improve cheap quorums for transient replication. This might have potential positive impact for regular read-write path, since we’ll be aborting queries early instead of timing them out. Can be useful for failing / going away nodes (which is also one of the changes we’re planning to implement). We do have means for propagating error both in client protocol through and in internode through FAILURE_RSP, which is true and we do not have to extend the protocol to implement this change, but this is still a change in protocol behavior, since we’ll be sending a message where we would usually silently timeout. -- 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] [Created] (CASSANDRA-15351) Allow configuring timeouts on the per-request basis
Alex Petrov created CASSANDRA-15351: --- Summary: Allow configuring timeouts on the per-request basis Key: CASSANDRA-15351 URL: https://issues.apache.org/jira/browse/CASSANDRA-15351 Project: Cassandra Issue Type: New Feature Components: Messaging/Client Reporter: Alex Petrov Some queries need to be ran with a higher timeout value, which should be possible without allowing _all_ requests to be above this value. -- 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] [Created] (CASSANDRA-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
Alex Petrov created CASSANDRA-15350: --- Summary: Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException. Key: CASSANDRA-15350 URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 Project: Cassandra Issue Type: Improvement Components: Feature/Lightweight Transactions Reporter: Alex Petrov Right now, CAS uncertainty introduced in https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as WriteTimeout. One of this conditions it manifests is when there’s at least one acceptor that has accepted the value, which means that this value _may_ still get accepted during the later round, despite the proposer failure. Similar problem happens with CAS contention, which is also indistinguishable from the “regular” timeout, even though it is visible in metrics correctly. -- 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-15349) Add “Going away” message to the client protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15349: Labels: client-impacting (was: ) > Add “Going away” message to the client protocol > --- > > Key: CASSANDRA-15349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15349 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Priority: Normal > Labels: client-impacting > > Add “Going away” message that allows node to announce its shutdown and let > clients gracefully shutdown and not attempt further requests. -- 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] [Created] (CASSANDRA-15349) Add “Going away” message to the client protocol
Alex Petrov created CASSANDRA-15349: --- Summary: Add “Going away” message to the client protocol Key: CASSANDRA-15349 URL: https://issues.apache.org/jira/browse/CASSANDRA-15349 Project: Cassandra Issue Type: New Feature Components: Messaging/Client Reporter: Alex Petrov Add “Going away” message that allows node to announce its shutdown and let clients gracefully shutdown and not attempt further requests. -- 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-14872) Update to version of python driver and update cqlsh to use driver metadata for virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-14872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947742#comment-16947742
]
Chris Lohfink commented on CASSANDRA-14872:
---
We need a new build of the driver for
https://datastax-oss.atlassian.net/browse/PYTHON-1158 and also need at least
3.19 for https://datastax-oss.atlassian.net/browse/PYTHON-1118 or the virtual
table stuff wont work even with new builds.
> Update to version of python driver and update cqlsh to use driver metadata
> for virtual tables
> -
>
> Key: CASSANDRA-14872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14872
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL, Legacy/Tools
>Reporter: Andy Tolbert
>Priority: Normal
>
> When virtual tables were implemented ([CASSANDRA-7622]), cqlsh.py was updated
> to parse virtual keyspace metadata by making queries to the
> {{system_virtual_schema}} table and included a TODO:
> {code:python}
> # TODO remove after virtual tables are added to connection metadata
> {code}
> Since python driver 3.15.0 (released in August), the driver now parses
> virtual keyspace metadata. It would be good to update the bundled python
> driver and simplify cqlsh code to utilize its capability to parse virtual
> tables.
--
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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947599#comment-16947599
]
mazhenlin commented on CASSANDRA-15169:
---
Yes, I have seen the failure . The OnDiskIndexTest.testNotEqualsQueryForStrings
test case shows that using '=' for prefix matching seems to be a feature other
than a bug . However, the inconsistent behavior between MemIndex and
OnDiskIndex (when is_literal = true ) still need to be fixed. Comparison for
blob type is also incorrect .
We have two choices:
1 Do not use = for prefix match since 'like' is already supported.
2 Use '=' for prefix matching only when is_literal = true.
Personally I like 1, but 2 may be better considering that someone might have
already used this feature. Which do you prefer ? [~mck]
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15142) Fix errors on repairing empty keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15142:
---
Source Control Link:
https://github.com/apache/cassandra/commit/5bc7a375a3cac85e79543e7e30d620faeb891955
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as 5bc7a37
> Fix errors on repairing empty keyspace
> --
>
> Key: CASSANDRA-15142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Tool/nodetool
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Running repairs on empty keyspaces will produce a rather confusing error in
> trunk:
> {noformat}
> ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 -
> Repair 014607d0-7dff-11e9-9256-158db058ccc5 failed:
> java.lang.IllegalArgumentException: repair sessions cannot operate on
> multiple keyspaces
> ▸ at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
> ▸ at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
> ▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ▸ at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ▸ at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Let's ignore empty keyspaces and return a success return status instead.
--
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
[cassandra] branch trunk updated: Fix errors on repairing empty keyspace
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 5bc7a37 Fix errors on repairing empty keyspace
5bc7a37 is described below
commit 5bc7a375a3cac85e79543e7e30d620faeb891955
Author: Stefan Podkowinski
AuthorDate: Fri May 24 11:12:09 2019 +0200
Fix errors on repairing empty keyspace
patch by Stefan Podkowinski; reviewed by Mick Semb Wever for CASSANDRA-15142
---
src/java/org/apache/cassandra/repair/RepairRunnable.java | 8
1 file changed, 8 insertions(+)
diff --git a/src/java/org/apache/cassandra/repair/RepairRunnable.java
b/src/java/org/apache/cassandra/repair/RepairRunnable.java
index f1f12dd..4f2f897 100644
--- a/src/java/org/apache/cassandra/repair/RepairRunnable.java
+++ b/src/java/org/apache/cassandra/repair/RepairRunnable.java
@@ -165,6 +165,14 @@ public class RepairRunnable extends WrappedRunnable
implements ProgressEventNoti
return;
}
+if (Iterables.isEmpty(validColumnFamilies))
+{
+String message = String.format("Empty keyspace, skipping repair:
%s", keyspace);
+logger.info(message);
+fireProgressEvent(new ProgressEvent(ProgressEventType.COMPLETE, 0,
0, message));
+return;
+}
+
final long startTime = System.currentTimeMillis();
String message = String.format("Starting repair command #%d (%s),
repairing keyspace %s with %s", cmd, parentSession, keyspace,
options);
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15142) Fix errors on repairing empty keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15142:
---
Status: Ready to Commit (was: Review In Progress)
+1
> Fix errors on repairing empty keyspace
> --
>
> Key: CASSANDRA-15142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Tool/nodetool
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Running repairs on empty keyspaces will produce a rather confusing error in
> trunk:
> {noformat}
> ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 -
> Repair 014607d0-7dff-11e9-9256-158db058ccc5 failed:
> java.lang.IllegalArgumentException: repair sessions cannot operate on
> multiple keyspaces
> ▸ at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
> ▸ at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
> ▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ▸ at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ▸ at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Let's ignore empty keyspaces and return a success return status instead.
--
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-15142) Fix errors on repairing empty keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15142:
---
Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> Fix errors on repairing empty keyspace
> --
>
> Key: CASSANDRA-15142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Tool/nodetool
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Running repairs on empty keyspaces will produce a rather confusing error in
> trunk:
> {noformat}
> ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 -
> Repair 014607d0-7dff-11e9-9256-158db058ccc5 failed:
> java.lang.IllegalArgumentException: repair sessions cannot operate on
> multiple keyspaces
> ▸ at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
> ▸ at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
> ▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ▸ at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ▸ at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Let's ignore empty keyspaces and return a success return status instead.
--
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-15142) Fix errors on repairing empty keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15142:
---
Fix Version/s: 4.0-alpha
Reviewers: Michael Semb Wever
Since Version: 4.x
> Fix errors on repairing empty keyspace
> --
>
> Key: CASSANDRA-15142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Tool/nodetool
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Running repairs on empty keyspaces will produce a rather confusing error in
> trunk:
> {noformat}
> ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 -
> Repair 014607d0-7dff-11e9-9256-158db058ccc5 failed:
> java.lang.IllegalArgumentException: repair sessions cannot operate on
> multiple keyspaces
> ▸ at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
> ▸ at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
> ▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ▸ at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ▸ at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Let's ignore empty keyspaces and return a success return status instead.
--
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
