[jira] [Comment Edited] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[
https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194544#comment-17194544
]
Caleb Rackliffe edited comment on CASSANDRA-15949 at 9/11/20, 10:08 PM:
[~dcapwell] So just to summarize, the plan would be...
1.) Remove the synchronization blocks on {{Keyspace}}.
2.) Replace the sync block on {{Keyspace}} in {{open()}} w/ a sync block on the
{{Schema}} singleton. (This ensures most access still results in a cache hit.)
3.) Given it's no longer possible, remove the check in my patch for a null
{{TableMetadataRef}} and the logging accompanying it.
Unless [~aleksey] has holes to poke in it, I like it...
was (Author: maedhroz):
[~dcapwell] So just to summarize, the plan would be...
1.) Remove the synchronization blocks on {{Keyspace}}.
2.) Replace the sync block on {{Keyspace}} in {{open()}} w/ a sync block on the
{{Schema}} singleton. (This ensures most access still results in a cache hit.)
3.) Given it's no longer possible, remove the check in my patch for a null
{{TableMetadataRef}} and the logging accompanying it.
> NPE thrown while updating speculative execution time if table is removed
> during task execution
> --
>
> Key: CASSANDRA-15949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15949
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jon Meredith
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> CASSANDRA-14338 fixed the scheduling the speculation retry threshold
> calculation, but if the task happens to be scheduled while a table is being
> dropped, it triggers an NPE.
> ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1]
> org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread
> Thread[OptionalTasks:1,5,main]
> java.lang.NullPointerException: null
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:346)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99)
> ~[cassandra-4.0.0.jar:4.0.0]
> at
> com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704)
> ~[guava-27.0-jre.jar:?]
> at
> com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45)
> ~[guava-27.0-jre.jar:?]
> at com.google.common.collect.Iterables$5.forEach(Iterables.java:704)
> ~[guava-27.0-jre.jar:?]
> at
> org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412)
> ~[cassandra-4.0.0.jar:4.0.0]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> [cassandra-4.0.0.jar:4.0.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.37.Final.jar:4.1.37.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[ https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194545#comment-17194545 ] Caleb Rackliffe commented on CASSANDRA-15949: - bq. I am wondering though if all should actually be allExisting, so rather than adding a new method we fix this method to avoid the problem? It looks like you're probably right on this one, but given there are a dozen or so places to audit, I lean toward avoiding it in this patch. > NPE thrown while updating speculative execution time if table is removed > during task execution > -- > > Key: CASSANDRA-15949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15949 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > CASSANDRA-14338 fixed the scheduling the speculation retry threshold > calculation, but if the task happens to be scheduled while a table is being > dropped, it triggers an NPE. > ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1] > org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread > Thread[OptionalTasks:1,5,main] > java.lang.NullPointerException: null > at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.(Keyspace.java:346) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99) > ~[cassandra-4.0.0.jar:4.0.0] > at > com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45) > ~[guava-27.0-jre.jar:?] > at com.google.common.collect.Iterables$5.forEach(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412) > ~[cassandra-4.0.0.jar:4.0.0] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118) > [cassandra-4.0.0.jar:4.0.0] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > [?:?] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > [netty-all-4.1.37.Final.jar:4.1.37.Final] > at java.lang.Thread.run(Thread.java:834) [?:?] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[
https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194544#comment-17194544
]
Caleb Rackliffe edited comment on CASSANDRA-15949 at 9/11/20, 10:06 PM:
[~dcapwell] So just to summarize, the plan would be...
1.) Remove the synchronization blocks on {{Keyspace}}.
2.) Replace the sync block on {{Keyspace}} in {{open()}} w/ a sync block on the
{{Schema}} singleton. (This ensures most access still results in a cache hit.)
3.) Given it's no longer possible, remove the check in my patch for a null
{{TableMetadataRef}} and the logging accompanying it.
was (Author: maedhroz):
[~dcapwell] So just to summarize, the plan would be...
1.) Remove the synchronization blocks on {{Keyspace}}.
2.) Replace the sync block on {{Keyspace}} in {{open()}} w/ a sync block on the
{{Schema}} singleton.
3.) Given it's no longer possible, remove the check in my patch for a null
{{TableMetadataRef}} and the logging accompanying it.
> NPE thrown while updating speculative execution time if table is removed
> during task execution
> --
>
> Key: CASSANDRA-15949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15949
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jon Meredith
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> CASSANDRA-14338 fixed the scheduling the speculation retry threshold
> calculation, but if the task happens to be scheduled while a table is being
> dropped, it triggers an NPE.
> ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1]
> org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread
> Thread[OptionalTasks:1,5,main]
> java.lang.NullPointerException: null
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:346)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99)
> ~[cassandra-4.0.0.jar:4.0.0]
> at
> com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704)
> ~[guava-27.0-jre.jar:?]
> at
> com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45)
> ~[guava-27.0-jre.jar:?]
> at com.google.common.collect.Iterables$5.forEach(Iterables.java:704)
> ~[guava-27.0-jre.jar:?]
> at
> org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412)
> ~[cassandra-4.0.0.jar:4.0.0]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> [cassandra-4.0.0.jar:4.0.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.37.Final.jar:4.1.37.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[
https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194544#comment-17194544
]
Caleb Rackliffe commented on CASSANDRA-15949:
-
[~dcapwell] So just to summarize, the plan would be...
1.) Remove the synchronization blocks on {{Keyspace}}.
2.) Replace the sync block on {{Keyspace}} in {{open()}} w/ a sync block on the
{{Schema}} singleton.
3.) Given it's no longer possible, remove the check in my patch for a null
{{TableMetadataRef}} and the logging accompanying it.
> NPE thrown while updating speculative execution time if table is removed
> during task execution
> --
>
> Key: CASSANDRA-15949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15949
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jon Meredith
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> CASSANDRA-14338 fixed the scheduling the speculation retry threshold
> calculation, but if the task happens to be scheduled while a table is being
> dropped, it triggers an NPE.
> ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1]
> org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread
> Thread[OptionalTasks:1,5,main]
> java.lang.NullPointerException: null
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:346)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99)
> ~[cassandra-4.0.0.jar:4.0.0]
> at
> com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704)
> ~[guava-27.0-jre.jar:?]
> at
> com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45)
> ~[guava-27.0-jre.jar:?]
> at com.google.common.collect.Iterables$5.forEach(Iterables.java:704)
> ~[guava-27.0-jre.jar:?]
> at
> org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412)
> ~[cassandra-4.0.0.jar:4.0.0]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> [cassandra-4.0.0.jar:4.0.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.37.Final.jar:4.1.37.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194541#comment-17194541
]
Stefan Miklosovic commented on CASSANDRA-13935:
---
I havent found any way how to test that in 3.11. I could not find a place where
we are producing CQL from UDF nor UDA. There is just a ColumnFamilyCQLHelper
(something like that) and it does not dump functions nor aggregates. Aggregates
and functions are not associated with a CF but with a keyspace and there isnt
any "toCQL" on a function (hence aggregate) either. UDF and UDA are not part of
CQL schema dump upon taking a snapshot as the original goal of this ticket was
not to dump them anyway, just indexes are udts.
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16105) InvalidQuery when datetime string format is not zero padded
[
https://issues.apache.org/jira/browse/CASSANDRA-16105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16105:
--
Test and Documentation Plan: new unit test characterizing the behavior
Status: Patch Available (was: In Progress)
> InvalidQuery when datetime string format is not zero padded
> ---
>
> Key: CASSANDRA-16105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16105
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: João Reis
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> With CASSANDRA-15976, Cassandra no longer accepts certain datetime string
> formats that it used to accept before:
> {code:java}
> Unable to parse a date/time from '2020-09-03 9:00:00+'
> {code}
> In this example, {{2020-09-03 9:00:00+}} is not accepted in 4.0-beta2 but
> it is accepted in previous versions (I tested this with 4.0-beta1 and
> 3.11.4). If I add a zero so that it becomes {{2020-09-03 09:00:00+}} then
> it is accepted in all of the 3 mentioned versions (note the zero padded time
> part - {{9:00:00}} vs {{09:00:00}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16105) InvalidQuery when datetime string format is not zero padded
[
https://issues.apache.org/jira/browse/CASSANDRA-16105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194532#comment-17194532
]
Adam Holmberg commented on CASSANDRA-16105:
---
Potential [patch|https://github.com/aholmberg/cassandra/pull/5/files].
I learned that a single character for a numeric field in the DTF pattern
accepts arbitrary zero padding (or not). I didn't see this described in the
docs. I added a test characterizing it. Also happened to find some additional
correctness bugs around this in the *old* parsing, so "good", I guess.
CI running:
[j8|https://app.circleci.com/pipelines/github/aholmberg/cassandra/32/workflows/07410762-10cd-4039-a072-238522b9ba1e]
[j11|https://app.circleci.com/pipelines/github/aholmberg/cassandra/32/workflows/e6f7ff1c-b15f-46c1-83d5-f4082bac7ccd]
> InvalidQuery when datetime string format is not zero padded
> ---
>
> Key: CASSANDRA-16105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16105
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: João Reis
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> With CASSANDRA-15976, Cassandra no longer accepts certain datetime string
> formats that it used to accept before:
> {code:java}
> Unable to parse a date/time from '2020-09-03 9:00:00+'
> {code}
> In this example, {{2020-09-03 9:00:00+}} is not accepted in 4.0-beta2 but
> it is accepted in previous versions (I tested this with 4.0-beta1 and
> 3.11.4). If I add a zero so that it becomes {{2020-09-03 09:00:00+}} then
> it is accepted in all of the 3 mentioned versions (note the zero padded time
> part - {{9:00:00}} vs {{09:00:00}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[
https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15164:
Test and Documentation Plan: minor new unit test to verify changes to the
logic in {{StatsMetadata}}
Status: Patch Available (was: In Progress)
> Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
> ---
>
> Key: CASSANDRA-15164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15164
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Ankur Jha
>Assignee: Caleb Rackliffe
>Priority: Urgent
> Labels: compaction, partition
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi, we are running 6 node Cassandra cluster in production with 3 seed node
> but from last night one of our seed nodes is continuously throwing an error
> like this;-
> cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max
> when histogram overflowed">
> For a cluster to be up and running I Drained this node.
> Can somebody help me out with this?
>
> Any help or lead would be appreciated
>
> Note : We are using Cassandra version 3.7
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194529#comment-17194529 ] Caleb Rackliffe commented on CASSANDRA-15164: - I've taken a stab at both providing better visibility around overflowed histograms and taking reasonable action to prevent compaction failures when they are present. There are reasonable inline comments and a simple new test. [trunk|https://github.com/apache/cassandra/pull/750], [j8 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/112/workflows/ab37a692-bb8c-40f7-a4f6-d406ddf9f6d5], [j11 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/112/workflows/69c9a0ca-f627-4238-b94b-da182f86641b] > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194528#comment-17194528
]
Stefan Miklosovic commented on CASSANDRA-13935:
---
[~blerer] Test added in UFJavaTest.
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194524#comment-17194524 ] Jordan West edited comment on CASSANDRA-16048 at 9/11/20, 8:52 PM: --- [~ifesdjeen] do you have a repro of that? I added some column level deletes in a [test I added previously | https://github.com/apache/cassandra/blob/cassandra-3.0/test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage2to3UpgradeTest.java#L190] and didn't discover any issues. Admittedly, it could be more robust and there may be a case I missed (aside: it would be nice to have Harry for this), but if you have a repro to share that would be super helpful. Thanks! was (Author: jrwest): [~ifesdjeen] do you have a repro of that? I added some column level deletes in a [test I added previously | https://github.com/apache/cassandra/blob/cassandra-3.0/test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage2to3UpgradeTest.java#L190] and it didn't source any issues. Admittedly, it could be more robust and there may be a case I missed (aside: it would be nice to have Harry for this), but if you have a repro to share that would be super helpful. Thanks! > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194524#comment-17194524 ] Jordan West commented on CASSANDRA-16048: - [~ifesdjeen] do you have a repro of that? I added some column level deletes in a [test I added previously | https://github.com/apache/cassandra/blob/cassandra-3.0/test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage2to3UpgradeTest.java#L190] and it didn't source any issues. Admittedly, it could be more robust and there may be a case I missed (aside: it would be nice to have Harry for this), but if you have a repro to share that would be super helpful. Thanks! > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15981) jvm-dtests crash on java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15981:
--
Description:
There is a race condition bug with CMS and class unloading which cause the JVM
to crash. Since jvm-dtests rely on class loaders and unloading, this causes
sporadic JVM crashes that look like the following in CI logs
{code}
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
note the time in the report does not reflect the time until the VM exit.
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.Vector.forEach(Vector.java:1387)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.Vector.forEach(Vector.java:1387)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
Here is the JVM bug https://bugs.openjdk.java.net/browse/JDK-8252955
was:
There is a race condition bug with CMS and class unloading which cause the JVM
to crash. Since jvm-dtests rely on class loaders and unloading, this causes
sporadic JVM crashes that look like the following in CI logs
{code}
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
note the time in the report does not reflect the time until the VM exit.
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.Vector.forEach(Vector.java:1387)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.Vector.forEach(Vector.java:1387)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
> jvm-dtests crash on java 11
> ---
>
> Key: CASSANDRA-15981
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15981
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-beta2
>
>
> There is a race condition bug with CMS and class unloading which cause the
> JVM to crash. Since jvm-dtests rely on class loaders and unloading, this
> causes sporadic JVM crashes that look like the following in CI logs
> {code}
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally.
> Please note the time in the report does not reflect the time until the VM
> exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1387)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Commented] (CASSANDRA-16101) Make sure we don't throw any uncaught exceptions during in-jvm dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194494#comment-17194494
]
David Capwell commented on CASSANDRA-16101:
---
bq. I did this first, but then thought we could just catch any exceptions and
ignore them if expected, do you have an example where this would not be enough?
I was thinking about the repair tests which trigger failures by design. Since
repair uses JMXEnabledThreadPoolExecutor any thrown exception will be handled
in org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor#handleOrLog
which calls
{code:java}
Thread.getDefaultUncaughtExceptionHandler().uncaughtException(Thread.currentThread(),
t);
{code}
so they should cause that list to be non-empty.
bq. thought we could just catch any exceptions and ignore them if expected
I may be thinking about this differently than you, but not sure how the test
can catch and ignore them. The one thing that seems possible is if I try to
remove them from the list before the test ends (it is copy-on-write so I can
try to remove). In the repair tests we reuse the cluster, so would need to
wrap every test with a try/finally to attempt to cleanup expected exceptions.
> Make sure we don't throw any uncaught exceptions during in-jvm dtests
> -
>
> Key: CASSANDRA-16101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16101
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> We should assert that we don't throw any uncaught exceptions when running
> in-jvm dtests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15234:
--
Reviewers: Benjamin Lerer, David Capwell, Michael Semb Wever (was:
Benjamin Lerer, Michael Semb Wever)
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16057) Should update in-jvm dtest to expose stdout and stderr for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-16057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194479#comment-17194479 ] David Capwell commented on CASSANDRA-16057: --- Overall LGTM, only small comments remaining. [~ifesdjeen] can you review as well? Would be great to get the API changes in 0.0.5 > Should update in-jvm dtest to expose stdout and stderr for nodetool > --- > > Key: CASSANDRA-16057 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16057 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: David Capwell >Assignee: Yifan Cai >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Many nodetool commands output to stdout or stderr so running nodetool using > in-jvm dtest should expose that to tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[ https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194468#comment-17194468 ] David Capwell commented on CASSANDRA-15949: --- Patch looks good to me, it would avoid updater trying to open a keyspace and makes it so the constructor doesn't fail. I am wondering though if all should actually be allExisting, so rather than adding a new method we fix this method to avoid the problem? on-startup and on keyspace create we cache the Keyspace object, so Keyspace.open isn't actually needed in the majority of cases. Given the race above, I still think it may be best if Keyspace.open also locks on Schema so it has a consistent view during the open call and can learn if it still exists (only when the double check locking happens, not in the cache hit case). [~aleksey] it would be great if we could get your feedback as well. > NPE thrown while updating speculative execution time if table is removed > during task execution > -- > > Key: CASSANDRA-15949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15949 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > CASSANDRA-14338 fixed the scheduling the speculation retry threshold > calculation, but if the task happens to be scheduled while a table is being > dropped, it triggers an NPE. > ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1] > org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread > Thread[OptionalTasks:1,5,main] > java.lang.NullPointerException: null > at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.(Keyspace.java:346) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99) > ~[cassandra-4.0.0.jar:4.0.0] > at > com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45) > ~[guava-27.0-jre.jar:?] > at com.google.common.collect.Iterables$5.forEach(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412) > ~[cassandra-4.0.0.jar:4.0.0] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118) > [cassandra-4.0.0.jar:4.0.0] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > [?:?] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > [netty-all-4.1.37.Final.jar:4.1.37.Final] > at java.lang.Thread.run(Thread.java:834) [?:?] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16057) Should update in-jvm dtest to expose stdout and stderr for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-16057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194461#comment-17194461 ] Yifan Cai commented on CASSANDRA-16057: --- Thanks David for the review. Updated the both PRs to address your comments. > Should update in-jvm dtest to expose stdout and stderr for nodetool > --- > > Key: CASSANDRA-16057 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16057 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: David Capwell >Assignee: Yifan Cai >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > Many nodetool commands output to stdout or stderr so running nodetool using > in-jvm dtest should expose that to tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[ https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194454#comment-17194454 ] David Capwell commented on CASSANDRA-15949: --- allExisting sounds better in this case, but if what you mentioned is true then we may have other race condition bugs (a lot of places use Keyspace.open) where a dropped keyspace comes back to life, which would impact metrics and would cause the cached Keyspace to have incorrect meta (org.apache.cassandra.schema.Schema#loadNew doesn't update meta)... > NPE thrown while updating speculative execution time if table is removed > during task execution > -- > > Key: CASSANDRA-15949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15949 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > CASSANDRA-14338 fixed the scheduling the speculation retry threshold > calculation, but if the task happens to be scheduled while a table is being > dropped, it triggers an NPE. > ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1] > org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread > Thread[OptionalTasks:1,5,main] > java.lang.NullPointerException: null > at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.(Keyspace.java:346) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99) > ~[cassandra-4.0.0.jar:4.0.0] > at > com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45) > ~[guava-27.0-jre.jar:?] > at com.google.common.collect.Iterables$5.forEach(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412) > ~[cassandra-4.0.0.jar:4.0.0] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118) > [cassandra-4.0.0.jar:4.0.0] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > [?:?] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > [netty-all-4.1.37.Final.jar:4.1.37.Final] > at java.lang.Thread.run(Thread.java:834) [?:?] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[ https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194401#comment-17194401 ] Caleb Rackliffe commented on CASSANDRA-15949: - [~jmeredithco] I've taken both the testability ideas from [~dcapwell] and the "only run the update task on existing keyspaces" approach and worked them into the patch, which is now [running through|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-15949] the tests again. Let me know what you think... > NPE thrown while updating speculative execution time if table is removed > during task execution > -- > > Key: CASSANDRA-15949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15949 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > CASSANDRA-14338 fixed the scheduling the speculation retry threshold > calculation, but if the task happens to be scheduled while a table is being > dropped, it triggers an NPE. > ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1] > org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread > Thread[OptionalTasks:1,5,main] > java.lang.NullPointerException: null > at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.(Keyspace.java:346) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99) > ~[cassandra-4.0.0.jar:4.0.0] > at > com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45) > ~[guava-27.0-jre.jar:?] > at com.google.common.collect.Iterables$5.forEach(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412) > ~[cassandra-4.0.0.jar:4.0.0] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118) > [cassandra-4.0.0.jar:4.0.0] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > [?:?] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > [netty-all-4.1.37.Final.jar:4.1.37.Final] > at java.lang.Thread.run(Thread.java:834) [?:?] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14801) calculatePendingRanges no longer safe for multiple adjacent range movements
[
https://issues.apache.org/jira/browse/CASSANDRA-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14801:
Reviewers: Marcus Eriksson, Sam Tunnicliffe (was: Blake Eggleston, Sam
Tunnicliffe)
> calculatePendingRanges no longer safe for multiple adjacent range movements
> ---
>
> Key: CASSANDRA-14801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14801
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict Elliott Smith
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Correctness depended upon the narrowing to a {{Set}},
> which we no longer do - we maintain a collection of all {{Replica}}. Our
> {{RangesAtEndpoint}} collection built by {{getPendingRanges}} can as a result
> contain the same endpoint multiple times; and our {{EndpointsForToken}}
> obtained by {{TokenMetadata.pendingEndpointsFor}} may fail to be constructed,
> resulting in cluster-wide failures for writes to the affected token ranges
> for the duration of the range movement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[
https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194283#comment-17194283
]
Jon Meredith commented on CASSANDRA-15949:
--
I like the `allExisting()` approach and agree updating thresholds in doomed CFS
is harmless as long as there aren't issues relating to them being shutdown (the
table metadata being invalid). I'm not sure where the best point to actually
iterate-over-metadata-of-all-loaded-CFS-without-loading-ever with the
{{updateSpeculationThreshold function}} which is what we really want to do.
It's also not the end of the world to miss it as a keyspace is loading as it
will be updated next time (as long as this doesn't crash updating of course).
> NPE thrown while updating speculative execution time if table is removed
> during task execution
> --
>
> Key: CASSANDRA-15949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15949
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jon Meredith
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CASSANDRA-14338 fixed the scheduling the speculation retry threshold
> calculation, but if the task happens to be scheduled while a table is being
> dropped, it triggers an NPE.
> ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1]
> org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread
> Thread[OptionalTasks:1,5,main]
> java.lang.NullPointerException: null
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:346)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102)
> ~[cassandra-4.0.0.jar:4.0.0]
> at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99)
> ~[cassandra-4.0.0.jar:4.0.0]
> at
> com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704)
> ~[guava-27.0-jre.jar:?]
> at
> com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45)
> ~[guava-27.0-jre.jar:?]
> at com.google.common.collect.Iterables$5.forEach(Iterables.java:704)
> ~[guava-27.0-jre.jar:?]
> at
> org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412)
> ~[cassandra-4.0.0.jar:4.0.0]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> [cassandra-4.0.0.jar:4.0.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.37.Final.jar:4.1.37.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194248#comment-17194248
]
Benjamin Lerer commented on CASSANDRA-13935:
Thanks [~adelapena]. It is a valid point.
[~stefan.miklosovic] could you add a test for that in {{UFJavaTest}}?
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-13935:
--
Status: Ready to Commit (was: Review In Progress)
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194241#comment-17194241
]
Andres de la Peña commented on CASSANDRA-13935:
---
[~stefan.miklosovic] [~blerer] Changes look good to me too, +1. The only thing
to mention is that, if I'm right, for UDF/UDA in trunk we don't seem to have
any call passing {{true}} to the new {{ifNotExists}} argument in
{{toCqlString}}, nor even in tests. I don't think that's a problem, given how
simple the change is.
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194148#comment-17194148
]
Tibor Repasi commented on CASSANDRA-16091:
--
As a work around, it seems to be safe to disable thrift after a node has
started up.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
