[jira] [Commented] (CASSANDRA-8675) COPY TO/FROM broken for newline characters

[Christophe (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964228#comment-15964228
 ] 

Christophe commented on CASSANDRA-8675:
---

This COPY FROM issue should be considered a real bug.

If someone runs COPY TO followed by COPY FROM, it is reasonable to expect that 
the data loaded should exactly matched the data extracted. But because if this 
issue, that's not the case when the original data contains string with escaped 
characters.

> 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.3.15#6346)

[jira] [Created] (CASSANDRA-9744) unrealistic pending compactions displayed

[Christophe (JIRA)]

Christophe created CASSANDRA-9744:
-

 Summary: unrealistic pending compactions displayed
 Key: CASSANDRA-9744
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9744
 Project: Cassandra
  Issue Type: Bug
Reporter: Christophe
 Attachments: compact.png

Hi there,

I am on 2.1.7. I am using DateTieredCompactionStrategy with the following 
parameters:
min_threshold 16
max_threshold 16
base_time_seconds 300
max_stable_age_days 0.05

Apart from that, nothing exotic. I dump an sstable of about 18M every 12 sec I 
would say.

Maybe 1 hour after creating my cluster, I can see that:
1. the number of SSTables has constantly been below 60.
2. Most of the time, I have between 1 and 4 pending compaction.
3. I occasionaly have a large number of pending compactions (30-40) for a short 
period of time (a few min)
4. I witness on 1 node 1610 pending compaction, on another node 367 pending 
compaction, for a short period of time (a few min)

Item 4 makes me thing there is a bug as I don't see how I can have that many 
pending compaction with less than 50 sstable.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)