[jira] [Commented] (CASSANDRA-8675) COPY TO/FROM broken for newline characters
[
https://issues.apache.org/jira/browse/CASSANDRA-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16283430#comment-16283430
]
Jaroslav Kamenik commented on CASSANDRA-8675:
-
Hi guys, could you please look at this bug? COPY FROM/TO is now unusable.
> COPY TO/FROM broken for newline characters
> --
>
> Key: CASSANDRA-8675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8675
> Project: Cassandra
> Issue Type: Bug
> Environment: [cqlsh 5.0.1 | Cassandra 2.1.2 | CQL spec 3.2.0 | Native
> protocol v3]
> Ubuntu 14.04 64-bit
>Reporter: Lex Lythius
> Labels: cqlsh
> Fix For: 2.1.3
>
> Attachments: copytest.csv
>
>
> Exporting/importing does not preserve contents when texts containing newline
> (and possibly other) characters are involved:
> {code:sql}
> cqlsh:test> create table if not exists copytest (id int primary key, t text);
> cqlsh:test> insert into copytest (id, t) values (1, 'This has a newline
> ... character');
> cqlsh:test> insert into copytest (id, t) values (2, 'This has a quote "
> character');
> cqlsh:test> insert into copytest (id, t) values (3, 'This has a fake tab \t
> character (typed backslash, t)');
> cqlsh:test> select * from copytest;
> id | t
> +-
> 1 | This has a newline\ncharacter
> 2 |This has a quote " character
> 3 | This has a fake tab \t character (entered slash-t text)
> (3 rows)
> cqlsh:test> copy copytest to '/tmp/copytest.csv';
> 3 rows exported in 0.034 seconds.
> cqlsh:test> copy copytest from '/tmp/copytest.csv';
> 3 rows imported in 0.005 seconds.
> cqlsh:test> select * from copytest;
> id | t
> +---
> 1 | This has a newlinencharacter
> 2 | This has a quote " character
> 3 | This has a fake tab \t character (typed backslash, t)
> (3 rows)
> {code}
> I tried replacing \n in the CSV file with \\n, which just expands to \n in
> the table; and with an actual newline character, which fails with error since
> it prematurely terminates the record.
> It seems backslashes are only used to take the following character as a
> literal
> Until this is fixed, what would be the best way to refactor an old table with
> a new, incompatible structure maintaining its content and name, since we
> can't rename tables?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11726) IndexOutOfBoundsException when selecting (distinct) row ids from counter table.
[
https://issues.apache.org/jira/browse/CASSANDRA-11726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaroslav Kamenik updated CASSANDRA-11726:
-
Reproduced In: 3.7, 3.5 (was: 3.5)
> IndexOutOfBoundsException when selecting (distinct) row ids from counter
> table.
> ---
>
> Key: CASSANDRA-11726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11726
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 3.5, cluster of 4 nodes.
>Reporter: Jaroslav Kamenik
>
> I have simple table containing counters:
> {code}
> CREATE TABLE tablename (
> object_id ascii,
> counter_id ascii,
> count counter,
> PRIMARY KEY (object_id, counter_id)
> ) WITH CLUSTERING ORDER BY (counter_id ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> Counters are often inc/decreased, whole rows are queried, deleted sometimes.
> After some time I tried to query all object_ids, but it failed with:
> {code}
> cqlsh:woc> consistency quorum;
> cqlsh:woc> select object_id from tablename;
> ServerError: message="java.lang.IndexOutOfBoundsException">
> {code}
> select * from ..., select where .., updates works well..
> With consistency one it works sometimes, so it seems something is broken at
> one server, but I tried to repair table there and it did not help.
> Whole exception from server log:
> {code}
> java.lang.IndexOutOfBoundsException: null
> at java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_73]
> at java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314)
> ~[na:1.8.0_73]
> at
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:141)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext.access$100(CounterContext.java:76)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext$ContextState.(CounterContext.java:758)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext$ContextState.wrap(CounterContext.java:765)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext.merge(CounterContext.java:271)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.Conflicts.mergeCounterValues(Conflicts.java:76)
> ~[apache-cassandra-3.5.jar:3.5]
> at org.apache.cassandra.db.rows.Cells.reconcile(Cells.java:143)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:591)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:549)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:217)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[apache-cassandra-3.5.jar:3.5]
> at org.apache.cassandra.db.rows.Row$Merger.merge(Row.java:526)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator$MergeReducer.getReduced(UnfilteredRowIterators.java:473)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator$MergeReducer.getReduced(UnfilteredRowIterators.java:437)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:217)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[apache-cassandra-3.5.jar:3.5]
> at
>
[jira] [Commented] (CASSANDRA-11726) IndexOutOfBoundsException when selecting (distinct) row ids from counter table.
[
https://issues.apache.org/jira/browse/CASSANDRA-11726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333430#comment-15333430
]
Jaroslav Kamenik commented on CASSANDRA-11726:
--
Hi,
we have experienced same problem now, at C* 3.7.
It seems there are others with same problem, look at
https://issues.apache.org/jira/browse/CASSANDRA-11812 .
> IndexOutOfBoundsException when selecting (distinct) row ids from counter
> table.
> ---
>
> Key: CASSANDRA-11726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11726
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 3.5, cluster of 4 nodes.
>Reporter: Jaroslav Kamenik
>
> I have simple table containing counters:
> {code}
> CREATE TABLE tablename (
> object_id ascii,
> counter_id ascii,
> count counter,
> PRIMARY KEY (object_id, counter_id)
> ) WITH CLUSTERING ORDER BY (counter_id ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> Counters are often inc/decreased, whole rows are queried, deleted sometimes.
> After some time I tried to query all object_ids, but it failed with:
> {code}
> cqlsh:woc> consistency quorum;
> cqlsh:woc> select object_id from tablename;
> ServerError: message="java.lang.IndexOutOfBoundsException">
> {code}
> select * from ..., select where .., updates works well..
> With consistency one it works sometimes, so it seems something is broken at
> one server, but I tried to repair table there and it did not help.
> Whole exception from server log:
> {code}
> java.lang.IndexOutOfBoundsException: null
> at java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_73]
> at java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314)
> ~[na:1.8.0_73]
> at
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:141)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext.access$100(CounterContext.java:76)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext$ContextState.(CounterContext.java:758)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext$ContextState.wrap(CounterContext.java:765)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext.merge(CounterContext.java:271)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.Conflicts.mergeCounterValues(Conflicts.java:76)
> ~[apache-cassandra-3.5.jar:3.5]
> at org.apache.cassandra.db.rows.Cells.reconcile(Cells.java:143)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:591)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:549)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:217)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[apache-cassandra-3.5.jar:3.5]
> at org.apache.cassandra.db.rows.Row$Merger.merge(Row.java:526)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator$MergeReducer.getReduced(UnfilteredRowIterators.java:473)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator$MergeReducer.getReduced(UnfilteredRowIterators.java:437)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:217)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
>
[jira] [Commented] (CASSANDRA-11812) IndexOutOfBoundsException in CounterContext.headerLength
[
https://issues.apache.org/jira/browse/CASSANDRA-11812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333427#comment-15333427
]
Jaroslav Kamenik commented on CASSANDRA-11812:
--
Hi, it seems we have same problem, I have reported it here:
https://issues.apache.org/jira/browse/CASSANDRA-11726
> IndexOutOfBoundsException in CounterContext.headerLength
>
>
> Key: CASSANDRA-11812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11812
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 14.04 TLS
> Cassandra 3.4
>Reporter: Jeff Evans
> Fix For: 3.x
>
>
> My team is using
> https://github.com/Contrast-Security-OSS/cassandra-migration for schema
> migrations, and it creates a table with a counter to store the schema
> version. We're able to create the table fine in 3.4, but when we run the
> tool on an existing keyspace, the client reports an error from the server.
> The server logs show an IndexOutOfBounds exception related to the counter
> column.
> the library creates a table with name and count:
> {code}
> CREATE TABLE silver.cassandra_migration_version_counts (
> name text PRIMARY KEY,
> count counter
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> then when the library performs a migration, it counts the rows in this table:
> {{SELECT count(\*) FROM silver.cassandra_migration_version_counts;}}
> this query throws the error:
> {code}
> cqlsh:silver> SELECT count(*) FROM silver.cassandra_migration_version_counts;
> ServerError: message="java.lang.IndexOutOfBoundsException">
> {code}
> the client driver debug logs show the query is running with CONSISTENCY ALL
> {code}
> 2016-05-16 18:03:05 [cluster2-nio-worker-3] WARN
> c.d.driver.core.RequestHandler - /172.24.131.52:9042 replied with server
> error (java.lang.IndexOutOfBoundsException), defuncting connection.
> 2016-05-16 18:03:05 [cluster2-nio-worker-3] DEBUG
> com.datastax.driver.core.Host.STATES - Defuncting
> Connection[/172.24.131.52:9042-1, inFlight=0, closed=false] because: An
> unexpected error occurred server side on /172.24.131.52:9042:
> java.lang.IndexOutOfBoundsException
> 2016-05-16 18:03:05 [cluster2-nio-worker-3] DEBUG
> com.datastax.driver.core.Connection - Connection[/172.24.131.52:9042-1,
> inFlight=0, closed=true] closing connection
> 2016-05-16 18:03:05 [cluster2-nio-worker-3] DEBUG
> com.datastax.driver.core.Host.STATES - [/172.24.131.52:9042] preventing new
> connections for the next 1000 ms
> 2016-05-16 18:03:05 [cluster2-nio-worker-3] DEBUG
> com.datastax.driver.core.Host.STATES - [/172.24.131.52:9042]
> Connection[/172.24.131.52:9042-1, inFlight=0, closed=true] failed, remaining
> = 0
> 2016-05-16 18:03:05 [cluster2-nio-worker-3] DEBUG
> c.d.driver.core.RequestHandler - [937744315-1] Doing retry 1 for query SELECT
> count(*) FROM silver.cassandra_migration_version_counts; at consistency ALL
> 2016-05-16 18:03:05 [cluster2-nio-worker-3] DEBUG
> c.d.driver.core.RequestHandler - [937744315-1] Error querying
> /172.24.131.52:9042 : com.datastax.driver.core.exceptions.ServerError: An
> unexpected error occurred server side on /172.24.131.52:9042:
> java.lang.IndexOutOfBoundsException
> {code}
> I can repro the error with this table, but I haven't found a simple repro yet.
> here's the call stack from the server log:
> {code}
> ERROR [SharedPool-Worker-2] 2016-05-16 17:00:39,313 ErrorMessage.java:338 -
> Unexpected exception during request
> java.lang.IndexOutOfBoundsException: null
> at java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_72]
> at java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314)
> ~[na:1.8.0_72]
> at
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:141)
> ~[apache-cassandra-3.4.jar:3.4]
> at
> org.apache.cassandra.db.context.CounterContext.access$100(CounterContext.java:76)
> ~[apache-cassandra-3.4.jar:3.4]
> at
> org.apache.cassandra.db.context.CounterContext$ContextState.(CounterContext.java:758)
> ~[apache-cassandra-3.4.jar:3.4]
> at
>
[jira] [Commented] (CASSANDRA-11805) Row deleted when value updated to null
[
https://issues.apache.org/jira/browse/CASSANDRA-11805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15290568#comment-15290568
]
Jaroslav Kamenik commented on CASSANDRA-11805:
--
Oki, thanx! One more question;) Why are rows created differently by insert and
update? Is it about performance or smth else?
> Row deleted when value updated to null
> --
>
> Key: CASSANDRA-11805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11805
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 3.5, both single node and cluster, C* 3.6 snapshot
> single node
>Reporter: Jaroslav Kamenik
>
> It seems that the behaviour of the value update to null differs when row is
> created by insert or update. When it is inserted the row stays and the value
> is null, when updated the row is deleted.
> Simple example:
> Inserts:
> create table aaa (a ascii, b ascii, c ascii, primary key (a,b));
> insert into aaa (a,b,c) values ('a','b','c');
> insert into aaa (a,b,c) values ('a','c','d');
> insert into aaa (a,b,c) values ('a','d','e');
> select * from aaa;
> a | b | c
> ---+---+---
> a | b | c
> a | c | d
> a | d | e
> update aaa set c = null where a='a' and b='b';
> select * from aaa;
> a | b | c
> ---+---+--
> a | b | null
> a | c |d
> a | d |e
> Updates:
> create table bbb (a ascii, b ascii, c ascii, primary key (a,b));
> update bbb set c = 'c' where a='a' and b='b';
> update bbb set c = 'd' where a='a' and b='c';
> update bbb set c = 'e' where a='a' and b='d';
> select * from bbb;
> a | b | c
> ---+---+---
> a | b | c
> a | c | d
> a | d | e
> update bbb set c = null where a='a' and b='b';
> select * from bbb;
> a | b | c
> ---+---+---
> a | c | d
> a | d | e
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11805) Row deleted when value updated to null
[
https://issues.apache.org/jira/browse/CASSANDRA-11805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286237#comment-15286237
]
Jaroslav Kamenik commented on CASSANDRA-11805:
--
I do not want delete it, I want to update val to null and I do not know now if
it dissapear or not. It seems little, ehm, unexpected, to me:).
So should I always reinsert null in such case?
> Row deleted when value updated to null
> --
>
> Key: CASSANDRA-11805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11805
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 3.5, both single node and cluster, C* 3.6 snapshot
> single node
>Reporter: Jaroslav Kamenik
>
> It seems that the behaviour of the value update to null differs when row is
> created by insert or update. When it is inserted the row stays and the value
> is null, when updated the row is deleted.
> Simple example:
> Inserts:
> create table aaa (a ascii, b ascii, c ascii, primary key (a,b));
> insert into aaa (a,b,c) values ('a','b','c');
> insert into aaa (a,b,c) values ('a','c','d');
> insert into aaa (a,b,c) values ('a','d','e');
> select * from aaa;
> a | b | c
> ---+---+---
> a | b | c
> a | c | d
> a | d | e
> update aaa set c = null where a='a' and b='b';
> select * from aaa;
> a | b | c
> ---+---+--
> a | b | null
> a | c |d
> a | d |e
> Updates:
> create table bbb (a ascii, b ascii, c ascii, primary key (a,b));
> update bbb set c = 'c' where a='a' and b='b';
> update bbb set c = 'd' where a='a' and b='c';
> update bbb set c = 'e' where a='a' and b='d';
> select * from bbb;
> a | b | c
> ---+---+---
> a | b | c
> a | c | d
> a | d | e
> update bbb set c = null where a='a' and b='b';
> select * from bbb;
> a | b | c
> ---+---+---
> a | c | d
> a | d | e
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11805) Row deleted when value updated to null
[
https://issues.apache.org/jira/browse/CASSANDRA-11805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286199#comment-15286199
]
Jaroslav Kamenik commented on CASSANDRA-11805:
--
Expected? It, among others, means that without knowledge of table history I
can't say what query will do.
Btw doc says:
"Note that unlike in SQL, UPDATE does not check the prior existence of the row
by default (except through the use of , see below): the row is
created if none existed before, and updated otherwise. Furthermore, there is no
mean to know which of creation or update happened."
> Row deleted when value updated to null
> --
>
> Key: CASSANDRA-11805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11805
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 3.5, both single node and cluster, C* 3.6 snapshot
> single node
>Reporter: Jaroslav Kamenik
>
> It seems that the behaviour of the value update to null differs when row is
> created by insert or update. When it is inserted the row stays and the value
> is null, when updated the row is deleted.
> Simple example:
> Inserts:
> create table aaa (a ascii, b ascii, c ascii, primary key (a,b));
> insert into aaa (a,b,c) values ('a','b','c');
> insert into aaa (a,b,c) values ('a','c','d');
> insert into aaa (a,b,c) values ('a','d','e');
> select * from aaa;
> a | b | c
> ---+---+---
> a | b | c
> a | c | d
> a | d | e
> update aaa set c = null where a='a' and b='b';
> select * from aaa;
> a | b | c
> ---+---+--
> a | b | null
> a | c |d
> a | d |e
> Updates:
> create table bbb (a ascii, b ascii, c ascii, primary key (a,b));
> update bbb set c = 'c' where a='a' and b='b';
> update bbb set c = 'd' where a='a' and b='c';
> update bbb set c = 'e' where a='a' and b='d';
> select * from bbb;
> a | b | c
> ---+---+---
> a | b | c
> a | c | d
> a | d | e
> update bbb set c = null where a='a' and b='b';
> select * from bbb;
> a | b | c
> ---+---+---
> a | c | d
> a | d | e
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11805) Row deleted when value updated to null
[
https://issues.apache.org/jira/browse/CASSANDRA-11805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaroslav Kamenik updated CASSANDRA-11805:
-
Environment: C* 3.5, both single node and cluster, C* 3.6 snapshot single
node (was: C* 3.5, both single node and cluster)
Reproduced In: 3.5, 3.6
> Row deleted when value updated to null
> --
>
> Key: CASSANDRA-11805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11805
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 3.5, both single node and cluster, C* 3.6 snapshot
> single node
>Reporter: Jaroslav Kamenik
>Priority: Critical
>
> It seems that the behaviour of the value update to null differs when row is
> created by insert or update. When it is inserted the row stays and the value
> is null, when updated the row is deleted.
> Simple example:
> Inserts:
> create table aaa (a ascii, b ascii, c ascii, primary key (a,b));
> insert into aaa (a,b,c) values ('a','b','c');
> insert into aaa (a,b,c) values ('a','c','d');
> insert into aaa (a,b,c) values ('a','d','e');
> select * from aaa;
> a | b | c
> ---+---+---
> a | b | c
> a | c | d
> a | d | e
> update aaa set c = null where a='a' and b='b';
> select * from aaa;
> a | b | c
> ---+---+--
> a | b | null
> a | c |d
> a | d |e
> Updates:
> create table bbb (a ascii, b ascii, c ascii, primary key (a,b));
> update bbb set c = 'c' where a='a' and b='b';
> update bbb set c = 'd' where a='a' and b='c';
> update bbb set c = 'e' where a='a' and b='d';
> select * from bbb;
> a | b | c
> ---+---+---
> a | b | c
> a | c | d
> a | d | e
> update bbb set c = null where a='a' and b='b';
> select * from bbb;
> a | b | c
> ---+---+---
> a | c | d
> a | d | e
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11805) Row deleted when value updated to null
Jaroslav Kamenik created CASSANDRA-11805:
Summary: Row deleted when value updated to null
Key: CASSANDRA-11805
URL: https://issues.apache.org/jira/browse/CASSANDRA-11805
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: C* 3.5, both single node and cluster
Reporter: Jaroslav Kamenik
Priority: Critical
It seems that the behaviour of the value update to null differs when row is
created by insert or update. When it is inserted the row stays and the value is
null, when updated the row is deleted.
Simple example:
Inserts:
create table aaa (a ascii, b ascii, c ascii, primary key (a,b));
insert into aaa (a,b,c) values ('a','b','c');
insert into aaa (a,b,c) values ('a','c','d');
insert into aaa (a,b,c) values ('a','d','e');
select * from aaa;
a | b | c
---+---+---
a | b | c
a | c | d
a | d | e
update aaa set c = null where a='a' and b='b';
select * from aaa;
a | b | c
---+---+--
a | b | null
a | c |d
a | d |e
Updates:
create table bbb (a ascii, b ascii, c ascii, primary key (a,b));
update bbb set c = 'c' where a='a' and b='b';
update bbb set c = 'd' where a='a' and b='c';
update bbb set c = 'e' where a='a' and b='d';
select * from bbb;
a | b | c
---+---+---
a | b | c
a | c | d
a | d | e
update bbb set c = null where a='a' and b='b';
select * from bbb;
a | b | c
---+---+---
a | c | d
a | d | e
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11726) IndexOutOfBoundsException when selecting (distinct) row ids from counter table.
[
https://issues.apache.org/jira/browse/CASSANDRA-11726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276003#comment-15276003
]
Jaroslav Kamenik commented on CASSANDRA-11726:
--
Hi,
thank you for the advice, unfortunately it did not help:( .
> IndexOutOfBoundsException when selecting (distinct) row ids from counter
> table.
> ---
>
> Key: CASSANDRA-11726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11726
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 3.5, cluster of 4 nodes.
>Reporter: Jaroslav Kamenik
>
> I have simple table containing counters:
> CREATE TABLE tablename (
> object_id ascii,
> counter_id ascii,
> count counter,
> PRIMARY KEY (object_id, counter_id)
> ) WITH CLUSTERING ORDER BY (counter_id ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> Counters are often inc/decreased, whole rows are queried, deleted sometimes.
> After some time I tried to query all object_ids, but it failed with:
> cqlsh:woc> consistency quorum;
> cqlsh:woc> select object_id from tablename;
> ServerError: message="java.lang.IndexOutOfBoundsException">
> select * from ..., select where .., updates works well..
> With consistency one it works sometimes, so it seems something is broken at
> one server, but I tried to repair table there and it did not help.
> Whole exception from server log:
> java.lang.IndexOutOfBoundsException: null
> at java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_73]
> at java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314)
> ~[na:1.8.0_73]
> at
> org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:141)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext.access$100(CounterContext.java:76)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext$ContextState.(CounterContext.java:758)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext$ContextState.wrap(CounterContext.java:765)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.context.CounterContext.merge(CounterContext.java:271)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.Conflicts.mergeCounterValues(Conflicts.java:76)
> ~[apache-cassandra-3.5.jar:3.5]
> at org.apache.cassandra.db.rows.Cells.reconcile(Cells.java:143)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:591)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:549)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:217)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[apache-cassandra-3.5.jar:3.5]
> at org.apache.cassandra.db.rows.Row$Merger.merge(Row.java:526)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator$MergeReducer.getReduced(UnfilteredRowIterators.java:473)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator$MergeReducer.getReduced(UnfilteredRowIterators.java:437)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:217)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
> ~[apache-cassandra-3.5.jar:3.5]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[apache-cassandra-3.5.jar:3.5]
> at
>
[jira] [Created] (CASSANDRA-11726) IndexOutOfBoundsException when selecting (distinct) row ids from counter table.
Jaroslav Kamenik created CASSANDRA-11726:
Summary: IndexOutOfBoundsException when selecting (distinct) row
ids from counter table.
Key: CASSANDRA-11726
URL: https://issues.apache.org/jira/browse/CASSANDRA-11726
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: C* 3.5, cluster of 4 nodes.
Reporter: Jaroslav Kamenik
I have simple table containing counters:
CREATE TABLE tablename (
object_id ascii,
counter_id ascii,
count counter,
PRIMARY KEY (object_id, counter_id)
) WITH CLUSTERING ORDER BY (counter_id ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'enabled': 'false'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
Counters are often inc/decreased, whole rows are queried, deleted sometimes.
After some time I tried to query all object_ids, but it failed with:
cqlsh:woc> consistency quorum;
cqlsh:woc> select object_id from tablename;
ServerError:
select * from ..., select where .., updates works well..
With consistency one it works sometimes, so it seems something is broken at one
server, but I tried to repair table there and it did not help.
Whole exception from server log:
java.lang.IndexOutOfBoundsException: null
at java.nio.Buffer.checkIndex(Buffer.java:546) ~[na:1.8.0_73]
at java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:314)
~[na:1.8.0_73]
at
org.apache.cassandra.db.context.CounterContext.headerLength(CounterContext.java:141)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.context.CounterContext.access$100(CounterContext.java:76)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.context.CounterContext$ContextState.(CounterContext.java:758)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.context.CounterContext$ContextState.wrap(CounterContext.java:765)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.context.CounterContext.merge(CounterContext.java:271)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.Conflicts.mergeCounterValues(Conflicts.java:76)
~[apache-cassandra-3.5.jar:3.5]
at org.apache.cassandra.db.rows.Cells.reconcile(Cells.java:143)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:591)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.rows.Row$Merger$ColumnDataReducer.getReduced(Row.java:549)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:217)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
~[apache-cassandra-3.5.jar:3.5]
at org.apache.cassandra.db.rows.Row$Merger.merge(Row.java:526)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator$MergeReducer.getReduced(UnfilteredRowIterators.java:473)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator$MergeReducer.getReduced(UnfilteredRowIterators.java:437)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:217)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:156)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:419)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:279)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
~[apache-cassandra-3.5.jar:3.5]
at
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:112)
~[apache-cassandra-3.5.jar:3.5]
at
[jira] [Created] (CASSANDRA-11582) Slow table creation
Jaroslav Kamenik created CASSANDRA-11582: Summary: Slow table creation Key: CASSANDRA-11582 URL: https://issues.apache.org/jira/browse/CASSANDRA-11582 Project: Cassandra Issue Type: Bug Components: Core Environment: C* 3.5 OpenSUSE 42.1 JDK 1.8u66 Reporter: Jaroslav Kamenik In last versions of Cassandra we experienced much slower creation of tables. It happens even at single PC, where there is no need to do broadcast schema change etc. It works well, but it is little annoying to wait when you have to recreate lots of tables... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11102) Data lost during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-11102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15136743#comment-15136743
]
Jaroslav Kamenik commented on CASSANDRA-11102:
--
Hi guys,
we deployed 3.3-snapshot to our test cluster last week. Test case from this bug
report was ok, but after 5 days compaction cleared part of one table again. It
looks like some files are still there and some dissapeared during compaction
(nodetool compactionhistory shows bytes read but 0 written). Before
upgrade to 3.3 it was clean 3.2.1 instalation, no old sstables and so. It seems
deletion happens 10 days (default gc_grace) after initial instalation.
> Data lost during compaction
> ---
>
> Key: CASSANDRA-11102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11102
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: Cassandra 3.2.1 (single node, 5 node cluster)
> JDK 8
>Reporter: Jaroslav Kamenik
>Assignee: Sylvain Lebresne
>Priority: Blocker
> Fix For: 3.0.3, 3.3
>
>
> We have experienced data loses in some tables during few weeks since update
> to cassandra 3.0. I thing I successfully found test case now.
> Step one - test table:
> CREATE TABLE aaa (
> r int,
> c1 int,
> c2 ascii,
> PRIMARY KEY (r, c1, c2));
> Step two - run few queries:
> insert into aaa (r, c1, c2) values (1,2,'A');
> delete from aaa where r=1 and c1=2 and c2='B';
> insert into aaa (r, c1, c2) values (2,3,'A');
> delete from aaa where r=2 and c1=3 and c2='B';
> insert into aaa (r, c1, c2) values (3,4,'A');
> delete from aaa where r=3 and c1=4 and c2='B';
> insert into aaa (r, c1, c2) values (4,5,'A');
> delete from aaa where r=4 and c1=5 and c2='B';
> It creates 4 rows (select count says 4) and 4 tombstones.
> Step 3 - Restart Cassandra
> You will see new files written into C* data folder. I tried sstable-tools to
> print table structure, it shows 4 rows, data and tombstones are there.
> Step 4 - set GC grace to 1 to force tombstone removing during compaction.
> alter table aaa with GC_GRACE_SECONDS = 1;
> Step 5 - Compact tables
> ./nodetool compact
> aaa files dissapeares during compaction.
> select count(*) says 0
> compaction history says
> ... aaa 2016-02-01T14:24:01.433 329 0 {}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11102) Data lost during compaction
Jaroslav Kamenik created CASSANDRA-11102:
Summary: Data lost during compaction
Key: CASSANDRA-11102
URL: https://issues.apache.org/jira/browse/CASSANDRA-11102
Project: Cassandra
Issue Type: Bug
Components: Compaction
Environment: Cassandra 3.2.1 (single node, 5 node cluster)
JDK 8
Reporter: Jaroslav Kamenik
Priority: Blocker
We have experienced data loses in some tables during few weeks since update to
cassandra 3.0. I thing I successfully found test case now.
Step one - test table:
CREATE TABLE aaa (
r int,
c1 int,
c2 ascii,
PRIMARY KEY (r, c1, c2));
Step two - run few queries:
insert into aaa (r, c1, c2) values (1,2,'A');
delete from aaa where r=1 and c1=2 and c2='B';
insert into aaa (r, c1, c2) values (2,3,'A');
delete from aaa where r=2 and c1=3 and c2='B';
insert into aaa (r, c1, c2) values (3,4,'A');
delete from aaa where r=3 and c1=4 and c2='B';
insert into aaa (r, c1, c2) values (4,5,'A');
delete from aaa where r=4 and c1=5 and c2='B';
It creates 4 rows (select count says 4) and 4 tombstones.
Step 3 - Restart Cassandra
You will see new files written into C* data folder. I tried sstable-tools to
print table structure, it shows 4 rows, data and tombstones are there.
Step 4 - set GC grace to 1 to force tombstone removing during compaction.
alter table aaa with GC_GRACE_SECONDS = 1;
Step 5 - Compact tables
./nodetool compact
aaa files dissapeares during compaction.
select count(*) says 0
compaction history says
... aaa 2016-02-01T14:24:01.433 329 0 {}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11102) Data lost during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-11102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126476#comment-15126476
]
Jaroslav Kamenik commented on CASSANDRA-11102:
--
Another case:
CREATE TABLE bbb (
r int,
c int,
PRIMARY KEY (r, c));
insert into bbb (r, c) values (1, 2);
... pause
delete from bbb where r=1 and c=2;
insert into bbb (r, c) values (2, 3);
... pause
delete from bbb where r=2 and c=3;
insert into bbb (r, c) values (1, 2);
... pause
delete from bbb where r=1 and c=2;
insert into bbb (r, c) values (2, 3);
... pause
delete from bbb where r=2 and c=3;
insert into bbb (r, c) values (1, 2);
select * from bbb;
r | c
---+---
1 | 2
alter table bbb with GC_GRACE_SECONDS = 1;
restart
compact
table is empty...
> Data lost during compaction
> ---
>
> Key: CASSANDRA-11102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11102
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: Cassandra 3.2.1 (single node, 5 node cluster)
> JDK 8
>Reporter: Jaroslav Kamenik
>Assignee: Marcus Eriksson
>Priority: Blocker
>
> We have experienced data loses in some tables during few weeks since update
> to cassandra 3.0. I thing I successfully found test case now.
> Step one - test table:
> CREATE TABLE aaa (
> r int,
> c1 int,
> c2 ascii,
> PRIMARY KEY (r, c1, c2));
> Step two - run few queries:
> insert into aaa (r, c1, c2) values (1,2,'A');
> delete from aaa where r=1 and c1=2 and c2='B';
> insert into aaa (r, c1, c2) values (2,3,'A');
> delete from aaa where r=2 and c1=3 and c2='B';
> insert into aaa (r, c1, c2) values (3,4,'A');
> delete from aaa where r=3 and c1=4 and c2='B';
> insert into aaa (r, c1, c2) values (4,5,'A');
> delete from aaa where r=4 and c1=5 and c2='B';
> It creates 4 rows (select count says 4) and 4 tombstones.
> Step 3 - Restart Cassandra
> You will see new files written into C* data folder. I tried sstable-tools to
> print table structure, it shows 4 rows, data and tombstones are there.
> Step 4 - set GC grace to 1 to force tombstone removing during compaction.
> alter table aaa with GC_GRACE_SECONDS = 1;
> Step 5 - Compact tables
> ./nodetool compact
> aaa files dissapeares during compaction.
> select count(*) says 0
> compaction history says
> ... aaa 2016-02-01T14:24:01.433 329 0 {}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10711) NoSuchElementException when executing empty batch.
Jaroslav Kamenik created CASSANDRA-10711: Summary: NoSuchElementException when executing empty batch. Key: CASSANDRA-10711 URL: https://issues.apache.org/jira/browse/CASSANDRA-10711 Project: Cassandra Issue Type: Bug Environment: Cassandra 3.0, OSS 42.1 Reporter: Jaroslav Kamenik After upgrade to C* 3.0, it fails when executes empty batch: java.util.NoSuchElementException: null at java.util.ArrayList$Itr.next(ArrayList.java:854) ~[na:1.8.0_60] at org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:737) ~[apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.cql3.statements.BatchStatement.executeWithoutConditions(BatchStatement.java:356) ~[apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:337) ~[apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:323) ~[apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.cql3.QueryProcessor.processBatch(QueryProcessor.java:490) ~[apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.cql3.QueryProcessor.processBatch(QueryProcessor.java:480) ~[apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.transport.messages.BatchMessage.execute(BatchMessage.java:217) ~[apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507) [apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401) [apache-cassandra-3.0.0.jar:3.0.0] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) [netty-all-4.0.23.Final.jar:4.0.23.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_60] at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) [apache-cassandra-3.0.0.jar:3.0.0] at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-3.0.0.jar:3.0.0] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950281#comment-14950281 ] Jaroslav Kamenik commented on CASSANDRA-9960: - We have tried and experienced it at more PCs, openSUSE 13.2, Win7, Fedora 22. > UDTs still visible after drop/recreate keyspace > --- > > Key: CASSANDRA-9960 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jaroslav Kamenik >Assignee: Robert Stupp >Priority: Critical > Fix For: 2.2.x > > Attachments: CrashTest.java > > > When deploying my app from the scratch I run sequence - drop keyspaces, > create keyspaces, create UDTs, create tables, generate lots of data... After > few cycles, randomly, cassandra ends in state, where I cannot see anything in > table system.schema_usertypes, when I select all rows, but queries with > specified keyspace_name and type_name return old values. Usually it helps to > restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14681387#comment-14681387 ] Jaroslav Kamenik commented on CASSANDRA-9960: - I have fresh instalation, changed paths and cluster name only. Btw it seems dropping and creating keyspace/tables is enough to break it. I run it in loop during night and it failed after 4 hours (~ few hundreds iterations). UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Assignee: Robert Stupp Priority: Critical Fix For: 2.2.x When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14681612#comment-14681612 ] Jaroslav Kamenik commented on CASSANDRA-9960: - I have attached simple unit test, it crashed too, took ~350 iterations. UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Assignee: Robert Stupp Priority: Critical Fix For: 2.2.x Attachments: CrashTest.java When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Kamenik updated CASSANDRA-9960: Attachment: CrashTest.java UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Assignee: Robert Stupp Priority: Critical Fix For: 2.2.x Attachments: CrashTest.java When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14681612#comment-14681612 ] Jaroslav Kamenik edited comment on CASSANDRA-9960 at 8/11/15 1:49 PM: -- I have attached simple unit test, it crashed too, took ~350 iterations. I have asked my colegue to try it at his W7 PC, he has absolutely default C* 2.2 and the same problem. was (Author: shinigami): I have attached simple unit test, it crashed too, took ~350 iterations. UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Assignee: Robert Stupp Priority: Critical Fix For: 2.2.x Attachments: CrashTest.java When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679795#comment-14679795 ] Jaroslav Kamenik commented on CASSANDRA-9960: - I had ntpd running, but I switched it off and have same problem after few iterations. UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Assignee: Robert Stupp Priority: Critical Fix For: 2.2.x When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661857#comment-14661857
]
Jaroslav Kamenik commented on CASSANDRA-9960:
-
New info - it seems, that old type data are resurrected after creation few new
types in empty keyspace. Now I have it in those strange state, example from
cqlsh:
cqlsh drop keyspace woc;
cqlsh CREATE KEYSPACE woc WITH REPLICATION = {'class': 'SimpleStrategy',
'replication_factor': '1'};
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names | field_types
---+---+-+-
(0 rows)
cqlsh CREATE TYPE IF NOT EXISTS woc.a(aa int);
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names | field_types
---+---+-+-
(0 rows)
cqlsh CREATE TYPE IF NOT EXISTS woc.b(bb int) ;
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names |
field_types
---+---+-+
woc | xxx | ['xxx', 'xxx', 'xxx'] |
['org.apache.cassandra.db.marshal.AsciiType',
'org.apache.cassandra.db.marshal.TimeUUIDType',
'org.apache.cassandra.db.marshal.AsciiType']
UDTs still visible after drop/recreate keyspace
---
Key: CASSANDRA-9960
URL: https://issues.apache.org/jira/browse/CASSANDRA-9960
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Jaroslav Kamenik
Assignee: Robert Stupp
Priority: Critical
Fix For: 2.2.x
When deploying my app from the scratch I run sequence - drop keyspaces,
create keyspaces, create UDTs, create tables, generate lots of data... After
few cycles, randomly, cassandra ends in state, where I cannot see anything in
table system.schema_usertypes, when I select all rows, but queries with
specified keyspace_name and type_name return old values. Usually it helps to
restart C* and old data disapear, sometimes it needs to delete all C* data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661857#comment-14661857
]
Jaroslav Kamenik edited comment on CASSANDRA-9960 at 8/7/15 2:01 PM:
-
New info - it seems, that old type data are resurrected after creation few new
types in empty keyspace. Now I have it in those strange state, example from
cqlsh:
cqlsh drop keyspace woc;
cqlsh CREATE KEYSPACE woc WITH REPLICATION = {'class': 'SimpleStrategy',
'replication_factor': '1'};
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names | field_types
---+---+-+-
(0 rows)
cqlsh CREATE TYPE IF NOT EXISTS woc.a(aa int);
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names | field_types
---+---+-+-
(0 rows)
cqlsh CREATE TYPE IF NOT EXISTS woc.b(bb int) ;
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names |
field_types
---+---+-+
woc | xxx | ['xxx', 'xxx', 'xxx'] |
['org.apache.cassandra.db.marshal.AsciiType',
'org.apache.cassandra.db.marshal.TimeUUIDType',
'org.apache.cassandra.db.marshal.AsciiType']
Can succesfully do this again and again:)
was (Author: shinigami):
New info - it seems, that old type data are resurrected after creation few new
types in empty keyspace. Now I have it in those strange state, example from
cqlsh:
cqlsh drop keyspace woc;
cqlsh CREATE KEYSPACE woc WITH REPLICATION = {'class': 'SimpleStrategy',
'replication_factor': '1'};
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names | field_types
---+---+-+-
(0 rows)
cqlsh CREATE TYPE IF NOT EXISTS woc.a(aa int);
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names | field_types
---+---+-+-
(0 rows)
cqlsh CREATE TYPE IF NOT EXISTS woc.b(bb int) ;
cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND
type_name='xxx';
keyspace_name | type_name | field_names |
field_types
---+---+-+
woc | xxx | ['xxx', 'xxx', 'xxx'] |
['org.apache.cassandra.db.marshal.AsciiType',
'org.apache.cassandra.db.marshal.TimeUUIDType',
'org.apache.cassandra.db.marshal.AsciiType']
UDTs still visible after drop/recreate keyspace
---
Key: CASSANDRA-9960
URL: https://issues.apache.org/jira/browse/CASSANDRA-9960
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Jaroslav Kamenik
Assignee: Robert Stupp
Priority: Critical
Fix For: 2.2.x
When deploying my app from the scratch I run sequence - drop keyspaces,
create keyspaces, create UDTs, create tables, generate lots of data... After
few cycles, randomly, cassandra ends in state, where I cannot see anything in
table system.schema_usertypes, when I select all rows, but queries with
specified keyspace_name and type_name return old values. Usually it helps to
restart C* and old data disapear, sometimes it needs to delete all C* data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661417#comment-14661417 ] Jaroslav Kamenik commented on CASSANDRA-9960: - I am using single local cassandra, one node, no replications, for development, and small virtualized cluster for testing, it has 5 nodes in one DC, NTS with rep factor 3. Experienced problem on both, after move to 2.2. UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Assignee: Robert Stupp Priority: Critical Fix For: 2.2.x When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661624#comment-14661624 ] Jaroslav Kamenik commented on CASSANDRA-9960: - I have changed cluster name and paths to data dirs only. The issue doesnt appear imediatelly, but after some time, few release cycles, sometimes hours, sometimes days.. I have around 30 types and 150 tables and push few GBs of data during release, with hundreds of threads parallely. UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Assignee: Robert Stupp Priority: Critical Fix For: 2.2.x When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661869#comment-14661869 ] Jaroslav Kamenik commented on CASSANDRA-9960: - Tried to restart C* FIRST RESTART cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc'; keyspace_name | type_name | field_names | field_types ---+---+-+--- woc | a | ['aa'] | ['org.apache.cassandra.db.marshal.Int32Type'] woc | b | ['bb'] | ['org.apache.cassandra.db.marshal.Int32Type'] (2 rows) cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND type_name='xxx'; keyspace_name | type_name | field_names | field_types ---+---+-+ woc | xxx | ['xxx', 'xxx', 'xxx'] | ['org.apache.cassandra.db.marshal.AsciiType', 'org.apache.cassandra.db.marshal.TimeUUIDType', 'org.apache.cassandra.db.marshal.AsciiType'] (1 rows) zombie still there.. SECOND RESTART cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc'; keyspace_name | type_name | field_names | field_types ---+---+-+--- woc | a | ['aa'] | ['org.apache.cassandra.db.marshal.Int32Type'] woc | b | ['bb'] | ['org.apache.cassandra.db.marshal.Int32Type'] (2 rows) cqlsh select * FROM system.schema_usertypes WHERE keyspace_name='woc' AND type_name='xxx'; keyspace_name | type_name | field_names | field_types ---+---+-+- (0 rows) Zombie disapeared. UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Assignee: Robert Stupp Priority: Critical Fix For: 2.2.x When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659796#comment-14659796 ] Jaroslav Kamenik commented on CASSANDRA-9960: - I have found this problem using datastax java client. I have used select from system.schema_usertypes to check if I need to create type (i know, there is IF NOT EXIST clause:). Sometimes it said 'type is there', just after drop/create whole keyspace. Drop/create was made before my java app started, so it does not seem to be problem of client caches or so... I checked it in CQLSH (it was started after this problem happened), where select * from system.schema_usertypes returned nothing, but select * FROM system.schema_usertypes WHERE keyspace_name='ks' AND type_name='typename'; returned type definition. It started after the upgrade to C* 2.2. UDTs still visible after drop/recreate keyspace --- Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Priority: Critical When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9960) UDTs still visible after drop/recreate keyspace
Jaroslav Kamenik created CASSANDRA-9960: --- Summary: UDTs still visible after drop/recreate keyspace Key: CASSANDRA-9960 URL: https://issues.apache.org/jira/browse/CASSANDRA-9960 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Priority: Critical When deploying my app from the scratch I run sequence - drop keyspaces, create keyspaces, create UDTs, create tables, generate lots of data... After few cycles, randomly, cassandra ends in state, where I cannot see anything in table system.schema_usertypes, when I select all rows, but queries with specified keyspace_name and type_name return old values. Usually it helps to restart C* and old data disapear, sometimes it needs to delete all C* data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8755) Replace trivial uses of String.replace/replaceAll/split with StringUtils methods
[ https://issues.apache.org/jira/browse/CASSANDRA-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14346616#comment-14346616 ] Jaroslav Kamenik commented on CASSANDRA-8755: - Hi, I have meant simple cases as String zone_parts[] = zone.split(-); String res = input.replaceAll(:, :); where regexp is normal string/even one char, so usage of regexp is overkill. Replace trivial uses of String.replace/replaceAll/split with StringUtils methods Key: CASSANDRA-8755 URL: https://issues.apache.org/jira/browse/CASSANDRA-8755 Project: Cassandra Issue Type: Improvement Reporter: Jaroslav Kamenik Priority: Trivial Labels: lhf There are places in the code where those regex based methods are used with plain, not regexp, strings, so StringUtils alternatives should be faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8755) Replace trivial uses of String.replace/replaceAll/split with StringUtils methods
Jaroslav Kamenik created CASSANDRA-8755: --- Summary: Replace trivial uses of String.replace/replaceAll/split with StringUtils methods Key: CASSANDRA-8755 URL: https://issues.apache.org/jira/browse/CASSANDRA-8755 Project: Cassandra Issue Type: Improvement Reporter: Jaroslav Kamenik Priority: Trivial There are places in the code where those regex based methods are used with plain, not regexp, strings, so StringUtils alternatives should be faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8231) Wrong size of cached prepared statements
Jaroslav Kamenik created CASSANDRA-8231: --- Summary: Wrong size of cached prepared statements Key: CASSANDRA-8231 URL: https://issues.apache.org/jira/browse/CASSANDRA-8231 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik Cassandra counts memory footprint of prepared statements for caching purposes. It seems, that there is problem with some statements, ie SelectStatement. Even simple selects is counted as 100KB object, updates, deletes etc have few hundreds or thousands bytes. Result is that cache - QueryProcessor.preparedStatements - holds just fraction of statements.. I dig a little into the code, and it seems that problem is in jamm in class MemoryMeter. It seems that if instance contains reference to class, it counts size of whole class too. SelectStatement references EnumSet through ResultSet.Metadata and EnumSet holds reference to Enum class... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40
[ https://issues.apache.org/jira/browse/CASSANDRA-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189792#comment-14189792 ] Jaroslav Kamenik commented on CASSANDRA-8209: - I think you just need use the last development release of jdk8 java version 1.8.0_40-ea Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b15, mixed mode) Cassandra crashes when running on OpenJDK8 update 40 Key: CASSANDRA-8209 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik It seems that problem is change made in update 40 - https://bugs.openjdk.java.net/browse/JDK-6642881 result is: java.lang.SecurityException: Cannot make java.lang.Class.classLoader accessible at java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) ~[na:1.8.0_40-ea] at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) ~[na:1.8.0_40-ea] at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) ~[jamm-0.2.6.jar:na] at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) ~[jamm-0.2.6.jar:na] at org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439) [apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335) [apache-cassandra-2.1.1.jar:2.1.1] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) [netty-all-4.0.23.Final.jar:4.0.23.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_40-ea] at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) [apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-2.1.1.jar:2.1.1] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8209) Cassandra crashes when running on OpenJDK8 update 40
[ https://issues.apache.org/jira/browse/CASSANDRA-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190265#comment-14190265 ] Jaroslav Kamenik commented on CASSANDRA-8209: - It is not JDK bug, it is new feature, they changed Class structure. So, you can wait until oracle release 8u40 and everyone who updates will have unusable Cassandra. Or fix it before release... Cassandra crashes when running on OpenJDK8 update 40 Key: CASSANDRA-8209 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik It seems that problem is change made in update 40 - https://bugs.openjdk.java.net/browse/JDK-6642881 result is: java.lang.SecurityException: Cannot make java.lang.Class.classLoader accessible at java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) ~[na:1.8.0_40-ea] at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) ~[na:1.8.0_40-ea] at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) ~[jamm-0.2.6.jar:na] at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) ~[jamm-0.2.6.jar:na] at org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439) [apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335) [apache-cassandra-2.1.1.jar:2.1.1] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) [netty-all-4.0.23.Final.jar:4.0.23.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_40-ea] at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) [apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-2.1.1.jar:2.1.1] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8209) Cassandra crashes when running on JDK8 update 40
Jaroslav Kamenik created CASSANDRA-8209: --- Summary: Cassandra crashes when running on JDK8 update 40 Key: CASSANDRA-8209 URL: https://issues.apache.org/jira/browse/CASSANDRA-8209 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jaroslav Kamenik It seems that problem is change made in update 40 - https://bugs.openjdk.java.net/browse/JDK-6642881 result is: java.lang.SecurityException: Cannot make java.lang.Class.classLoader accessible at java.lang.reflect.AccessibleObject.setAccessible0(AccessibleObject.java:147) ~[na:1.8.0_40-ea] at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:129) ~[na:1.8.0_40-ea] at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:204) ~[jamm-0.2.6.jar:na] at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:158) ~[jamm-0.2.6.jar:na] at org.apache.cassandra.cql3.statements.SelectStatement.measureForPreparedCache(SelectStatement.java:166) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.measure(QueryProcessor.java:546) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:441) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:404) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:388) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77) ~[apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439) [apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335) [apache-cassandra-2.1.1.jar:2.1.1] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) [netty-all-4.0.23.Final.jar:4.0.23.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_40-ea] at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) [apache-cassandra-2.1.1.jar:2.1.1] at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-2.1.1.jar:2.1.1] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40-ea] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-7656) UDT with null/missing attributes
Jaroslav Kamenik created CASSANDRA-7656:
---
Summary: UDT with null/missing attributes
Key: CASSANDRA-7656
URL: https://issues.apache.org/jira/browse/CASSANDRA-7656
Project: Cassandra
Issue Type: Bug
Reporter: Jaroslav Kamenik
I have experienced problem with queriing UDTs stored with some not filled
attributes through new java driver 2.1. I tried to query them in cqlsh too and
it failed. I tried to simulate it again with fresh C* directly in cqlsh and it
seems it has problems in some cases. I have tested it with UDT defined as (a
ascii, b ascii, c ascii, d ascii, e ascii, f ascii, g ascii).
Few observations:
{noformat}
Store {a:'a'} is ok, it returns {a: 'a', b: '', c: '', d: '', e: '', f: '', g:
''}
Store {a:'a', b:'b', c:'c', d:'d', e:'e', f:'f', g:'g'} is ok, returns all
filled.
Store {a:'a', g:'g'} fills a only.
Store {a:'a', b:'b', d:'d', e:'e', f:'f', g:'g'} (missing c) failed on load.
Store {a:'a', f:'f', g:'g'} fills just a.
Store {f:'f',g:'g'} nothing filled
Store {e:'e',f:'f',g:'g'} failed on load.
{noformat}
you can reproduce it with:
{noformat}
./cqlsh
Connected to WOC at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.0-rc4 | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
cqlsh create keyspace testks WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1};
cqlsh use testks;
cqlsh:testks CREATE TYPE IF NOT EXISTS data (a ascii, b ascii, c ascii, d
ascii, e ascii, f ascii, g ascii);
cqlsh:testks CREATE TABLE IF NOT EXISTS bbb (a ascii primary key, b data);
cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a'});
cqlsh:testks select * from bbb;
a | b
---+
a | {a: 'a', b: '', c: '', d: '', e: '', f: '', g: ''}
(1 rows)
cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a', b:'b', c:'c',
d:'d', e:'e', f:'f', g:'g'});
cqlsh:testks select * from bbb;
a | b
---+--
a | {a: 'a', b: 'b', c: 'c', d: 'd', e: 'e', f: 'f', g: 'g'}
(1 rows)
cqlsh insert into testks.bbb (a,b) values ('a', {a:'a', g:'g'});
cqlsh select * from testks.bbb;
a | b
---+
a | {a: 'a', b: '', c: '', d: '', e: '', f: '', g: ''}
(1 rows)
cqlsh:testks insert into testks.bbb (a,b) values ('a', {a:'a', b:'b', d:'d',
e:'e', f:'f', g:'g'});
cqlsh:testks select * from bbb;
Traceback (most recent call last):
File ./cqlsh, line 901, in perform_simple_statement
rows = self.session.execute(statement, trace=self.tracing_enabled)
File
/srv/apache-cassandra-2.1.0-rc4/bin/../lib/cassandra-driver-internal-only-2.1.0b1.post.zip/cassandra-driver-2.1.0b1.post/cassandra/cluster.py,
line 1186, in execute
result = future.result(timeout)
File
/srv/apache-cassandra-2.1.0-rc4/bin/../lib/cassandra-driver-internal-only-2.1.0b1.post.zip/cassandra-driver-2.1.0b1.post/cassandra/cluster.py,
line 2610, in result
raise self._final_exception
error: unpack requires a string argument of length 4
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
