[jira] [Created] (CASSANDRA-19574) LIKE_MATCHES should be an equality
Berenguer Blasi created CASSANDRA-19574: --- Summary: LIKE_MATCHES should be an equality Key: CASSANDRA-19574 URL: https://issues.apache.org/jira/browse/CASSANDRA-19574 Project: Cassandra Issue Type: Bug Reporter: Berenguer Blasi Assignee: Berenguer Blasi The operator LIKE_MATCHES is [currently|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/Operator.java#L245] coded as a 'contains' instead of an 'equality' -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19574) LIKE_MATCHES should be an equality
[ https://issues.apache.org/jira/browse/CASSANDRA-19574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-19574: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: CQL/Semantics Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > LIKE_MATCHES should be an equality > -- > > Key: CASSANDRA-19574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19574 > Project: Cassandra > Issue Type: Bug > Components: CQL/Semantics >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > The operator LIKE_MATCHES is > [currently|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/Operator.java#L245] > coded as a 'contains' instead of an 'equality' -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19574) LIKE_MATCHES should be an equality
[ https://issues.apache.org/jira/browse/CASSANDRA-19574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-19574: Fix Version/s: 4.0.x 4.1.x 5.0.x 5.x > LIKE_MATCHES should be an equality > -- > > Key: CASSANDRA-19574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19574 > Project: Cassandra > Issue Type: Bug >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > The operator LIKE_MATCHES is > [currently|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/Operator.java#L245] > coded as a 'contains' instead of an 'equality' -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19573) incorrect queries showing up in queries virtual table
Jon Haddad created CASSANDRA-19573:
--
Summary: incorrect queries showing up in queries virtual table
Key: CASSANDRA-19573
URL: https://issues.apache.org/jira/browse/CASSANDRA-19573
Project: Cassandra
Issue Type: Bug
Components: Feature/Virtual Tables
Reporter: Jon Haddad
While running an easy-cass-stress workload I queried system_views.queries and
got this (edited for sanity):
{noformat}
thread_id | queued_micros | running_micros | task
-+---++
MutationStage-2 | 0 | 0 |
Mutation(keyspace='easy_cass_stress', key='3030312e302e3937363535',
modifications=[\n [easy_cass_stress.random_access] key=001.0.97655
partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647
columns=[[] | [value]]\n Row[info=[ts=1713501354789139] ]: row_id=291 |
[value=SXFNPWZDYFHTUSBWMUQCTTRAHQWXMGYOHASTGDFYLILWMOSFQWZGKUAIPUUGCLTADKFFXZRQGKIJJLXNOQKMAIOVSSVMVSFSFAVPABIIHGQSGRPACFWCKYMZMSNZZARSBFVDASTMCRHAVAYHKQDZWFCHRUPDWZJVTEVIWKPMKLAOZGBUDFJVOPSAHLAIWOGNXZHCBVK
ts=1713501354789139]\n])
ReadStage-4 | 0 | 6216 | SELECT * FROM
easy_cass_stress.random_access WHERE partition_id = '001.0.18474' AND row_id =
746 LIMIT 5000 ALLOW FILTERING
{noformat}
What's interesting is that I supply neither a LIMIT or ALLOW FILTERING when I
prepared the query. I assume the limit is coming from the driver, and while
it's technically correct from the standpoint of what it does, it's not what I
prepared so it's a little weird to see it there.
The ALLOW FILTERING, on the other hand, was definitely not prepared.
{noformat}
session.prepare("SELECT * from random_access WHERE partition_id = ? and row_id
= ?")
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19563) [Analytics] Support bulk write via S3
[ https://issues.apache.org/jira/browse/CASSANDRA-19563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838825#comment-17838825 ] Francisco Guerrero commented on CASSANDRA-19563: +1 Thanks for the patch > [Analytics] Support bulk write via S3 > - > > Key: CASSANDRA-19563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19563 > Project: Cassandra > Issue Type: New Feature > Components: Analytics Library >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > I would like to propose a new write option in Cassandra Analytics to bulk > write SSTables via S3, in addition to the previously-implemented "direct > upload to all sidecars" (now known as the "Direct" transport). > The new write option, now being implemented, is the "S3_COMPAT" transport, > which allows the job to upload the generated SSTables to an S3-compatible > storage system, and then inform the Cassandra Sidecar that those files are > available for download & commit. > Additionally, a plug-in system was added to allow communications between > custom transport hooks and the job, so the custom hook can provide updated > credentials and out-of-band status updates on S3-related issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19563) [Analytics] Support bulk write via S3
[ https://issues.apache.org/jira/browse/CASSANDRA-19563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRA-19563: --- Reviewers: Francisco Guerrero Status: Review In Progress (was: Patch Available) > [Analytics] Support bulk write via S3 > - > > Key: CASSANDRA-19563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19563 > Project: Cassandra > Issue Type: New Feature > Components: Analytics Library >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > I would like to propose a new write option in Cassandra Analytics to bulk > write SSTables via S3, in addition to the previously-implemented "direct > upload to all sidecars" (now known as the "Direct" transport). > The new write option, now being implemented, is the "S3_COMPAT" transport, > which allows the job to upload the generated SSTables to an S3-compatible > storage system, and then inform the Cassandra Sidecar that those files are > available for download & commit. > Additionally, a plug-in system was added to allow communications between > custom transport hooks and the job, so the custom hook can provide updated > credentials and out-of-band status updates on S3-related issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19572) Test failure: org.apache.cassandra.db.ImportTest flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-19572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838805#comment-17838805 ] Brandon Williams commented on CASSANDRA-19572: -- I haven't been able to repro these - I have a suspicion they may only occur in circle, and only when run in the suite since I didn't repro a specific test in 5k attempts [here|https://app.circleci.com/pipelines/github/driftx/cassandra/1586/workflows/2f172253-80a8-4c5f-b299-174067f0c4c6/jobs/84768/tests] or [here|https://app.circleci.com/pipelines/github/driftx/cassandra/1589/workflows/868187b9-32e5-49ce-98a4-db4b9c48d148/jobs/85046/tests]. > Test failure: org.apache.cassandra.db.ImportTest flakiness > -- > > Key: CASSANDRA-19572 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19572 > Project: Cassandra > Issue Type: Bug > Components: Tool/bulk load >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > As discovered on CASSANDRA-19401, the tests in this class are flaky, at least > the following: > * testImportCorruptWithoutValidationWithCopying > * testImportInvalidateCache > * testImportCorruptWithCopying > * testImportCacheEnabledWithoutSrcDir > * testImportInvalidateCache > [https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19566) JSON encoded timestamp value does not always match non-JSON encoded value
[
https://issues.apache.org/jira/browse/CASSANDRA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838793#comment-17838793
]
Stefan Miklosovic commented on CASSANDRA-19566:
---
Now we talk. I wonder how far this bug go. It is probably everywhere.
[https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-19566-5.0]
> JSON encoded timestamp value does not always match non-JSON encoded value
> -
>
> Key: CASSANDRA-19566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19566
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Bowen Song
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Description:
> "SELECT JSON ..." and "toJson(...)" on Cassandra 4.1.4 produces different
> date than "SELECT ..." for some timestamp type values.
>
> Steps to reproduce:
> {code:java}
> $ sudo docker pull cassandra:4.1.4
> $ sudo docker create --name cass cassandra:4.1.4
> $ sudo docker start cass
> $ # wait for the Cassandra instance becomes ready
> $ sudo docker exec -ti cass cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.1.0 | Cassandra 4.1.4 | CQL spec 3.4.6 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table tbl (id int, ts timestamp, primary key (id));
> cqlsh:test> insert into tbl (id, ts) values (1, -1376701920);
> cqlsh:test> select tounixtimestamp(ts), ts, tojson(ts) from tbl where id=1;
> system.tounixtimestamp(ts) | ts |
> system.tojson(ts)
> +-+
> -1376701920 | 1533-09-28 12:00:00.00+ | "1533-09-18
> 12:00:00.000Z"
> (1 rows)
> cqlsh:test> select json * from tbl where id=1;
> [json]
> -
> {"id": 1, "ts": "1533-09-18 12:00:00.000Z"}
> (1 rows)
> {code}
>
> Expected behaviour:
> The "select ts", "select tojson(ts)" and "select json *" should all produce
> the same date.
>
> Actual behaviour:
> The "select ts" produced the "1533-09-28" date but the "select tojson(ts)"
> and "select json *" produced the "1533-09-18" date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19566) JSON encoded timestamp value does not always match non-JSON encoded value
[
https://issues.apache.org/jira/browse/CASSANDRA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838793#comment-17838793
]
Stefan Miklosovic edited comment on CASSANDRA-19566 at 4/18/24 8:52 PM:
Now we talk. I wonder how far this bug go. It is probably everywhere.
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/4200/workflows/1a1e48c3-f02a-45fd-8576-d4ae470a8199]
was (Author: smiklosovic):
Now we talk. I wonder how far this bug go. It is probably everywhere.
[https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-19566-5.0]
> JSON encoded timestamp value does not always match non-JSON encoded value
> -
>
> Key: CASSANDRA-19566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19566
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Bowen Song
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Description:
> "SELECT JSON ..." and "toJson(...)" on Cassandra 4.1.4 produces different
> date than "SELECT ..." for some timestamp type values.
>
> Steps to reproduce:
> {code:java}
> $ sudo docker pull cassandra:4.1.4
> $ sudo docker create --name cass cassandra:4.1.4
> $ sudo docker start cass
> $ # wait for the Cassandra instance becomes ready
> $ sudo docker exec -ti cass cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.1.0 | Cassandra 4.1.4 | CQL spec 3.4.6 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table tbl (id int, ts timestamp, primary key (id));
> cqlsh:test> insert into tbl (id, ts) values (1, -1376701920);
> cqlsh:test> select tounixtimestamp(ts), ts, tojson(ts) from tbl where id=1;
> system.tounixtimestamp(ts) | ts |
> system.tojson(ts)
> +-+
> -1376701920 | 1533-09-28 12:00:00.00+ | "1533-09-18
> 12:00:00.000Z"
> (1 rows)
> cqlsh:test> select json * from tbl where id=1;
> [json]
> -
> {"id": 1, "ts": "1533-09-18 12:00:00.000Z"}
> (1 rows)
> {code}
>
> Expected behaviour:
> The "select ts", "select tojson(ts)" and "select json *" should all produce
> the same date.
>
> Actual behaviour:
> The "select ts" produced the "1533-09-28" date but the "select tojson(ts)"
> and "select json *" produced the "1533-09-18" date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838787#comment-17838787
]
Caleb Rackliffe commented on CASSANDRA-18736:
-
I left a few nits in the 4.0 PR, but also approved all 4 PRs.
+1
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:53)
>
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838781#comment-17838781
]
Brandon Williams commented on CASSANDRA-19557:
--
I agree, none of the failures look related to this patch (and if it did break
something, I'd expect to see a lot more.) Do you know if this is a problem in
5.0 after CASSANDRA-17056? This patch won't apply to that branch after that
ticket.
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Attachments: 19557-4.1.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when
[jira] [Updated] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19401:
--
Status: Ready to Commit (was: Changes Suggested)
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838772#comment-17838772
]
Brandon Williams commented on CASSANDRA-19401:
--
No, we have to fix those tests first.
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838771#comment-17838771
]
Stefan Miklosovic commented on CASSANDRA-19401:
---
OK so given CASSANDRA-19572 I think we can merge this. Moving to ready to
commit, correct me if not desirable.
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19401:
--
Status: Changes Suggested (was: Ready to Commit)
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] CASSANDRA-19563: Support bulk write via S3 [cassandra-analytics]
yifan-c commented on code in PR #53:
URL:
https://github.com/apache/cassandra-analytics/pull/53#discussion_r1571206932
##
scripts/build-sidecar.sh:
##
@@ -24,7 +24,7 @@ else
SCRIPT_DIR=$( dirname -- "$( readlink -f -- "$0"; )"; )
SIDECAR_REPO="${SIDECAR_REPO:-https://github.com/apache/cassandra-sidecar.git}";
SIDECAR_BRANCH="${SIDECAR_BRANCH:-trunk}"
- SIDECAR_COMMIT="${SIDECAR_COMMIT:-20795db4d708b9287e0a2281695923bfb6fa9138}"
+ SIDECAR_COMMIT="${SIDECAR_COMMIT:-686d9e8699bd0a56857e24523d883120023b9841}"
Review Comment:
Updated to `fd6f7ac5f9f19dbbeeb9e7f80ca1fcbf60d5a4c6`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19572) Test failure: org.apache.cassandra.db.ImportTest flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-19572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19572: -- Description: As discovered on CASSANDRA-19401, the tests in this class are flaky, at least the following: * testImportCorruptWithoutValidationWithCopying * testImportInvalidateCache * testImportCorruptWithCopying * testImportCacheEnabledWithoutSrcDir * testImportInvalidateCache [https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests] was: As discovered on CASSANDRA-19401, the tests in this class are flaky, at least the following: * testImportCorruptWithoutValidationWithCopying * testImportInvalidateCache * testImportCorruptWithCopying * testImportCacheEnabledWithoutSrcDir * testImportInvalidateCache https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests > Test failure: org.apache.cassandra.db.ImportTest flakiness > -- > > Key: CASSANDRA-19572 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19572 > Project: Cassandra > Issue Type: Bug > Components: Tool/bulk load >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > As discovered on CASSANDRA-19401, the tests in this class are flaky, at least > the following: > * testImportCorruptWithoutValidationWithCopying > * testImportInvalidateCache > * testImportCorruptWithCopying > * testImportCacheEnabledWithoutSrcDir > * testImportInvalidateCache > [https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19572) Test failure: org.apache.cassandra.db.ImportTest flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-19572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19572: - Description: As discovered on CASSANDRA-19401, the tests in this class are flaky, at least the following: * testImportCorruptWithoutValidationWithCopying * testImportInvalidateCache * testImportCorruptWithCopying * testImportCacheEnabledWithoutSrcDir * testImportInvalidateCache https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests was: As discovered on CASSANDRA-1940, the tests in this class are flaky, at least the following: * testImportCorruptWithoutValidationWithCopying * testImportInvalidateCache * testImportCorruptWithCopying * testImportCacheEnabledWithoutSrcDir * testImportInvalidateCache https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests > Test failure: org.apache.cassandra.db.ImportTest flakiness > -- > > Key: CASSANDRA-19572 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19572 > Project: Cassandra > Issue Type: Bug > Components: Tool/bulk load >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > As discovered on CASSANDRA-19401, the tests in this class are flaky, at least > the following: > * testImportCorruptWithoutValidationWithCopying > * testImportInvalidateCache > * testImportCorruptWithCopying > * testImportCacheEnabledWithoutSrcDir > * testImportInvalidateCache > https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19572) Test failure: org.apache.cassandra.db.ImportTest flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-19572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19572: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Tool/bulk load Discovered By: User Report Fix Version/s: 4.0.x 4.1.x 5.0.x 5.x Severity: Normal Status: Open (was: Triage Needed) > Test failure: org.apache.cassandra.db.ImportTest flakiness > -- > > Key: CASSANDRA-19572 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19572 > Project: Cassandra > Issue Type: Bug > Components: Tool/bulk load >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > As discovered on CASSANDRA-1940, the tests in this class are flaky, at least > the following: > * testImportCorruptWithoutValidationWithCopying > * testImportInvalidateCache > * testImportCorruptWithCopying > * testImportCacheEnabledWithoutSrcDir > * testImportInvalidateCache > https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838765#comment-17838765
]
Dmitry Konstantinov edited comment on CASSANDRA-19557 at 4/18/24 6:29 PM:
--
I see 3 errors in the test report and all of them do not look like related to
the changes..
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84434]
fails with: test_consistent_range_movement_true_with_rf1_should_fail
looks like a flaky test, the current change is not related to bootstrap logic..
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84433/parallel-runs/9]
fails with: Too long with no output (exceeded 15m0s): context deadline exceeded
https://issues.apache.org/jira/browse/CASSANDRA-18735 - the same failure was
considered here as an infra issue.
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84432/tests]
AssertionFailedError: Expected heap usage close to 74.927MiB, got 71.597MiB.
at
org.apache.cassandra.cql3.MemtableSizeTest.testSizeFlaky(MemtableSizeTest.java:149)
The same test is mentioned in the open ticket: CASSANDRA-17298
was (Author: dnk):
I see 3 errors in the test report and all of them do not look like related to
the changes..
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84434]
fails with: test_consistent_range_movement_true_with_rf1_should_fail
looks like a flaky test, the current change is not related to bootstrap logic..
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84433/parallel-runs/9]
fails with: Too long with no output (exceeded 15m0s): context deadline exceeded
https://issues.apache.org/jira/browse/CASSANDRA-18735 - the same failure was
considered here as an infra issue.
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84432/tests]
AssertionFailedError: Expected heap usage close to 74.927MiB, got 71.597MiB.
at
org.apache.cassandra.cql3.MemtableSizeTest.testSizeFlaky(MemtableSizeTest.java:149)
The same test ie mentioned in the open ticket: CASSANDRA-17298
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Attachments: 19557-4.1.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(
[jira] [Created] (CASSANDRA-19572) Test failure: org.apache.cassandra.db.ImportTest flakiness
Brandon Williams created CASSANDRA-19572: Summary: Test failure: org.apache.cassandra.db.ImportTest flakiness Key: CASSANDRA-19572 URL: https://issues.apache.org/jira/browse/CASSANDRA-19572 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams As discovered on CASSANDRA-1940, the tests in this class are flaky, at least the following: * testImportCorruptWithoutValidationWithCopying * testImportInvalidateCache * testImportCorruptWithCopying * testImportCacheEnabledWithoutSrcDir * testImportInvalidateCache https://app.circleci.com/pipelines/github/instaclustr/cassandra/4199/workflows/a70b41d8-f848-4114-9349-9a01ac082281/jobs/223621/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838765#comment-17838765
]
Dmitry Konstantinov commented on CASSANDRA-19557:
-
I see 3 errors in the test report and all of them do not look like related to
the changes..
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84434]
fails with: test_consistent_range_movement_true_with_rf1_should_fail
looks like a flaky test, the current change is not related to bootstrap logic..
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84433/parallel-runs/9]
fails with: Too long with no output (exceeded 15m0s): context deadline exceeded
https://issues.apache.org/jira/browse/CASSANDRA-18735 - the same failure was
considered here as an infra issue.
#
[https://app.circleci.com/pipelines/github/driftx/cassandra/1583/workflows/c6f9d038-b59a-4647-ba06-160d79da32b4/jobs/84432/tests]
AssertionFailedError: Expected heap usage close to 74.927MiB, got 71.597MiB.
at
org.apache.cassandra.cql3.MemtableSizeTest.testSizeFlaky(MemtableSizeTest.java:149)
The same test ie mentioned in the open ticket: CASSANDRA-17298
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Attachments: 19557-4.1.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
>
[jira] [Assigned] (CASSANDRA-19571) Avoid ConcurrentModificationException when removing metrics from CassandraMetricsRegistry
[
https://issues.apache.org/jira/browse/CASSANDRA-19571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned CASSANDRA-19571:
---
Assignee: Maxim Muzafarov
> Avoid ConcurrentModificationException when removing metrics from
> CassandraMetricsRegistry
> -
>
> Key: CASSANDRA-19571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19571
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Maxim Muzafarov
>Priority: Normal
>
> Multiple threads can modify the lists in {{CassandraMetricsRegistry}}
> {{ALIASES}} map values. We have seen this CME when removing metrics, but
> could possibly affect other paths using those lists
> Adding a small delay (10ms) when map:ing to {{getMetricName}} in
> {{CassandraMetricsRegistry.remove(name)}} makes this reproduce when running
> {{TransientRangeMovementTest.testLeave}}
> Caused by CASSANDRA-14572
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19571) Avoid ConcurrentModificationException when removing metrics from CassandraMetricsRegistry
[
https://issues.apache.org/jira/browse/CASSANDRA-19571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19571:
Fix Version/s: 5.x
> Avoid ConcurrentModificationException when removing metrics from
> CassandraMetricsRegistry
> -
>
> Key: CASSANDRA-19571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19571
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> Multiple threads can modify the lists in {{CassandraMetricsRegistry}}
> {{ALIASES}} map values. We have seen this CME when removing metrics, but
> could possibly affect other paths using those lists
> Adding a small delay (10ms) when map:ing to {{getMetricName}} in
> {{CassandraMetricsRegistry.remove(name)}} makes this reproduce when running
> {{TransientRangeMovementTest.testLeave}}
> Caused by CASSANDRA-14572
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] CASSANDRA-19563: Support bulk write via S3 [cassandra-analytics]
yifan-c commented on code in PR #53:
URL:
https://github.com/apache/cassandra-analytics/pull/53#discussion_r1571175753
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/token/ConsistencyLevel.java:
##
@@ -19,16 +19,42 @@
package org.apache.cassandra.spark.bulkwriter.token;
+import java.util.Collection;
+import java.util.Objects;
import java.util.Set;
-import org.slf4j.Logger;
-import org.slf4j.LoggerFactory;
+import com.google.common.base.Preconditions;
+
+import org.apache.cassandra.spark.common.model.CassandraInstance;
+import org.apache.cassandra.spark.data.ReplicationFactor;
public interface ConsistencyLevel
{
+/**
+ * Whether the consistency level only considers replicas in the local data
center.
+ *
+ * @return true if only considering the local replicas; otherwise, return
false
+ */
boolean isLocal();
-Logger LOGGER = LoggerFactory.getLogger(ConsistencyLevel.class);
+/**
+ * Check consistency level with the collection of the succeeded instances
+ *
+ * @param succeededInstances the succeeded instances in the replica set
+ * @param replicationFactor replication factor to check with
+ * @param localDC the local data center name if required for the check
+ * @return true means the consistency level is _definitively_ satisfied.
+ * Meanwhile, returning false means no conclusion can be drawn
+ */
+boolean canBeSatisfied(Collection
succeededInstances,
Review Comment:
Adding test in this patch.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19221) CMS: Nodes can restart with new ipaddress already defined in the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-19221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19221:
Reviewers: Sam Tunnicliffe, Sam Tunnicliffe
Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe)
Status: Review In Progress (was: Patch Available)
> CMS: Nodes can restart with new ipaddress already defined in the cluster
>
>
> Key: CASSANDRA-19221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19221
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html
>
>
> I am simulating running a cluster in Kubernetes and testing what happens when
> several pods go down and ip addresses are swapped between nodes. In 4.0 this
> is blocked and the node cannot be restarted.
> To simulate this I create a 3 node cluster on a local machine using 3
> loopback addresses
> {code}
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> {code}
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {code}
> bin/nodetool -p 7199 describecms
> {code}
> Cluster Metadata Service:
> {code}
> Members: /127.0.0.1:7000
> Is Member: true
> Service State: LOCAL
> {code}
> At this point I bring down the nodes 127.0.0.2 and 127.0.0.3 and swap the ip
> addresses for the rpc_address and listen_address
>
> The nodes come back as normal, but the nodeid has now been swapped against
> the ip address:
> Before:
> {code}
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 127.0.0.3 75.2 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1
> UN 127.0.0.2 86.77 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1
> UN 127.0.0.1 80.88 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1
> {code}
> After:
> {code}
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 127.0.0.3 149.62 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1
> UN 127.0.0.2 155.48 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1
> UN 127.0.0.1 75.74 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1
> {code}
> On previous tests of this I have created a table with a replication factor of
> 1, inserted some data before the swap. After the swap the data on nodes 2
> and 3 is now missing.
> One theory I have is that I am using different port numbers for the different
> nodes, and I am only swapping the ip addresses and not the port numbers, so
> the ip:port still looks unique
> i.e. 127.0.0.2:9043 becomes 127.0.0.2:9044
> and 127.0.0.3:9044 becomes 127.0.0.3:9043
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19221) CMS: Nodes can restart with new ipaddress already defined in the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-19221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838761#comment-17838761
]
Sam Tunnicliffe commented on CASSANDRA-19221:
-
+1. I left a couple of minor suggestions on the PR, feel free to accept or
ignore them.
> CMS: Nodes can restart with new ipaddress already defined in the cluster
>
>
> Key: CASSANDRA-19221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19221
> Project: Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
>Reporter: Paul Chandler
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html
>
>
> I am simulating running a cluster in Kubernetes and testing what happens when
> several pods go down and ip addresses are swapped between nodes. In 4.0 this
> is blocked and the node cannot be restarted.
> To simulate this I create a 3 node cluster on a local machine using 3
> loopback addresses
> {code}
> 127.0.0.1
> 127.0.0.2
> 127.0.0.3
> {code}
> The nodes are created correctly and the first node is assigned as a CMS node
> as shown:
> {code}
> bin/nodetool -p 7199 describecms
> {code}
> Cluster Metadata Service:
> {code}
> Members: /127.0.0.1:7000
> Is Member: true
> Service State: LOCAL
> {code}
> At this point I bring down the nodes 127.0.0.2 and 127.0.0.3 and swap the ip
> addresses for the rpc_address and listen_address
>
> The nodes come back as normal, but the nodeid has now been swapped against
> the ip address:
> Before:
> {code}
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 127.0.0.3 75.2 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1
> UN 127.0.0.2 86.77 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1
> UN 127.0.0.1 80.88 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1
> {code}
> After:
> {code}
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
> Rack
> UN 127.0.0.3 149.62 KiB 16 76.0%
> 6d194555-f6eb-41d0-c000-0003 rack1
> UN 127.0.0.2 155.48 KiB 16 59.3%
> 6d194555-f6eb-41d0-c000-0002 rack1
> UN 127.0.0.1 75.74 KiB 16 64.7%
> 6d194555-f6eb-41d0-c000-0001 rack1
> {code}
> On previous tests of this I have created a table with a replication factor of
> 1, inserted some data before the swap. After the swap the data on nodes 2
> and 3 is now missing.
> One theory I have is that I am using different port numbers for the different
> nodes, and I am only swapping the ip addresses and not the port numbers, so
> the ip:port still looks unique
> i.e. 127.0.0.2:9043 becomes 127.0.0.2:9044
> and 127.0.0.3:9044 becomes 127.0.0.3:9043
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838756#comment-17838756
]
Stefan Miklosovic commented on CASSANDRA-19401:
---
We need to postpone the merging of this patch until we resolve the flakiness of
ImportTest across all branches.
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19492) Allow configurable v4/v6 address matching behavior for SAI indexes on CQL inet columns
[
https://issues.apache.org/jira/browse/CASSANDRA-19492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838741#comment-17838741
]
Caleb Rackliffe commented on CASSANDRA-19492:
-
A preliminary test that illustrates the problem lives here:
https://github.com/maedhroz/cassandra/commit/4aaf91a23bd18304d156ae62446da3f890b4bab6
> Allow configurable v4/v6 address matching behavior for SAI indexes on CQL
> inet columns
> --
>
> Key: CASSANDRA-19492
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19492
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> The {{inet}} type in CQL allows ipv4 and ipv6 address formats to mix in the
> same column, and while there is a standard conversion between v4 and v6,
> equivalent addresses are not considered equal by Cassandra, when it comes to
> their usage in keys or in filtering queries. However, in SAI queries,
> equivalent v4 and v6 addresses ARE considered equal. Even if this behavior is
> useful, it might be a good idea to make the default behavior consistent with
> filtering, and allow the index configuration to control whether or not to
> consider them equal. (We have precedent for this w/ case-insensitive indexing
> of text columns, etc.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19344) Range movements involving transient replicas must safely enact changes to read and write replica sets
[
https://issues.apache.org/jira/browse/CASSANDRA-19344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838739#comment-17838739
]
Sam Tunnicliffe commented on CASSANDRA-19344:
-
Rebased and attached an updated {{ci_summary-1.html}}
> Range movements involving transient replicas must safely enact changes to
> read and write replica sets
> -
>
> Key: CASSANDRA-19344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19344
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> remove-n4-post-19344.txt, remove-n4-pre-19344.txt, result_details.tar.gz
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> (edit) This was originally opened due to a flaky test
> {{org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode-_jdk17}}
> The test can fail in two different ways:
> {code:java}
> junit.framework.AssertionFailedError: NOT IN CURRENT: 31 -- [(00,20),
> (31,50)] at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:203)
> at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode(TransientRangeMovementTest.java:183)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
> as in here -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2639/workflows/32b92ce7-5e9d-4efb-8362-d200d2414597/jobs/55139/tests#failed-test-0]
> and
> {code:java}
> junit.framework.AssertionFailedError: nodetool command [removenode,
> 6d194555-f6eb-41d0-c000-0003, --force] was not successful stdout:
> stderr: error: Node /127.0.0.4:7012 is alive and owns this ID. Use
> decommission command to remove it from the ring -- StackTrace --
> java.lang.UnsupportedOperationException: Node /127.0.0.4:7012 is alive and
> owns this ID. Use decommission command to remove it from the ring at
> org.apache.cassandra.tcm.sequences.SingleNodeSequences.removeNode(SingleNodeSequences.java:110)
> at
> org.apache.cassandra.service.StorageService.removeNode(StorageService.java:3682)
> at org.apache.cassandra.tools.NodeProbe.removeNode(NodeProbe.java:1020) at
> org.apache.cassandra.tools.nodetool.RemoveNode.execute(RemoveNode.java:51) at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:388)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:373) at
> org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:272) at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:1129)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$51(Instance.java:1038)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833) Notifications: Error:
> java.lang.UnsupportedOperationException: Node /127.0.0.4:7012 is alive and
> owns this ID. Use decommission command to remove it from the ring at
> org.apache.cassandra.tcm.sequences.SingleNodeSequences.removeNode(SingleNodeSequences.java:110)
> at
> org.apache.cassandra.service.StorageService.removeNode(StorageService.java:3682)
> at org.apache.cassandra.tools.NodeProbe.removeNode(NodeProbe.java:1020) at
> org.apache.cassandra.tools.nodetool.RemoveNode.execute(RemoveNode.java:51) at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:388)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:373) at
> org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:272) at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:1129)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$51(Instance.java:1038)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExec
[jira] [Updated] (CASSANDRA-19344) Range movements involving transient replicas must safely enact changes to read and write replica sets
[
https://issues.apache.org/jira/browse/CASSANDRA-19344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19344:
Attachment: ci_summary-1.html
> Range movements involving transient replicas must safely enact changes to
> read and write replica sets
> -
>
> Key: CASSANDRA-19344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19344
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html,
> remove-n4-post-19344.txt, remove-n4-pre-19344.txt, result_details.tar.gz
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> (edit) This was originally opened due to a flaky test
> {{org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode-_jdk17}}
> The test can fail in two different ways:
> {code:java}
> junit.framework.AssertionFailedError: NOT IN CURRENT: 31 -- [(00,20),
> (31,50)] at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:203)
> at
> org.apache.cassandra.distributed.test.TransientRangeMovementTest.testRemoveNode(TransientRangeMovementTest.java:183)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
> as in here -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2639/workflows/32b92ce7-5e9d-4efb-8362-d200d2414597/jobs/55139/tests#failed-test-0]
> and
> {code:java}
> junit.framework.AssertionFailedError: nodetool command [removenode,
> 6d194555-f6eb-41d0-c000-0003, --force] was not successful stdout:
> stderr: error: Node /127.0.0.4:7012 is alive and owns this ID. Use
> decommission command to remove it from the ring -- StackTrace --
> java.lang.UnsupportedOperationException: Node /127.0.0.4:7012 is alive and
> owns this ID. Use decommission command to remove it from the ring at
> org.apache.cassandra.tcm.sequences.SingleNodeSequences.removeNode(SingleNodeSequences.java:110)
> at
> org.apache.cassandra.service.StorageService.removeNode(StorageService.java:3682)
> at org.apache.cassandra.tools.NodeProbe.removeNode(NodeProbe.java:1020) at
> org.apache.cassandra.tools.nodetool.RemoveNode.execute(RemoveNode.java:51) at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:388)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:373) at
> org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:272) at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:1129)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$51(Instance.java:1038)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833) Notifications: Error:
> java.lang.UnsupportedOperationException: Node /127.0.0.4:7012 is alive and
> owns this ID. Use decommission command to remove it from the ring at
> org.apache.cassandra.tcm.sequences.SingleNodeSequences.removeNode(SingleNodeSequences.java:110)
> at
> org.apache.cassandra.service.StorageService.removeNode(StorageService.java:3682)
> at org.apache.cassandra.tools.NodeProbe.removeNode(NodeProbe.java:1020) at
> org.apache.cassandra.tools.nodetool.RemoveNode.execute(RemoveNode.java:51) at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:388)
> at org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:373) at
> org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:272) at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:1129)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$51(Instance.java:1038)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Wor
[jira] [Commented] (CASSANDRA-19571) Avoid ConcurrentModificationException when removing metrics from CassandraMetricsRegistry
[
https://issues.apache.org/jira/browse/CASSANDRA-19571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838722#comment-17838722
]
Marcus Eriksson commented on CASSANDRA-19571:
-
cc [~mmuzaf]
> Avoid ConcurrentModificationException when removing metrics from
> CassandraMetricsRegistry
> -
>
> Key: CASSANDRA-19571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19571
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Priority: Normal
>
> Multiple threads can modify the lists in {{CassandraMetricsRegistry}}
> {{ALIASES}} map values. We have seen this CME when removing metrics, but
> could possibly affect other paths using those lists
> Adding a small delay (10ms) when map:ing to {{getMetricName}} in
> {{CassandraMetricsRegistry.remove(name)}} makes this reproduce when running
> {{TransientRangeMovementTest.testLeave}}
> Caused by CASSANDRA-14572
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19571) Avoid ConcurrentModificationException when removing metrics from CassandraMetricsRegistry
Marcus Eriksson created CASSANDRA-19571:
---
Summary: Avoid ConcurrentModificationException when removing
metrics from CassandraMetricsRegistry
Key: CASSANDRA-19571
URL: https://issues.apache.org/jira/browse/CASSANDRA-19571
Project: Cassandra
Issue Type: Bug
Reporter: Marcus Eriksson
Multiple threads can modify the lists in {{CassandraMetricsRegistry}}
{{ALIASES}} map values. We have seen this CME when removing metrics, but could
possibly affect other paths using those lists
Adding a small delay (10ms) when map:ing to {{getMetricName}} in
{{CassandraMetricsRegistry.remove(name)}} makes this reproduce when running
{{TransientRangeMovementTest.testLeave}}
Caused by CASSANDRA-14572
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] CASSANDRA-19568: Jennkins pipeline's default Java version for Jabba has changed [cassandra-java-driver]
SiyaoIsHiding commented on code in PR #1929:
URL:
https://github.com/apache/cassandra-java-driver/pull/1929#discussion_r1570957184
##
Jenkinsfile:
##
@@ -593,7 +593,7 @@ pipeline {
stage('Build-Driver') {
steps {
// Jabba default should be a JDK8 for now
Review Comment:
You are so right. This is deleted!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] CASSANDRA-19568: Jennkins pipeline's default Java version for Jabba has changed [cassandra-java-driver]
joao-r-reis commented on code in PR #1929:
URL:
https://github.com/apache/cassandra-java-driver/pull/1929#discussion_r1570935845
##
Jenkinsfile:
##
@@ -593,7 +593,7 @@ pipeline {
stage('Build-Driver') {
steps {
// Jabba default should be a JDK8 for now
Review Comment:
should probably change this comment as it is no longer true
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19514) When jvm-dtest is shutting down an instance TCM retries block the shutdown causing the test to fail
[
https://issues.apache.org/jira/browse/CASSANDRA-19514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19514:
Source Control Link:
https://github.com/apache/cassandra/commit/cbf4dcb3345c7e2f42f6a897c66b6460b7acc2ca
(was:
https://github.com/apache/cassandra/commit/a5b8c06bb925905719261b1f449fffb049f54d1b)
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks!
> When jvm-dtest is shutting down an instance TCM retries block the shutdown
> causing the test to fail
> ---
>
> Key: CASSANDRA-19514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19514
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Test/dtest/java
>Reporter: David Capwell
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest#testRequestingPeerWatermarks
> {code}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException
>org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
>
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:540)
>
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
>
> org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest.testRequestingPeerWatermarks(RequestCurrentEpochTest.java:77)
>java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.TimeoutException
>
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
>
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:532)
> Suppressed: java.util.concurrent.TimeoutException
> {code}
> In debugger I found the blocked future and it was
> src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java waiting on
> src/java/org/apache/cassandra/tcm/RemoteProcessor.java retries
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated: Enable EpochAwareDebounce to cancel in flight rpc requests
This is an automated email from the ASF dual-hosted git repository.
samt 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 cbf4dcb334 Enable EpochAwareDebounce to cancel in flight rpc requests
cbf4dcb334 is described below
commit cbf4dcb3345c7e2f42f6a897c66b6460b7acc2ca
Author: Sam Tunnicliffe
AuthorDate: Fri Apr 12 14:04:06 2024 +0100
Enable EpochAwareDebounce to cancel in flight rpc requests
Patch by Sam Tunnicliffe; reviewed by Alex Petrov and Marcus Eriksson
for CASSANDRA-19514
---
.../apache/cassandra/tcm/EpochAwareDebounce.java | 65 --
.../org/apache/cassandra/tcm/PeerLogFetcher.java | 19 +--
.../org/apache/cassandra/tcm/RemoteProcessor.java | 38 --
.../cassandra/distributed/impl/Instance.java | 5 +-
.../distributed/test/log/CMSCatchupTest.java | 71 +++
.../test/log/FetchLogFromPeers2Test.java | 134
.../test/log/FetchLogFromPeersTest.java| 139 +
7 files changed, 306 insertions(+), 165 deletions(-)
diff --git a/src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java
b/src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java
index 5621845487..f65c03d830 100644
--- a/src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java
+++ b/src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java
@@ -18,13 +18,23 @@
package org.apache.cassandra.tcm;
-import java.util.concurrent.Callable;
+import java.util.List;
+import java.util.concurrent.CopyOnWriteArrayList;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
import java.util.concurrent.atomic.AtomicReference;
+import java.util.function.Function;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
import org.apache.cassandra.concurrent.ExecutorFactory;
import org.apache.cassandra.concurrent.ExecutorPlus;
+import org.apache.cassandra.tcm.log.LogState;
+import org.apache.cassandra.utils.ExecutorUtils;
import org.apache.cassandra.utils.concurrent.AsyncPromise;
import org.apache.cassandra.utils.concurrent.Future;
+import org.apache.cassandra.utils.concurrent.Promise;
/**
* When debouncing from a replica we know exactly which epoch we need, so to
avoid retries we
@@ -32,12 +42,13 @@ import org.apache.cassandra.utils.concurrent.Future;
* comes in, we create a new future. If a request for a newer epoch comes in,
we simply
* swap out the current future reference for a new one which is requesting the
newer epoch.
*/
-public class EpochAwareDebounce
+public class EpochAwareDebounce
{
-public static final EpochAwareDebounce instance = new
EpochAwareDebounce<>();
-
-private final AtomicReference> currentFuture =
new AtomicReference<>();
+private static final Logger logger =
LoggerFactory.getLogger(EpochAwareDebounce.class);
+public static final EpochAwareDebounce instance = new EpochAwareDebounce();
+private final AtomicReference currentFuture = new
AtomicReference<>();
private final ExecutorPlus executor;
+private final List> inflightRequests = new
CopyOnWriteArrayList<>();
private EpochAwareDebounce()
{
@@ -45,24 +56,50 @@ public class EpochAwareDebounce
this.executor =
ExecutorFactory.Global.executorFactory().pooled("debounce", 2);
}
-public Future getAsync(Callable get, Epoch epoch)
+/**
+ * Deduplicate requests to catch up log state based on the desired epoch.
Callers supply a target epoch and
+ * a function obtain the ClusterMetadata that corresponds with it. It is
expected that this function will make rpc
+ * calls to peers, retrieving a LogState which can be applied locally to
produce the necessary {@code
+ * ClusterMetadata}. The function takes a {@code Promise} as
input, with the expectation that this
+ * specific instance will be used to provide blocking behaviour when
making the rpc calls that fetch the {@code
+ * LogState}. These promises are memoized in order to cancel them when
{@link #shutdownAndWait(long, TimeUnit)} is
+ * called. This causes the fetch function to stop waiting on any in flight
{@code LogState} requests and prevents
+ * shutdown from being blocked.
+ *
+ * @param fetchFunction executes the request for LogState. It's expected
that this popluates fetchResult with the
+ * successful result.
+ * @param epoch the desired epoch
+ * @return
+ */
+public Future getAsync(Function,
ClusterMetadata> fetchFunction,
+Epoch epoch)
{
while (true)
{
-EpochAwareAsyncPromise running = currentFuture.get();
+EpochAwareAsyncPromise running = currentFuture.get();
if (running != null && !running.isDone() &&
running.epoch.isEqualOrAfter(epoch))
return ru
[jira] [Assigned] (CASSANDRA-19158) Reuse native transport-driven futures in Debounce
[ https://issues.apache.org/jira/browse/CASSANDRA-19158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov reassigned CASSANDRA-19158: --- Assignee: Alex Petrov > Reuse native transport-driven futures in Debounce > - > > Key: CASSANDRA-19158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19158 > Project: Cassandra > Issue Type: Improvement >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Currently, we create a future in Debounce, then create one more future in > RemoteProcessor#sendWithCallback. This is further exacerbated by chaining > calls, when we first attempt to catch up from peer, and then from CMS. > First of all, we should always only use a native transport timeout driven > futures returned from sendWithCallback, since they implement reasonable > retries under the hood, and are easy to bulk-configure (ie you can simply > change timeout in yaml and have all futures change their behaviour). > Second, we should _chain_ futures and use map or andThen for fallback > operations such as trying to catch up from CMS after an unsuccesful attemp to > catch up from peer. > This should significantly simplify the code and number of blocked/waiting > threads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19514) When jvm-dtest is shutting down an instance TCM retries block the shutdown causing the test to fail
[
https://issues.apache.org/jira/browse/CASSANDRA-19514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19514:
Reviewers: Alex Petrov, Blake Eggleston, Marcus Eriksson, Sam Tunnicliffe
(was: Alex Petrov, Blake Eggleston, Marcus Eriksson)
Status: Review In Progress (was: Patch Available)
> When jvm-dtest is shutting down an instance TCM retries block the shutdown
> causing the test to fail
> ---
>
> Key: CASSANDRA-19514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19514
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Test/dtest/java
>Reporter: David Capwell
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest#testRequestingPeerWatermarks
> {code}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException
>org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
>
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:540)
>
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
>
> org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest.testRequestingPeerWatermarks(RequestCurrentEpochTest.java:77)
>java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.TimeoutException
>
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
>
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:532)
> Suppressed: java.util.concurrent.TimeoutException
> {code}
> In debugger I found the blocked future and it was
> src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java waiting on
> src/java/org/apache/cassandra/tcm/RemoteProcessor.java retries
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19514) When jvm-dtest is shutting down an instance TCM retries block the shutdown causing the test to fail
[
https://issues.apache.org/jira/browse/CASSANDRA-19514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19514:
Status: Ready to Commit (was: Review In Progress)
> When jvm-dtest is shutting down an instance TCM retries block the shutdown
> causing the test to fail
> ---
>
> Key: CASSANDRA-19514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19514
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Test/dtest/java
>Reporter: David Capwell
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest#testRequestingPeerWatermarks
> {code}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException
>org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
>
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:540)
>
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
>
> org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest.testRequestingPeerWatermarks(RequestCurrentEpochTest.java:77)
>java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.TimeoutException
>
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
>
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:532)
> Suppressed: java.util.concurrent.TimeoutException
> {code}
> In debugger I found the blocked future and it was
> src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java waiting on
> src/java/org/apache/cassandra/tcm/RemoteProcessor.java retries
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19566) JSON encoded timestamp value does not always match non-JSON encoded value
[
https://issues.apache.org/jira/browse/CASSANDRA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838665#comment-17838665
]
Stefan Miklosovic commented on CASSANDRA-19566:
---
Ah, so there are some problems in the end. I haven't looked in that yet.
[CASSANDRA-19566-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19566-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311 5m 49s
✓ j17_cqlsh_dtests_py311_vnode 6m 39s
✓ j17_cqlsh_dtests_py38_vnode 6m 34s
✓ j17_cqlshlib_cython_tests7m 13s
✓ j17_cqlshlib_tests 8m 21s
✓ j17_dtests 32m 51s
✓ j17_dtests_latest 33m 11s
✓ j17_dtests_vnode33m 29s
✓ j17_jvm_dtests_latest_vnode 16m 56s
j17_jvm_dtests 22m 16s
j17_unit_tests 3m 26s
j17_cqlsh_dtests_py38 pending
j17_utests_latest pending
✕ j17_utests_oa 15m 49s
org.apache.cassandra.db.marshal.AbstractTypeTest serdeFromCQLLiteral
org.apache.cassandra.db.marshal.AbstractTypeTest serdeFromString
org.apache.cassandra.utils.bytecomparable.ByteSourceComparisonTest
testDateType
org.apache.cassandra.utils.bytecomparable.ByteSourceComparisonTest
testTimestampType
org.apache.cassandra.utils.bytecomparable.ByteSourceConversionTest
testDateType
org.apache.cassandra.utils.bytecomparable.ByteSourceConversionTest
testTimestampType
org.apache.cassandra.cql3.functions.CastFctsTest
testTimeCastsInSelectionClause
org.apache.cassandra.net.ConnectionTest testTimeout
org.apache.cassandra.db.marshal.TimestampTypeTest stringProperty
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4191/workflows/ed068a94-b146-4b8c-87fb-851be5735922]
> JSON encoded timestamp value does not always match non-JSON encoded value
> -
>
> Key: CASSANDRA-19566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19566
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Bowen Song
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Description:
> "SELECT JSON ..." and "toJson(...)" on Cassandra 4.1.4 produces different
> date than "SELECT ..." for some timestamp type values.
>
> Steps to reproduce:
> {code:java}
> $ sudo docker pull cassandra:4.1.4
> $ sudo docker create --name cass cassandra:4.1.4
> $ sudo docker start cass
> $ # wait for the Cassandra instance becomes ready
> $ sudo docker exec -ti cass cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.1.0 | Cassandra 4.1.4 | CQL spec 3.4.6 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table tbl (id int, ts timestamp, primary key (id));
> cqlsh:test> insert into tbl (id, ts) values (1, -1376701920);
> cqlsh:test> select tounixtimestamp(ts), ts, tojson(ts) from tbl where id=1;
> system.tounixtimestamp(ts) | ts |
> system.tojson(ts)
> +-+
> -1376701920 | 1533-09-28 12:00:00.00+ | "1533-09-18
> 12:00:00.000Z"
> (1 rows)
> cqlsh:test> select json * from tbl where id=1;
> [json]
> -
> {"id": 1, "ts": "1533-09-18 12:00:00.000Z"}
> (1 rows)
> {code}
>
> Expected behaviour:
> The "select ts", "select tojson(ts)" and "select json *" should all produce
> the same date.
>
> Actual behaviour:
> The "select ts" produced the "1533-09-28" date but the "select tojson(ts)"
> and "select json *" produced the "1533-09-18" date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19566) JSON encoded timestamp value does not always match non-JSON encoded value
[
https://issues.apache.org/jira/browse/CASSANDRA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838665#comment-17838665
]
Stefan Miklosovic edited comment on CASSANDRA-19566 at 4/18/24 1:58 PM:
Ah, so there are some problems in the end. I haven't looked into that yet.
[CASSANDRA-19566-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19566-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311 5m 49s
✓ j17_cqlsh_dtests_py311_vnode 6m 39s
✓ j17_cqlsh_dtests_py38_vnode 6m 34s
✓ j17_cqlshlib_cython_tests7m 13s
✓ j17_cqlshlib_tests 8m 21s
✓ j17_dtests 32m 51s
✓ j17_dtests_latest 33m 11s
✓ j17_dtests_vnode33m 29s
✓ j17_jvm_dtests_latest_vnode 16m 56s
j17_jvm_dtests 22m 16s
j17_unit_tests 3m 26s
j17_cqlsh_dtests_py38 pending
j17_utests_latest pending
✕ j17_utests_oa 15m 49s
org.apache.cassandra.db.marshal.AbstractTypeTest serdeFromCQLLiteral
org.apache.cassandra.db.marshal.AbstractTypeTest serdeFromString
org.apache.cassandra.utils.bytecomparable.ByteSourceComparisonTest
testDateType
org.apache.cassandra.utils.bytecomparable.ByteSourceComparisonTest
testTimestampType
org.apache.cassandra.utils.bytecomparable.ByteSourceConversionTest
testDateType
org.apache.cassandra.utils.bytecomparable.ByteSourceConversionTest
testTimestampType
org.apache.cassandra.cql3.functions.CastFctsTest
testTimeCastsInSelectionClause
org.apache.cassandra.net.ConnectionTest testTimeout
org.apache.cassandra.db.marshal.TimestampTypeTest stringProperty
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4191/workflows/ed068a94-b146-4b8c-87fb-851be5735922]
was (Author: smiklosovic):
Ah, so there are some problems in the end. I haven't looked in that yet.
[CASSANDRA-19566-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19566-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 36s
✓ j17_cqlsh_dtests_py311 5m 49s
✓ j17_cqlsh_dtests_py311_vnode 6m 39s
✓ j17_cqlsh_dtests_py38_vnode 6m 34s
✓ j17_cqlshlib_cython_tests7m 13s
✓ j17_cqlshlib_tests 8m 21s
✓ j17_dtests 32m 51s
✓ j17_dtests_latest 33m 11s
✓ j17_dtests_vnode33m 29s
✓ j17_jvm_dtests_latest_vnode 16m 56s
j17_jvm_dtests 22m 16s
j17_unit_tests 3m 26s
j17_cqlsh_dtests_py38 pending
j17_utests_latest pending
✕ j17_utests_oa 15m 49s
org.apache.cassandra.db.marshal.AbstractTypeTest serdeFromCQLLiteral
org.apache.cassandra.db.marshal.AbstractTypeTest serdeFromString
org.apache.cassandra.utils.bytecomparable.ByteSourceComparisonTest
testDateType
org.apache.cassandra.utils.bytecomparable.ByteSourceComparisonTest
testTimestampType
org.apache.cassandra.utils.bytecomparable.ByteSourceConversionTest
testDateType
org.apache.cassandra.utils.bytecomparable.ByteSourceConversionTest
testTimestampType
org.apache.cassandra.cql3.functions.CastFctsTest
testTimeCastsInSelectionClause
org.apache.cassandra.net.ConnectionTest testTimeout
org.apache.cassandra.db.marshal.TimestampTypeTest stringProperty
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4191/workflows/ed068a94-b146-4b8c-87fb-851be5735922]
> JSON encoded timestamp value does not always match non-JSON encoded value
> -
>
> Key: CASSANDRA-19566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19566
> Project: Cassandra
> Issue Type: Bug
> Component
[jira] [Commented] (CASSANDRA-19514) When jvm-dtest is shutting down an instance TCM retries block the shutdown causing the test to fail
[
https://issues.apache.org/jira/browse/CASSANDRA-19514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838664#comment-17838664
]
Alex Petrov commented on CASSANDRA-19514:
-
+1 on the latest trunk patch! Thank you!
> When jvm-dtest is shutting down an instance TCM retries block the shutdown
> causing the test to fail
> ---
>
> Key: CASSANDRA-19514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19514
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Test/dtest/java
>Reporter: David Capwell
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest#testRequestingPeerWatermarks
> {code}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException
>org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
>
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:540)
>
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
>
> org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest.testRequestingPeerWatermarks(RequestCurrentEpochTest.java:77)
>java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.util.concurrent.TimeoutException
>
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
>
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:532)
> Suppressed: java.util.concurrent.TimeoutException
> {code}
> In debugger I found the blocked future and it was
> src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java waiting on
> src/java/org/apache/cassandra/tcm/RemoteProcessor.java retries
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19538:
Fix Version/s: 5.1
(was: 5.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/80971709b983566a3f2dbfc189dfa1c5367d69bb
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Merged to trunk (with ninja followup because *someone* forgot to add
{{CHANGES.txt}})
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated: Ninja: update CHANGES.txt
This is an automated email from the ASF dual-hosted git repository. samt 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 a84f7daf05 Ninja: update CHANGES.txt a84f7daf05 is described below commit a84f7daf05315797c6a7ede8aedb72a433bf626d Author: Sam Tunnicliffe AuthorDate: Thu Apr 18 13:27:51 2024 +0100 Ninja: update CHANGES.txt --- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGES.txt b/CHANGES.txt index 4f07c455df..04d75e5e0a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 5.1 + * Correctly set last modified epoch when combining multistep operations into a single step (CASSANDRA-19538) * Add new TriggersPolicy configuration to allow operators to disable triggers (CASSANDRA-19532) * Use Transformation.Kind.id in local and distributed log tables (CASSANDRA-19516) * Remove period field from ClusterMetadata and metadata log tables (CASSANDRA-19482) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated: Properly set lastModifiedEpoch on multistep operations
This is an automated email from the ASF dual-hosted git repository.
samt 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 80971709b9 Properly set lastModifiedEpoch on multistep operations
80971709b9 is described below
commit 80971709b983566a3f2dbfc189dfa1c5367d69bb
Author: Marcus Eriksson
AuthorDate: Mon Apr 15 11:06:57 2024 +0200
Properly set lastModifiedEpoch on multistep operations
Patch by Marcus Eriksson; reviewed by Sam Tunnicliffe for
CASSANDRA-19538
---
src/java/org/apache/cassandra/tcm/MultiStepOperation.java | 4 ++--
.../org/apache/cassandra/tcm/ownership/DataPlacement.java | 6 ++
.../org/apache/cassandra/tcm/ownership/DataPlacements.java | 10 +-
.../apache/cassandra/tcm/ownership/PlacementForRange.java | 14 ++
.../apache/cassandra/tcm/ownership/VersionedEndpoints.java | 6 ++
5 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/src/java/org/apache/cassandra/tcm/MultiStepOperation.java
b/src/java/org/apache/cassandra/tcm/MultiStepOperation.java
index 9e8f21c6ec..5fffbd2c84 100644
--- a/src/java/org/apache/cassandra/tcm/MultiStepOperation.java
+++ b/src/java/org/apache/cassandra/tcm/MultiStepOperation.java
@@ -155,7 +155,7 @@ public abstract class MultiStepOperation
public static Transformation.Result
applyMultipleTransformations(ClusterMetadata metadata, Transformation.Kind
next, List transformations)
{
ImmutableSet.Builder modifiedKeys =
ImmutableSet.builder();
-Epoch lastModifiedEpoch = metadata.epoch;
+Epoch lastModifiedEpoch = metadata.epoch.nextEpoch();
boolean foundStart = false;
for (Transformation nextTransformation : transformations)
{
@@ -169,7 +169,7 @@ public abstract class MultiStepOperation
modifiedKeys.addAll(result.success().affectedMetadata);
}
}
-return new
Transformation.Success(metadata.forceEpoch(lastModifiedEpoch.nextEpoch()),
LockedRanges.AffectedRanges.EMPTY, modifiedKeys.build());
+return new Transformation.Success(metadata,
LockedRanges.AffectedRanges.EMPTY, modifiedKeys.build());
}
/**
diff --git a/src/java/org/apache/cassandra/tcm/ownership/DataPlacement.java
b/src/java/org/apache/cassandra/tcm/ownership/DataPlacement.java
index 521084ffe5..c37137b357 100644
--- a/src/java/org/apache/cassandra/tcm/ownership/DataPlacement.java
+++ b/src/java/org/apache/cassandra/tcm/ownership/DataPlacement.java
@@ -155,6 +155,12 @@ public class DataPlacement
}
}
+public DataPlacement withCappedLastModified(Epoch lastModified)
+{
+return new DataPlacement(reads.withCappedLastModified(lastModified),
+ writes.withCappedLastModified(lastModified));
+}
+
@Override
public String toString()
{
diff --git a/src/java/org/apache/cassandra/tcm/ownership/DataPlacements.java
b/src/java/org/apache/cassandra/tcm/ownership/DataPlacements.java
index 73c83fb5fd..5d598a8191 100644
--- a/src/java/org/apache/cassandra/tcm/ownership/DataPlacements.java
+++ b/src/java/org/apache/cassandra/tcm/ownership/DataPlacements.java
@@ -25,6 +25,7 @@ import java.util.Map;
import java.util.Objects;
import java.util.function.BiConsumer;
+import com.google.common.collect.ImmutableMap;
import com.google.common.collect.Maps;
import com.google.common.collect.Sets;
@@ -122,7 +123,7 @@ public class DataPlacements extends
ReplicationMap implements Met
@Override
public DataPlacements withLastModified(Epoch epoch)
{
-return new DataPlacements(epoch, asMap());
+return new DataPlacements(epoch, capLastModified(epoch, map));
}
@Override
@@ -255,6 +256,13 @@ public class DataPlacements extends
ReplicationMap implements Met
}
}
+public static ImmutableMap
capLastModified(Epoch lastModified, Map
placements)
+{
+ImmutableMap.Builder builder =
ImmutableMap.builder();
+placements.forEach((params, placement) -> builder.put(params,
placement.withCappedLastModified(lastModified)));
+return builder.build();
+}
+
public void dumpDiff(DataPlacements other)
{
if (!map.equals(other.map))
diff --git a/src/java/org/apache/cassandra/tcm/ownership/PlacementForRange.java
b/src/java/org/apache/cassandra/tcm/ownership/PlacementForRange.java
index c72bd2a0d5..baa7719d13 100644
--- a/src/java/org/apache/cassandra/tcm/ownership/PlacementForRange.java
+++ b/src/java/org/apache/cassandra/tcm/ownership/PlacementForRange.java
@@ -152,6 +152,20 @@ public class PlacementForRange
return builder.build();
}
+public PlacementForRange withCappedLastModified(Epoch lastModified)
+{
+SortedMap, VersionedEndpoints.ForRange> copy = new
TreeMap<>();
+for (Map.Entry, VersionedEndpoints.ForRange> en
[jira] [Updated] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19401:
-
Status: Changes Suggested (was: Review In Progress)
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838627#comment-17838627
]
Brandon Williams commented on CASSANDRA-19401:
--
The flakiness in the ImportTests seems to be caused by this patch, as without
it 5.0 can pass 5k times
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1586/workflows/2f172253-80a8-4c5f-b299-174067f0c4c6/jobs/84768/tests]
and
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1589/workflows/868187b9-32e5-49ce-98a4-db4b9c48d148/jobs/85046/tests].
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19538:
Attachment: ci_summary-1.html
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838624#comment-17838624
]
Sam Tunnicliffe commented on CASSANDRA-19538:
-
+1 to the followup commit too
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19401:
-
Status: Review In Progress (was: Needs Committer)
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19570) Allow setting LIBFFI_TMPDIR
[ https://issues.apache.org/jira/browse/CASSANDRA-19570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19570: - Change Category: Operability Complexity: Low Hanging Fruit Component/s: Build Fix Version/s: 5.0.x 5.x Status: Open (was: Triage Needed) > Allow setting LIBFFI_TMPDIR > --- > > Key: CASSANDRA-19570 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19570 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Thomas De Keulenaer >Priority: Normal > Fix For: 5.0.x, 5.x > > > Since JNA >= 5.10.0 you can specify LIBFFI_TMPDIR because the vendored libffi > was upgraded. > I think it is best to set this to the same value as jna.tmpdir. Perhaps in > cassandra-env.sh? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19401:
--
Status: Needs Committer (was: Patch Available)
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838623#comment-17838623
]
Stefan Miklosovic commented on CASSANDRA-19401:
---
[CASSANDRA-19401-4.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19401-4.0]
{noformat}
java8_pre-commit_tests
✓ j8_build 4m 54s
✓ j8_cqlsh-dtests-py2-no-vnodes6m 22s
✓ j8_cqlsh-dtests-py2-with-vnodes 8m 30s
✓ j8_cqlsh_dtests_py3 6m 22s
✓ j8_cqlsh_dtests_py311 9m 1s
✓ j8_cqlsh_dtests_py311_vnode 6m 20s
✓ j8_cqlsh_dtests_py38 8m 37s
✓ j8_cqlsh_dtests_py38_vnode7m 2s
✓ j8_cqlsh_dtests_py3_vnode5m 44s
✓ j8_cqlshlib_tests8m 13s
✓ j8_dtests 32m 11s
✓ j8_dtests_vnode 37m 10s
✓ j8_jvm_dtests 12m 46s
✓ j8_unit_tests_repeat 8m 12s
✓ j11_unit_tests_repeat7m 42s
✓ j11_dtests_vnode 35m 3s
✓ j11_dtests 31m 14s
✓ j11_cqlsh_dtests_py3_vnode 5m 29s
✓ j11_cqlsh_dtests_py38_vnode 5m 51s
✓ j11_cqlsh_dtests_py385m 26s
✓ j11_cqlsh_dtests_py311_vnode 5m 43s
✓ j11_cqlsh_dtests_py311 5m 56s
✓ j11_cqlsh_dtests_py3 6m 3s
✓ j11_cqlsh-dtests-py2-with-vnodes 5m 47s
✓ j11_cqlsh-dtests-py2-no-vnodes 5m 51s
✕ j8_unit_tests 10m 58s
org.apache.cassandra.cql3.MemtableSizeTest testTruncationReleasesLogSpace
✕ j8_utests_system_keyspace_directory 10m 52s
org.apache.cassandra.index.sasi.SASICQLTest testPagingWithClustering
org.apache.cassandra.cql3.MemtableSizeTest testTruncationReleasesLogSpace
✕ j8_utests_system_keyspace_directory_repeat 8m 56s
org.apache.cassandra.db.ImportTest testImportInvalidateCache
✕ j11_unit_tests 8m 13s
org.apache.cassandra.net.ConnectionTest testMessageDeliveryOnReconnect
org.apache.cassandra.cql3.MemtableSizeTest testTruncationReleasesLogSpace
{noformat}
[java8_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4197/workflows/fa55d5f0-4ed8-4125-bb9e-f83a22446050]
org.apache.cassandra.db.ImportTest testImportInvalidateCache seem to be a flaky
one, similar case as for 5.0 build
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nod
[jira] [Created] (CASSANDRA-19570) Allow setting LIBFFI_TMPDIR
Thomas De Keulenaer created CASSANDRA-19570: --- Summary: Allow setting LIBFFI_TMPDIR Key: CASSANDRA-19570 URL: https://issues.apache.org/jira/browse/CASSANDRA-19570 Project: Cassandra Issue Type: Improvement Reporter: Thomas De Keulenaer Since JNA >= 5.10.0 you can specify LIBFFI_TMPDIR because the vendored libffi was upgraded. I think it is best to set this to the same value as jna.tmpdir. Perhaps in cassandra-env.sh? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19479:
---
Fix Version/s: 5.0-beta2
5.0
(was: 5.0-rc)
> Fix type issues and provide tests for type compatibility between 4.1 and 5.0
>
>
> Key: CASSANDRA-19479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19479
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Core, Test/unit
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.13, 4.1.5, 5.0-beta2, 5.0, 5.1
>
> Attachments: ci_summary.html, results_details.tar.xz
>
>
> This is a part of CASSANDRA-14476 - we should verify whether the type
> compatibility matrix is upgradable from 4.0 and 4.1 to 5.0, and if not, fix
> the remaining issues.
> The implemented tests verify the following:
> - assumed compatibility between primitive types
> - equals method symmetricity
> - freezing/unfreezing
> - value compatibility by using a serializer of one type to deserialize a
> value serialized using a serializer of another type
> - serialization compatibility by serializing a row with a column of one type
> as a column of another type for simple and complex cells (multicell types)
> - (comparison) compatibility by comparing serialized values of one type using
> a comparator of another type; for multicell types - build rows and compare
> cell paths of a complex type using a cell path comparator of another complex
> type
> - verify whether types that are (value/serialization/comparison) compatible
> in a previous release are still compatible with this release
> - store the compatibility matrix in a compressed JSON file so that we can
> copy it to future releases to assert backward compatibility (similar approach
> to LegacySSTableTest)
> - verify that type serializers are different for non-compatible type pairs
> which use custom comparisons
> Additionally:
> - the equals method in {{TupleType}} and {{UserType}} was fixed to be
> symmetric. Previously, comparing two values gave a different outcome when
> inverted.
> - fixed a condition in comparison method of {{AbstractCompositeType}}
> - ported a fix for composite and dynamic composite types which adds a
> distinct serializers for them so that the serializers for those types and for
> {{BytesType}} are considered different; similar thing was done for
> {{LexicalUUIDType}} to make its serializer different to {{UUIDType}}
> serializer (see
> https://the-asf.slack.com/archives/CK23JSY2K/p1712060572432959)
> - fixed a problem with DCT builder - in 5.0+ the {{DynamicCompositeType}}
> generation has a problem with inverse alias-type mapping which makes it
> vulnerable to problems when the same type has two different aliases
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838617#comment-17838617
]
Brandon Williams commented on CASSANDRA-19565:
--
bq. Also, on Cassandra 5.x with JNA >= 5.10.0 you can specify LIBFFI_TMPDIR.
Can you open a new ticket for this?
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19569) sstableupgrade is very slow
[
https://issues.apache.org/jira/browse/CASSANDRA-19569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19569:
-
Bug Category: Parent values: Degradation(12984)Level 1 values: Performance
Bug/Regression(12997)
Complexity: Normal
Component/s: Local/Compaction
Discovered By: User Report
Fix Version/s: 4.1.x
Severity: Normal
Status: Open (was: Triage Needed)
> sstableupgrade is very slow
> ---
>
> Key: CASSANDRA-19569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19569
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Norbert Schultz
>Priority: Normal
> Fix For: 4.1.x
>
> Attachments: flamegraph_ok.png, flamegraph_sstableupgrade.png
>
>
> We are in the process of migrating cassandra from 3.11.x to 4.1.4 and
> upgrading the sstables using sstableupgrade from Cassandra V4.1.4, from `me-`
> to `nb-` Format
> Unfortunately, the process is very very slow (less than 0.5 MB/s).
> Some observations:
> - The process is only slow on (fast) SSDs, but not on ram disks.
> - The sstables consist of many partitions (this may be unrelated)
> - The upgrade process is fast, if we use `automatic_sstable_upgrade` instead
> of the sstableupgradetool.
> - We give enough RAM (export MAX_HEAP_SIZE=8g)
> On profiling, we found out, that sstableupgrade is burning most CPU time on
> {{posix_fadvise}} (see flamegraph_sstableupgrade.png ).
> My naive interpretation of the whole {{maybeReopenEarly}} to
> {{posix_fadvise}} chain is, that the process just informs the linux kernel,
> that the written data should not be cached. If we comment out the call to
> {{NativeLibrary.trySkipCache}}, the conversion is running at expected 10MB/s
> (see flamegraph_ok.png )
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19479:
--
Fix Version/s: 4.0.13
4.1.5
5.0-rc
5.1
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/f92998190ccfc688e22d035318848a2f61987585
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix type issues and provide tests for type compatibility between 4.1 and 5.0
>
>
> Key: CASSANDRA-19479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19479
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Core, Test/unit
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.13, 4.1.5, 5.0-rc, 5.1
>
> Attachments: ci_summary.html, results_details.tar.xz
>
>
> This is a part of CASSANDRA-14476 - we should verify whether the type
> compatibility matrix is upgradable from 4.0 and 4.1 to 5.0, and if not, fix
> the remaining issues.
> The implemented tests verify the following:
> - assumed compatibility between primitive types
> - equals method symmetricity
> - freezing/unfreezing
> - value compatibility by using a serializer of one type to deserialize a
> value serialized using a serializer of another type
> - serialization compatibility by serializing a row with a column of one type
> as a column of another type for simple and complex cells (multicell types)
> - (comparison) compatibility by comparing serialized values of one type using
> a comparator of another type; for multicell types - build rows and compare
> cell paths of a complex type using a cell path comparator of another complex
> type
> - verify whether types that are (value/serialization/comparison) compatible
> in a previous release are still compatible with this release
> - store the compatibility matrix in a compressed JSON file so that we can
> copy it to future releases to assert backward compatibility (similar approach
> to LegacySSTableTest)
> - verify that type serializers are different for non-compatible type pairs
> which use custom comparisons
> Additionally:
> - the equals method in {{TupleType}} and {{UserType}} was fixed to be
> symmetric. Previously, comparing two values gave a different outcome when
> inverted.
> - fixed a condition in comparison method of {{AbstractCompositeType}}
> - ported a fix for composite and dynamic composite types which adds a
> distinct serializers for them so that the serializers for those types and for
> {{BytesType}} are considered different; similar thing was done for
> {{LexicalUUIDType}} to make its serializer different to {{UUIDType}}
> serializer (see
> https://the-asf.slack.com/archives/CK23JSY2K/p1712060572432959)
> - fixed a problem with DCT builder - in 5.0+ the {{DynamicCompositeType}}
> generation has a problem with inverse alias-type mapping which makes it
> vulnerable to problems when the same type has two different aliases
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-5.0' into trunk
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d9192745bc4c67f14445b5fea416736b5cec5a46 Merge: c33c8ebab4 82297b490e Author: Jacek Lewandowski AuthorDate: Thu Apr 18 12:33:56 2024 +0200 Merge branch 'cassandra-5.0' into trunk * cassandra-5.0: Fix few types issues and implement types compatibility tests CHANGES.txt| 1 + .../db/marshal/AbstractCompositeType.java | 2 +- .../org/apache/cassandra/db/marshal/TupleType.java | 6 +- .../apache/cassandra/db/marshal/TypeParser.java| 2 +- .../org/apache/cassandra/db/marshal/UserType.java | 2 +- .../apache/cassandra/utils/CassandraVersion.java | 5 + test/data/types-compatibility/4.0.json.gz | Bin 0 -> 397346 bytes test/data/types-compatibility/4.1.json.gz | Bin 0 -> 396407 bytes test/data/types-compatibility/5.0.json.gz | Bin 0 -> 397761 bytes .../cassandra/db/marshal/AbstractTypeTest.java | 922 - .../cassandra/utils/AbstractTypeGenerators.java| 228 - .../utils/asserts/SoftAssertionsWithLimit.java | 42 + 12 files changed, 1200 insertions(+), 10 deletions(-) diff --cc CHANGES.txt index 6d9856ae5c,99f938c40b..4f07c455df --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -69,9 -36,10 +69,10 @@@ Merged from 4.1 * Fix hints delivery for a node going down repeatedly (CASSANDRA-19495) * Do not go to disk for reading hints file sizes (CASSANDRA-19477) * Fix system_views.settings to handle array types (CASSANDRA-19475) - * Memoize Cassandra verion and add a backoff interval for failed schema pulls (CASSANDRA-18902) * Fix StackOverflowError on ALTER after many previous schema changes (CASSANDRA-19166) + * Memoize Cassandra verion (CASSANDRA-18902) Merged from 4.0: + * Fix few types issues and implement types compatibility tests (CASSANDRA-19479) * Change logging to TRACE when failing to get peer certificate (CASSANDRA-19508) * Push LocalSessions info logs to debug (CASSANDRA-18335) * Filter remote DC replicas out when constructing the initial replica plan for the local read repair (CASSANDRA-19120) diff --cc test/unit/org/apache/cassandra/db/marshal/AbstractTypeTest.java index 22925d1e1f,499470904d..35ecfab60d --- a/test/unit/org/apache/cassandra/db/marshal/AbstractTypeTest.java +++ b/test/unit/org/apache/cassandra/db/marshal/AbstractTypeTest.java @@@ -42,11 -70,23 +70,23 @@@ import org.apache.cassandra.config.Data import org.apache.cassandra.cql3.AssignmentTestable; import org.apache.cassandra.cql3.ColumnIdentifier; import org.apache.cassandra.cql3.ColumnSpecification; -import org.apache.cassandra.cql3.Constants; +import org.apache.cassandra.cql3.terms.Constants; import org.apache.cassandra.cql3.Json; import org.apache.cassandra.cql3.QueryOptions; -import org.apache.cassandra.cql3.Term; +import org.apache.cassandra.cql3.terms.Term; import org.apache.cassandra.cql3.VariableSpecifications; + import org.apache.cassandra.db.SerializationHeader; + import org.apache.cassandra.db.filter.ColumnFilter; + import org.apache.cassandra.db.rows.BTreeRow; + import org.apache.cassandra.db.rows.Cell; + import org.apache.cassandra.db.rows.CellPath; + import org.apache.cassandra.db.rows.ComplexColumnData; + import org.apache.cassandra.db.rows.DeserializationHelper; + import org.apache.cassandra.db.rows.EncodingStats; + import org.apache.cassandra.db.rows.Row; + import org.apache.cassandra.db.rows.Rows; + import org.apache.cassandra.db.rows.SerializationHelper; + import org.apache.cassandra.db.rows.UnfilteredSerializer; import org.apache.cassandra.io.util.DataInputBuffer; import org.apache.cassandra.io.util.DataInputPlus; import org.apache.cassandra.io.util.DataOutputBuffer; - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated (c33c8ebab4 -> d9192745bc)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from c33c8ebab4 Merge branch 'cassandra-5.0' into trunk add f92998190c Fix few types issues and implement types compatibility tests add 445ae1a4b1 Merge branch 'cassandra-4.0' into cassandra-4.1 add 82297b490e Merge branch 'cassandra-4.1' into cassandra-5.0 new d9192745bc Merge branch 'cassandra-5.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../db/marshal/AbstractCompositeType.java | 2 +- .../org/apache/cassandra/db/marshal/TupleType.java | 6 +- .../apache/cassandra/db/marshal/TypeParser.java| 2 +- .../org/apache/cassandra/db/marshal/UserType.java | 2 +- .../apache/cassandra/utils/CassandraVersion.java | 5 + test/data/types-compatibility/4.0.json.gz | Bin 0 -> 397346 bytes test/data/types-compatibility/4.1.json.gz | Bin 0 -> 396407 bytes test/data/types-compatibility/5.0.json.gz | Bin 0 -> 397761 bytes .../cassandra/db/marshal/AbstractTypeTest.java | 922 - .../cassandra/utils/AbstractTypeGenerators.java| 228 - .../utils/asserts/SoftAssertionsWithLimit.java | 25 +- 12 files changed, 1174 insertions(+), 19 deletions(-) create mode 100644 test/data/types-compatibility/4.0.json.gz create mode 100644 test/data/types-compatibility/4.1.json.gz create mode 100644 test/data/types-compatibility/5.0.json.gz copy src/java/org/apache/cassandra/gms/VersionGenerator.java => test/unit/org/apache/cassandra/utils/asserts/SoftAssertionsWithLimit.java (61%) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-4.1 updated (643d7f1751 -> 445ae1a4b1)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 643d7f1751 Merge branch 'cassandra-4.0' into cassandra-4.1 add f92998190c Fix few types issues and implement types compatibility tests add 445ae1a4b1 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt|1 + build.xml |4 +- .../db/marshal/AbstractCompositeType.java |2 +- .../cassandra/db/marshal/ByteArrayAccessor.java|7 + .../cassandra/db/marshal/ByteBufferAccessor.java |7 + .../apache/cassandra/db/marshal/CompositeType.java | 39 + .../cassandra/db/marshal/DynamicCompositeType.java | 47 +- .../cassandra/db/marshal/LexicalUUIDType.java |8 +- .../org/apache/cassandra/db/marshal/TupleType.java |6 +- .../apache/cassandra/db/marshal/TypeParser.java|2 +- .../org/apache/cassandra/db/marshal/UserType.java |2 +- .../apache/cassandra/db/marshal/ValueAccessor.java |6 + .../apache/cassandra/utils/CassandraVersion.java |5 + .../apache/cassandra/utils/FastByteOperations.java |5 + test/data/types-compatibility/4.0.json.gz | Bin 0 -> 397346 bytes test/data/types-compatibility/4.1.json.gz | Bin 0 -> 396407 bytes .../distributed/test/SSTableIdGenerationTest.java |2 +- .../distributed/util/QueryResultUtil.java |9 +- .../cql3/validation/entities/TupleTypeTest.java|5 +- .../cassandra/db/marshal/AbstractTypeTest.java | 1001 .../org/apache/cassandra/repair/RepairJobTest.java |9 +- .../cassandra/utils/AbstractTypeGenerators.java| 823 +++- .../cassandra/utils/CassandraGenerators.java | 21 + .../org/apache/cassandra/utils/Generators.java | 58 ++ .../utils/asserts/SoftAssertionsWithLimit.java | 27 +- test/unit/org/quicktheories/impl/JavaRandom.java | 112 +++ 26 files changed, 2136 insertions(+), 72 deletions(-) create mode 100644 test/data/types-compatibility/4.0.json.gz create mode 100644 test/data/types-compatibility/4.1.json.gz create mode 100644 test/unit/org/apache/cassandra/db/marshal/AbstractTypeTest.java copy src/java/org/apache/cassandra/gms/VersionGenerator.java => test/unit/org/apache/cassandra/utils/asserts/SoftAssertionsWithLimit.java (56%) create mode 100644 test/unit/org/quicktheories/impl/JavaRandom.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-5.0 updated (9bfaee91c4 -> 82297b490e)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 9bfaee91c4 Optionally fail writes when SAI refuses to index a term value exceeding a configured maximum size add f92998190c Fix few types issues and implement types compatibility tests add 445ae1a4b1 Merge branch 'cassandra-4.0' into cassandra-4.1 add 82297b490e Merge branch 'cassandra-4.1' into cassandra-5.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../db/marshal/AbstractCompositeType.java | 2 +- .../org/apache/cassandra/db/marshal/TupleType.java | 6 +- .../apache/cassandra/db/marshal/TypeParser.java| 2 +- .../org/apache/cassandra/db/marshal/UserType.java | 2 +- .../apache/cassandra/utils/CassandraVersion.java | 6 + test/data/types-compatibility/4.0.json.gz | Bin 0 -> 397346 bytes test/data/types-compatibility/4.1.json.gz | Bin 0 -> 396407 bytes test/data/types-compatibility/5.0.json.gz | Bin 0 -> 397761 bytes .../cassandra/db/marshal/AbstractTypeTest.java | 922 - .../cassandra/utils/AbstractTypeGenerators.java| 228 - .../utils/asserts/SoftAssertionsWithLimit.java | 25 +- 12 files changed, 1175 insertions(+), 19 deletions(-) create mode 100644 test/data/types-compatibility/4.0.json.gz create mode 100644 test/data/types-compatibility/4.1.json.gz create mode 100644 test/data/types-compatibility/5.0.json.gz copy src/java/org/apache/cassandra/gms/VersionGenerator.java => test/unit/org/apache/cassandra/utils/asserts/SoftAssertionsWithLimit.java (61%) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-4.0 updated (0662094b84 -> f92998190c)
This is an automated email from the ASF dual-hosted git repository. jlewandowski pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 0662094b84 Merge branch 'cassandra-3.11' into cassandra-4.0 add f92998190c Fix few types issues and implement types compatibility tests No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + build.xml | 4 +- .../db/marshal/AbstractCompositeType.java | 2 +- .../cassandra/db/marshal/ByteArrayAccessor.java| 7 + .../cassandra/db/marshal/ByteBufferAccessor.java | 7 + .../apache/cassandra/db/marshal/CompositeType.java | 39 + .../cassandra/db/marshal/DynamicCompositeType.java | 47 +- .../cassandra/db/marshal/LexicalUUIDType.java | 8 +- .../org/apache/cassandra/db/marshal/TupleType.java | 6 +- .../apache/cassandra/db/marshal/TypeParser.java| 2 +- .../org/apache/cassandra/db/marshal/UserType.java | 2 +- .../apache/cassandra/db/marshal/ValueAccessor.java | 6 + .../apache/cassandra/utils/CassandraVersion.java | 5 + .../apache/cassandra/utils/FastByteOperations.java | 5 + test/data/types-compatibility/4.0.json.gz | Bin 0 -> 397346 bytes .../cql3/validation/entities/TupleTypeTest.java| 5 +- .../cassandra/db/marshal/AbstractTypeTest.java | 998 + .../org/apache/cassandra/repair/RepairJobTest.java | 3 +- .../cassandra/utils/AbstractTypeGenerators.java| 823 - .../cassandra/utils/CassandraGenerators.java | 21 + .../org/apache/cassandra/utils/Generators.java | 59 ++ .../utils/asserts/SoftAssertionsWithLimit.java | 27 +- test/unit/org/quicktheories/impl/JavaRandom.java | 112 +++ 23 files changed, 2125 insertions(+), 64 deletions(-) create mode 100644 test/data/types-compatibility/4.0.json.gz create mode 100644 test/unit/org/apache/cassandra/db/marshal/AbstractTypeTest.java copy src/java/org/apache/cassandra/gms/VersionGenerator.java => test/unit/org/apache/cassandra/utils/asserts/SoftAssertionsWithLimit.java (56%) create mode 100644 test/unit/org/quicktheories/impl/JavaRandom.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19479:
--
Attachment: results_details.tar.xz
ci_summary.html
> Fix type issues and provide tests for type compatibility between 4.1 and 5.0
>
>
> Key: CASSANDRA-19479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19479
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Core, Test/unit
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary.html, results_details.tar.xz
>
>
> This is a part of CASSANDRA-14476 - we should verify whether the type
> compatibility matrix is upgradable from 4.0 and 4.1 to 5.0, and if not, fix
> the remaining issues.
> The implemented tests verify the following:
> - assumed compatibility between primitive types
> - equals method symmetricity
> - freezing/unfreezing
> - value compatibility by using a serializer of one type to deserialize a
> value serialized using a serializer of another type
> - serialization compatibility by serializing a row with a column of one type
> as a column of another type for simple and complex cells (multicell types)
> - (comparison) compatibility by comparing serialized values of one type using
> a comparator of another type; for multicell types - build rows and compare
> cell paths of a complex type using a cell path comparator of another complex
> type
> - verify whether types that are (value/serialization/comparison) compatible
> in a previous release are still compatible with this release
> - store the compatibility matrix in a compressed JSON file so that we can
> copy it to future releases to assert backward compatibility (similar approach
> to LegacySSTableTest)
> - verify that type serializers are different for non-compatible type pairs
> which use custom comparisons
> Additionally:
> - the equals method in {{TupleType}} and {{UserType}} was fixed to be
> symmetric. Previously, comparing two values gave a different outcome when
> inverted.
> - fixed a condition in comparison method of {{AbstractCompositeType}}
> - ported a fix for composite and dynamic composite types which adds a
> distinct serializers for them so that the serializers for those types and for
> {{BytesType}} are considered different; similar thing was done for
> {{LexicalUUIDType}} to make its serializer different to {{UUIDType}}
> serializer (see
> https://the-asf.slack.com/archives/CK23JSY2K/p1712060572432959)
> - fixed a problem with DCT builder - in 5.0+ the {{DynamicCompositeType}}
> generation has a problem with inverse alias-type mapping which makes it
> vulnerable to problems when the same type has two different aliases
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19479:
--
Status: Ready to Commit (was: Review In Progress)
> Fix type issues and provide tests for type compatibility between 4.1 and 5.0
>
>
> Key: CASSANDRA-19479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19479
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Core, Test/unit
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: ci_summary.html, results_details.tar.xz
>
>
> This is a part of CASSANDRA-14476 - we should verify whether the type
> compatibility matrix is upgradable from 4.0 and 4.1 to 5.0, and if not, fix
> the remaining issues.
> The implemented tests verify the following:
> - assumed compatibility between primitive types
> - equals method symmetricity
> - freezing/unfreezing
> - value compatibility by using a serializer of one type to deserialize a
> value serialized using a serializer of another type
> - serialization compatibility by serializing a row with a column of one type
> as a column of another type for simple and complex cells (multicell types)
> - (comparison) compatibility by comparing serialized values of one type using
> a comparator of another type; for multicell types - build rows and compare
> cell paths of a complex type using a cell path comparator of another complex
> type
> - verify whether types that are (value/serialization/comparison) compatible
> in a previous release are still compatible with this release
> - store the compatibility matrix in a compressed JSON file so that we can
> copy it to future releases to assert backward compatibility (similar approach
> to LegacySSTableTest)
> - verify that type serializers are different for non-compatible type pairs
> which use custom comparisons
> Additionally:
> - the equals method in {{TupleType}} and {{UserType}} was fixed to be
> symmetric. Previously, comparing two values gave a different outcome when
> inverted.
> - fixed a condition in comparison method of {{AbstractCompositeType}}
> - ported a fix for composite and dynamic composite types which adds a
> distinct serializers for them so that the serializers for those types and for
> {{BytesType}} are considered different; similar thing was done for
> {{LexicalUUIDType}} to make its serializer different to {{UUIDType}}
> serializer (see
> https://the-asf.slack.com/archives/CK23JSY2K/p1712060572432959)
> - fixed a problem with DCT builder - in 5.0+ the {{DynamicCompositeType}}
> generation has a problem with inverse alias-type mapping which makes it
> vulnerable to problems when the same type has two different aliases
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19479:
--
Reviewers: Stefan Miklosovic
Status: Review In Progress (was: Patch Available)
> Fix type issues and provide tests for type compatibility between 4.1 and 5.0
>
>
> Key: CASSANDRA-19479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19479
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Core, Test/unit
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> This is a part of CASSANDRA-14476 - we should verify whether the type
> compatibility matrix is upgradable from 4.0 and 4.1 to 5.0, and if not, fix
> the remaining issues.
> The implemented tests verify the following:
> - assumed compatibility between primitive types
> - equals method symmetricity
> - freezing/unfreezing
> - value compatibility by using a serializer of one type to deserialize a
> value serialized using a serializer of another type
> - serialization compatibility by serializing a row with a column of one type
> as a column of another type for simple and complex cells (multicell types)
> - (comparison) compatibility by comparing serialized values of one type using
> a comparator of another type; for multicell types - build rows and compare
> cell paths of a complex type using a cell path comparator of another complex
> type
> - verify whether types that are (value/serialization/comparison) compatible
> in a previous release are still compatible with this release
> - store the compatibility matrix in a compressed JSON file so that we can
> copy it to future releases to assert backward compatibility (similar approach
> to LegacySSTableTest)
> - verify that type serializers are different for non-compatible type pairs
> which use custom comparisons
> Additionally:
> - the equals method in {{TupleType}} and {{UserType}} was fixed to be
> symmetric. Previously, comparing two values gave a different outcome when
> inverted.
> - fixed a condition in comparison method of {{AbstractCompositeType}}
> - ported a fix for composite and dynamic composite types which adds a
> distinct serializers for them so that the serializers for those types and for
> {{BytesType}} are considered different; similar thing was done for
> {{LexicalUUIDType}} to make its serializer different to {{UUIDType}}
> serializer (see
> https://the-asf.slack.com/archives/CK23JSY2K/p1712060572432959)
> - fixed a problem with DCT builder - in 5.0+ the {{DynamicCompositeType}}
> generation has a problem with inverse alias-type mapping which makes it
> vulnerable to problems when the same type has two different aliases
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838546#comment-17838546
]
Sam Tunnicliffe commented on CASSANDRA-19567:
-
bq. The problem is only reproducible on the x86 machine, the problem is not
reproducible on the arm64.
We've observed the increased heap usage on apple silicon, so I don't believe
this is entirely true.
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
> FAILED (crashed)BUILD FAILED
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19566) JSON encoded timestamp value does not always match non-JSON encoded value
[
https://issues.apache.org/jira/browse/CASSANDRA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838545#comment-17838545
]
Stefan Miklosovic commented on CASSANDRA-19566:
---
working on it
> JSON encoded timestamp value does not always match non-JSON encoded value
> -
>
> Key: CASSANDRA-19566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19566
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Bowen Song
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Description:
> "SELECT JSON ..." and "toJson(...)" on Cassandra 4.1.4 produces different
> date than "SELECT ..." for some timestamp type values.
>
> Steps to reproduce:
> {code:java}
> $ sudo docker pull cassandra:4.1.4
> $ sudo docker create --name cass cassandra:4.1.4
> $ sudo docker start cass
> $ # wait for the Cassandra instance becomes ready
> $ sudo docker exec -ti cass cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.1.0 | Cassandra 4.1.4 | CQL spec 3.4.6 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table tbl (id int, ts timestamp, primary key (id));
> cqlsh:test> insert into tbl (id, ts) values (1, -1376701920);
> cqlsh:test> select tounixtimestamp(ts), ts, tojson(ts) from tbl where id=1;
> system.tounixtimestamp(ts) | ts |
> system.tojson(ts)
> +-+
> -1376701920 | 1533-09-28 12:00:00.00+ | "1533-09-18
> 12:00:00.000Z"
> (1 rows)
> cqlsh:test> select json * from tbl where id=1;
> [json]
> -
> {"id": 1, "ts": "1533-09-18 12:00:00.000Z"}
> (1 rows)
> {code}
>
> Expected behaviour:
> The "select ts", "select tojson(ts)" and "select json *" should all produce
> the same date.
>
> Actual behaviour:
> The "select ts" produced the "1533-09-28" date but the "select tojson(ts)"
> and "select json *" produced the "1533-09-18" date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19566) JSON encoded timestamp value does not always match non-JSON encoded value
[
https://issues.apache.org/jira/browse/CASSANDRA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838532#comment-17838532
]
Berenguer Blasi commented on CASSANDRA-19566:
-
Is there a CI link?
> JSON encoded timestamp value does not always match non-JSON encoded value
> -
>
> Key: CASSANDRA-19566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19566
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Bowen Song
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Description:
> "SELECT JSON ..." and "toJson(...)" on Cassandra 4.1.4 produces different
> date than "SELECT ..." for some timestamp type values.
>
> Steps to reproduce:
> {code:java}
> $ sudo docker pull cassandra:4.1.4
> $ sudo docker create --name cass cassandra:4.1.4
> $ sudo docker start cass
> $ # wait for the Cassandra instance becomes ready
> $ sudo docker exec -ti cass cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.1.0 | Cassandra 4.1.4 | CQL spec 3.4.6 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table tbl (id int, ts timestamp, primary key (id));
> cqlsh:test> insert into tbl (id, ts) values (1, -1376701920);
> cqlsh:test> select tounixtimestamp(ts), ts, tojson(ts) from tbl where id=1;
> system.tounixtimestamp(ts) | ts |
> system.tojson(ts)
> +-+
> -1376701920 | 1533-09-28 12:00:00.00+ | "1533-09-18
> 12:00:00.000Z"
> (1 rows)
> cqlsh:test> select json * from tbl where id=1;
> [json]
> -
> {"id": 1, "ts": "1533-09-18 12:00:00.000Z"}
> (1 rows)
> {code}
>
> Expected behaviour:
> The "select ts", "select tojson(ts)" and "select json *" should all produce
> the same date.
>
> Actual behaviour:
> The "select ts" produced the "1533-09-28" date but the "select tojson(ts)"
> and "select json *" produced the "1533-09-18" date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19564) MemtablePostFlush deadlock leads to stuck nodes and crashes
[
https://issues.apache.org/jira/browse/CASSANDRA-19564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838525#comment-17838525
]
Benedict Elliott Smith commented on CASSANDRA-19564:
The {{isBlocking}} flag is what indicates that you can skip the memtable
allocator limit checks. The earliest possible {{OpOrder.Group}} (so walking the
{{prev}} links until there are no more) is the one that will be stopping
progress.
If you can upload / send a jstack dump while the node is locked up I can
_probably_ diagnose it.
> MemtablePostFlush deadlock leads to stuck nodes and crashes
> ---
>
> Key: CASSANDRA-19564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19564
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/Memtable
>Reporter: Jon Haddad
>Priority: Urgent
> Fix For: 4.1.x
>
> Attachments: image-2024-04-16-11-55-54-750.png,
> image-2024-04-16-12-29-15-386.png, image-2024-04-16-13-43-11-064.png,
> image-2024-04-16-13-53-24-455.png, image-2024-04-17-18-46-29-474.png,
> image-2024-04-17-19-13-06-769.png, image-2024-04-17-19-14-34-344.png
>
>
> I've run into an issue on a 4.1.4 cluster where an entire node has locked up
> due to what I believe is a deadlock in memtable flushing. Here's what I know
> so far. I've stitched together what happened based on conversations, logs,
> and some flame graphs.
> *Log reports memtable flushing*
> The last successful flush happens at 12:19.
> {noformat}
> INFO [NativePoolCleaner] 2024-04-16 12:19:53,634
> AbstractAllocatorMemtable.java:286 - Flushing largest CFS(Keyspace='ks',
> ColumnFamily='version') to free up room. Used total: 0.24/0.33, live:
> 0.16/0.20, flushing: 0.09/0.13, this: 0.13/0.15
> INFO [NativePoolCleaner] 2024-04-16 12:19:53,634 ColumnFamilyStore.java:1012
> - Enqueuing flush of ks.version, Reason: MEMTABLE_LIMIT, Usage: 660.521MiB
> (13%) on-heap, 790.606MiB (15%) off-heap
> {noformat}
> *MemtablePostFlush appears to be blocked*
> At this point, MemtablePostFlush completed tasks stops incrementing, active
> stays at 1 and pending starts to rise.
> {noformat}
> MemtablePostFlush 1 1 3446 0 0
> {noformat}
>
> The flame graph reveals that PostFlush.call is stuck. I don't have the line
> number, but I know we're stuck in
> {{org.apache.cassandra.db.ColumnFamilyStore.PostFlush#call}} given the visual
> below:
> *!image-2024-04-16-13-43-11-064.png!*
> *Memtable flushing is now blocked.*
> All MemtableFlushWriter threads are Parked waiting on
> {{{}OpOrder.Barrier.await{}}}. A wall clock profile of 30s reveals all time
> is spent here. Presumably we're waiting on the single threaded Post Flush.
> !image-2024-04-16-12-29-15-386.png!
> *Memtable allocations start to block*
> Eventually it looks like the NativeAllocator stops successfully allocating
> memory. I assume it's waiting on memory to be freed, but since memtable
> flushes are blocked, we wait indefinitely.
> Looking at a wall clock flame graph, all writer threads have reached the
> allocation failure path of {{MemtableAllocator.allocate()}}. I believe we're
> waiting on {{signal.awaitThrowUncheckedOnInterrupt()}}
> {noformat}
> MutationStage 48 828425 980253369 0 0{noformat}
> !image-2024-04-16-11-55-54-750.png!
>
> *Compaction Stops*
> Since we write to the compaction history table, and that requires memtables,
> compactions are now blocked as well.
>
> !image-2024-04-16-13-53-24-455.png!
>
> The node is now doing basically nothing and must be restarted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838506#comment-17838506
]
Berenguer Blasi commented on CASSANDRA-19565:
-
It is not a bad idea at all to add that var 5.0+
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838501#comment-17838501
]
Stefan Miklosovic commented on CASSANDRA-19401:
---
[CASSANDRA-19401-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19401-trunk]
{noformat}
java11_pre-commit_tests
✓ j11_build8m 35s
✓ j11_cqlsh_dtests_py311 10m 43s
✓ j11_cqlsh_dtests_py311_vnode 8m 33s
✓ j11_cqlsh_dtests_py388m 37s
✓ j11_cqlsh_dtests_py38_vnode 9m 16s
✓ j11_cqlshlib_cython_tests 12m 31s
✓ j11_cqlshlib_tests 10m 9s
✓ j11_jvm_dtests_latest_vnode 22m 51s
✓ j11_unit_tests 19m 22s
✓ j11_unit_tests_repeat 10m 45s
✓ j11_utests_latest17m 4s
✓ j11_utests_latest_repeat 9m 50s
✓ j11_utests_oa_repeat10m 37s
✓ j11_utests_system_keyspace_directory_repeat 10m 12s
✓ j17_cqlsh_dtests_py311 7m 19s
✓ j17_cqlsh_dtests_py311_vnode 7m 34s
✓ j17_cqlsh_dtests_py386m 55s
✓ j17_cqlsh_dtests_py38_vnode 7m 38s
✓ j17_cqlshlib_cython_tests7m 54s
✓ j17_cqlshlib_tests 6m 16s
✓ j17_unit_tests 13m 45s
✓ j17_unit_tests_repeat 6m 7s
✓ j17_utests_latest16m 6s
✓ j17_utests_latest_repeat 6m 42s
✓ j17_utests_oa 17m 23s
✓ j17_utests_oa_repeat 6m 6s
✕ j11_dtests 38m 56s
gossip_test.TestGossip test_assassinate_valid_node
✕ j11_dtests_latest 37m 52s
configuration_test.TestConfiguration test_change_durable_writes
gossip_test.TestGossip test_assassinate_valid_node
✕ j11_dtests_vnode37m 21s
gossip_test.TestGossip test_assassinate_valid_node
✕ j11_jvm_dtests 39m 56s
org.apache.cassandra.distributed.test.log.FetchLogFromPeersTest
testCMSCatchupTest TIMEOUTED
✕ j11_simulator_dtests36m 28s
org.apache.cassandra.simulator.test.HarrySimulatorTest test
org.apache.cassandra.simulator.test.ShortPaxosSimulationTest
simulationTest
✕ j11_utests_oa 19m 44s
org.apache.cassandra.net.ConnectionTest testTimeout
✕ j11_utests_system_keyspace_directory 21m 5s
org.apache.cassandra.tools.TopPartitionsTest
testServiceTopPartitionsSingleTable
✕ j17_dtests 37m 14s
gossip_test.TestGossip test_assassinate_valid_node
✕ j17_dtests_latest 36m 41s
configuration_test.TestConfiguration test_change_durable_writes
gossip_test.TestGossip test_assassinate_valid_node
✕ j17_dtests_vnode 37m 1s
gossip_test.TestGossip test_assassinate_valid_node
✕ j17_jvm_dtests 27m 32s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testOptionalMtlsModeDoNotAllowNonSSLConnections TIMEOUTED
org.apache.cassandra.distributed.test.log.FetchLogFromPeersTest
testCMSCatchupTest
org.apache.cassandra.distributed.test.tcm.SplitBrainTest
testSplitBrainStartup TIMEOUTED
✕ j17_jvm_dtests_latest_vnode 22m 24s
junit.framework.TestSuite
org.apache.cassandra.fuzz.harry.integration.model.InJVMTokenAwareExecutorTest
TIMEOUTED
java11_separate_tests
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4192/workflows/09240a96-74db-4549-bb0d-7ad9a6776b09]
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the ke
[jira] [Commented] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838494#comment-17838494
]
Thomas De Keulenaer commented on CASSANDRA-19565:
-
bq. It's a pity we don't have a repro, we could upgrade jna on a 4.0 PR and see
if it fails then, confirming the jna upgrade is the bit causing the problem
You probably also need to lock the machine down with SE Linux to force libffi
to create executable files.
[ElasticSearch|https://github.com/elastic/elasticsearch/issues/77014] also had
this issue.
{quote}
Do we have an idea of the specific controls that need to be enabled to
reproduce?
We know at least some of them I think:
* SELinux enabled & configured to prevent mmap() from creating anonymous
executable & writeable mappings
* /tmp, /var/tmp, /dev/shm all nonexistent or mounted noexec
* $HOME nonexistent for the elasticsearch user
* All mount points in /etc/mtab not writable by elasticsearch, or mounted noexec
* $ES_TMPDIR (and hence java.io.tmpdir and/or jna.tmpdir) pointing somewhere
writeable and not mounted noexec.
* $TMPDIR unset
{quote}
Also, on Cassandra 5.x with JNA >= 5.10.0 you can specify LIBFFI_TMPDIR.
I think it is best to set this to the same value as jna.tmpdir. Perhaps in
cassandra-env.sh?
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
