[jira] [Updated] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1, 2.2 and 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroyuki Yamada updated CASSANDRA-12864: Summary: "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1, 2.2 and 3.9 (was: "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 and 2.2) > "commitlog_sync_batch_window_in_ms" parameter is not working correctly in > 2.1, 2.2 and 3.9 > -- > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Hiroyuki Yamada > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1.16, 2.2.8 and 3.9. > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 and 2.2
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroyuki Yamada updated CASSANDRA-12864: Description: "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in the latest versions in 2.1.16, 2.2.8 and 3.9. Here is the way to reproduce the bug. 1. set the following parameters in cassandra.yaml * commitlog_sync: batch * commitlog_sync_batch_window_in_ms: 1 (10s) 2. issue an insert from cqlsh 3. it immediately returns instead of waiting for 10 seconds. Please refer to the communication in the mailing list. http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html was: "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in the latest versions in 2.1 and 2.2. (2.1.16 and 2.2.8 respectively) Here is the way to reproduce the bug. 1. set the following parameters in cassandra.yaml * commitlog_sync: batch * commitlog_sync_batch_window_in_ms: 1 (10s) 2. issue an insert from cqlsh 3. it immediately returns instead of waiting for 10 seconds. Please refer to the communication in the mailing list. http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html > "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 > and 2.2 > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Hiroyuki Yamada > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1.16, 2.2.8 and 3.9. > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 and 2.2
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroyuki Yamada updated CASSANDRA-12864: Component/s: Core > "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 > and 2.2 > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Hiroyuki Yamada > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1 and 2.2. (2.1.16 and 2.2.8 respectively) > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 and 2.2
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroyuki Yamada updated CASSANDRA-12864: Fix Version/s: (was: 2.1.16) (was: 2.2.8) > "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 > and 2.2 > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug >Reporter: Hiroyuki Yamada > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1 and 2.2. (2.1.16 and 2.2.8 respectively) > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 and 2.2
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroyuki Yamada updated CASSANDRA-12864: Summary: "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 and 2.2 (was: "commitlog_sync_batch_window_in_ms" parameter is not working correctly) > "commitlog_sync_batch_window_in_ms" parameter is not working correctly in 2.1 > and 2.2 > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug >Reporter: Hiroyuki Yamada > Fix For: 2.1.16, 2.2.8 > > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1 and 2.2. (2.1.16 and 2.2.8 respectively) > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not working correctly
Hiroyuki Yamada created CASSANDRA-12864: --- Summary: "commitlog_sync_batch_window_in_ms" parameter is not working correctly Key: CASSANDRA-12864 URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 Project: Cassandra Issue Type: Bug Reporter: Hiroyuki Yamada Fix For: 2.2.8, 2.1.16 "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in the latest versions in 2.1 and 2.2. (2.1.16 and 2.2.8 respectively) Here is the way to reproduce the bug. 1. set the following parameters in cassandra.yaml * commitlog_sync: batch * commitlog_sync_batch_window_in_ms: 1 (10s) 2. issue an insert from cqlsh 3. it immediately returns instead of waiting for 10 seconds. Please refer to the communication in the mailing list. http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12838) Extend native protocol flags and add supported versions to the SUPPORTED response
[
https://issues.apache.org/jira/browse/CASSANDRA-12838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15621119#comment-15621119
]
Stefania commented on CASSANDRA-12838:
--
Thank you, I'll ping you on Monday morning to arrange a time.
> Extend native protocol flags and add supported versions to the SUPPORTED
> response
> -
>
> Key: CASSANDRA-12838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12838
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Stefania
>Assignee: Stefania
> Labels: client-impacting
> Fix For: 3.x
>
>
> We already use 7 bits for the flags of the QUERY message, and since they are
> encoded with a fixed size byte, we may be forced to change the structure of
> the message soon, and I'd like to do this in version 5 but without wasting
> bytes on the wire. Therefore, I propose to convert fixed flag's bytes to
> unsigned vints, as defined in CASSANDRA-9499. The only exception would be the
> flags in the frame, which should stay as fixed size.
> Up to 7 bits, vints are encoded the same as bytes are, so no immediate change
> would be required in the drivers, although they should plan to support vint
> flags if supporting version 5. Moving forward, when a new flag is required
> for the QUERY message, and eventually when other flags reach 8 bits in other
> messages too, the flag's bitmaps would be automatically encoded with a size
> that is big enough to accommodate all flags, but no bigger than required. We
> can currently support up to 8 bytes with unsigned vints.
> The downside is that drivers need to implement unsigned vint encoding for
> version 5, but this is already required by CASSANDRA-11873, and will most
> likely be required by CASSANDRA-11622 as well.
> I would also like to add the list of versions to the SUPPORTED message, in
> order to simplify the handshake for drivers that prefer to send an OPTION
> message, rather than rely on receiving an error for an unsupported version in
> the STARTUP message. Said error should also contain the full list of
> supported versions, not just the min and max, for clarity, and because the
> latest version is now a beta version.
> Finally, we currently store versions as integer constants in {{Server.java}},
> and we still have a fair bit of hard-coded numbers in the code, especially in
> tests. I plan to clean this up by introducing a {{ProtocolVersion}} enum.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10855) Use Caffeine (W-TinyLFU) for on-heap caches
[ https://issues.apache.org/jira/browse/CASSANDRA-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15621068#comment-15621068 ] Ben Manes commented on CASSANDRA-10855: --- Released 2.3.4 with JCTools fix. Please revisit. > Use Caffeine (W-TinyLFU) for on-heap caches > --- > > Key: CASSANDRA-10855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10855 > Project: Cassandra > Issue Type: Improvement >Reporter: Ben Manes > Labels: performance > Attachments: CASSANDRA-10855.patch, CASSANDRA-10855.patch > > > Cassandra currently uses > [ConcurrentLinkedHashMap|https://code.google.com/p/concurrentlinkedhashmap] > for performance critical caches (key, counter) and Guava's cache for > non-critical (auth, metrics, security). All of these usages have been > replaced by [Caffeine|https://github.com/ben-manes/caffeine], written by the > author of the previously mentioned libraries. > The primary incentive is to switch from LRU policy to W-TinyLFU, which > provides [near optimal|https://github.com/ben-manes/caffeine/wiki/Efficiency] > hit rates. It performs particularly well in database and search traces, is > scan resistant, and as adds a very small time/space overhead to LRU. > Secondarily, Guava's caches never obtained similar > [performance|https://github.com/ben-manes/caffeine/wiki/Benchmarks] to CLHM > due to some optimizations not being ported over. This change results in > faster reads and not creating garbage as a side-effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12861) example/triggers build fail.
[
https://issues.apache.org/jira/browse/CASSANDRA-12861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasuharu Goto updated CASSANDRA-12861:
--
Status: Patch Available (was: Open)
> example/triggers build fail.
>
>
> Key: CASSANDRA-12861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12861
> Project: Cassandra
> Issue Type: Bug
>Reporter: Yasuharu Goto
>Assignee: Yasuharu Goto
>Priority: Trivial
>
> When I tried to build example/trigger on trunk branch, I found that "ant jar"
> fails with an error like below.
> (Sorry for my language settings for ant. I couldn't find how to change it.
> The error indicated here is a "cannot find symboll" error of
> RowUpdateBuilder).
> {code}
> Buildfile: /Users/yasuharu/git/cassandra/examples/triggers/build.xml
> init:
> [mkdir] Created dir:
> /Users/yasuharu/git/cassandra/examples/triggers/build/classes
> build:
> [javac] Compiling 1 source file to
> /Users/yasuharu/git/cassandra/examples/triggers/build/classes
> [javac] 警告:
> 注釈プロセッサ'org.openjdk.jmh.generators.BenchmarkProcessor'から-source
> '1.8'より小さいソース・バージョン'RELEASE_6'がサポートされています
> [javac]
> /Users/yasuharu/git/cassandra/examples/triggers/src/org/apache/cassandra/triggers/AuditTrigger.java:27:
> エラー: シンボルを見つけられません
> [javac] import org.apache.cassandra.db.RowUpdateBuilder;
> [javac] ^
> [javac] シンボル: クラス RowUpdateBuilder
> [javac] 場所: パッケージ org.apache.cassandra.db
> [javac] エラー1個
> [javac] 警告1個
> BUILD FAILED
> /Users/yasuharu/git/cassandra/examples/triggers/build.xml:45: Compile failed;
> see the compiler error output for details.
> Total time: 1 second
> {code}
> I think the movement of RowUpdateBuilder to test has broken this build.
> https://github.com/apache/cassandra/commit/26838063de6246e3a1e18062114ca92fb81c00cf
> In order to fix this, I moved back RowUpdateBuilder.java to src in my patch.
> https://github.com/apache/cassandra/commit/d133eefe9c5fbebd8d389a9397c3948b8c36bd06
> Could you please review my patch?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12863) cqlsh COPY FROM cannot parse timestamp in partition key if table contains a counter value
[
https://issues.apache.org/jira/browse/CASSANDRA-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-12863:
-
Description:
This sample table:
{code}
CREATE TABLE test (columnname text, day timestamp, israndom boolean,
columnvalue text, counter counter, PRIMARY KEY ((columnname, day, israndom),
columnvalue));
{code}
with this sample data:
{code}
origins|2016-10-01 00:00:00+|False|ACTUAL|6
origins|2016-10-01 00:00:00+|False|ADGMOB|4
origins|2016-10-01 00:00:00+|False|ANONPM|4
origins|2016-10-01 00:00:00+|False|CSRT2L|76
origins|2016-10-01 00:00:00+|False|DIAGOP|18
origins|2016-10-01 00:00:00+|False|E-SOFT|17
origins|2016-10-01 00:00:00+|False|E-TASK|10
{code}
when imported with
{code}
COPY ks.test FROM 'test.csv' WITH DELIMITER = '|';
{code}
will generate a parse error:
{code}
Failed to import 7 rows: ParseError - can't interpret u"'2016-10-01
00:00:00+'" as a date with this format: %Y-%m-%d %H:%M:%S%z, given up
without retries
{code}
The problem is that when a counter value is present, we don't use prepared
statements and so we typically don't convert values unless they are part of the
partition key. We also add quotes for certain types, such as timestamps. The
problem is that we do not remove such quotes before parsing the partition key
values, therefore ending up with a parse error.
> cqlsh COPY FROM cannot parse timestamp in partition key if table contains a
> counter value
> -
>
> Key: CASSANDRA-12863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12863
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> This sample table:
> {code}
> CREATE TABLE test (columnname text, day timestamp, israndom boolean,
> columnvalue text, counter counter, PRIMARY KEY ((columnname, day, israndom),
> columnvalue));
> {code}
> with this sample data:
> {code}
> origins|2016-10-01 00:00:00+|False|ACTUAL|6
> origins|2016-10-01 00:00:00+|False|ADGMOB|4
> origins|2016-10-01 00:00:00+|False|ANONPM|4
> origins|2016-10-01 00:00:00+|False|CSRT2L|76
> origins|2016-10-01 00:00:00+|False|DIAGOP|18
> origins|2016-10-01 00:00:00+|False|E-SOFT|17
> origins|2016-10-01 00:00:00+|False|E-TASK|10
> {code}
> when imported with
> {code}
> COPY ks.test FROM 'test.csv' WITH DELIMITER = '|';
> {code}
> will generate a parse error:
> {code}
> Failed to import 7 rows: ParseError - can't interpret u"'2016-10-01
> 00:00:00+'" as a date with this format: %Y-%m-%d %H:%M:%S%z, given up
> without retries
> {code}
> The problem is that when a counter value is present, we don't use prepared
> statements and so we typically don't convert values unless they are part of
> the partition key. We also add quotes for certain types, such as timestamps.
> The problem is that we do not remove such quotes before parsing the partition
> key values, therefore ending up with a parse error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12863) cqlsh COPY FROM cannot parse timestamp in partition key if table contains a counter value
[
https://issues.apache.org/jira/browse/CASSANDRA-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-12863:
-
Description: (was: This sample table:
{code}
CREATE TABLE test (columnname text, day timestamp, israndom boolean,
columnvalue text, counter counter, PRIMARY KEY ((columnname, day, israndom),
columnvalue));
{code}
with this sample data:
{code}
origins|2016-10-01 00:00:00+|False|ACTUAL|6
origins|2016-10-01 00:00:00+|False|ADGMOB|4
origins|2016-10-01 00:00:00+|False|ANONPM|4
origins|2016-10-01 00:00:00+|False|CSRT2L|76
origins|2016-10-01 00:00:00+|False|DIAGOP|18
origins|2016-10-01 00:00:00+|False|E-SOFT|17
origins|2016-10-01 00:00:00+|False|E-TASK|10
{code}
when imported with
{code}
COPY ks.test FROM 'test.csv' WITH DELIMITER = '|';
{code}
will generate a parse error:
{code}
Failed to import 7 rows: ParseError - can't interpret u"'2016-10-01
00:00:00+'" as a date with this format: %Y-%m-%d %H:%M:%S%z, given up
without retries
{code}
The problem is that when a counter value is present, we don't use prepared
statements and hence add quotes to certain types, such as timestamps. However,
because the timestamp is part of the partition key, we must parse it in order
to determine the routing token. Here lies the problem, we do not remove the
quotes before parsing the partition key, therefore ending up with a parse
error.)
> cqlsh COPY FROM cannot parse timestamp in partition key if table contains a
> counter value
> -
>
> Key: CASSANDRA-12863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12863
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12863) cqlsh COPY FROM cannot parse timestamp in partition key if table contains a counter value
[
https://issues.apache.org/jira/browse/CASSANDRA-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-12863:
-
Status: Patch Available (was: In Progress)
> cqlsh COPY FROM cannot parse timestamp in partition key if table contains a
> counter value
> -
>
> Key: CASSANDRA-12863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12863
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> This sample table:
> {code}
> CREATE TABLE test (columnname text, day timestamp, israndom boolean,
> columnvalue text, counter counter, PRIMARY KEY ((columnname, day, israndom),
> columnvalue));
> {code}
> with this sample data:
> {code}
> origins|2016-10-01 00:00:00+|False|ACTUAL|6
> origins|2016-10-01 00:00:00+|False|ADGMOB|4
> origins|2016-10-01 00:00:00+|False|ANONPM|4
> origins|2016-10-01 00:00:00+|False|CSRT2L|76
> origins|2016-10-01 00:00:00+|False|DIAGOP|18
> origins|2016-10-01 00:00:00+|False|E-SOFT|17
> origins|2016-10-01 00:00:00+|False|E-TASK|10
> {code}
> when imported with
> {code}
> COPY ks.test FROM 'test.csv' WITH DELIMITER = '|';
> {code}
> will generate a parse error:
> {code}
> Failed to import 7 rows: ParseError - can't interpret u"'2016-10-01
> 00:00:00+'" as a date with this format: %Y-%m-%d %H:%M:%S%z, given up
> without retries
> {code}
> The problem is that when a counter value is present, we don't use prepared
> statements and hence add quotes to certain types, such as timestamps.
> However, because the timestamp is part of the partition key, we must parse it
> in order to determine the routing token. Here lies the problem, we do not
> remove the quotes before parsing the partition key, therefore ending up with
> a parse error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12863) cqlsh COPY FROM cannot parse timestamp in partition key if table contains a counter value
[
https://issues.apache.org/jira/browse/CASSANDRA-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15620959#comment-15620959
]
Stefania commented on CASSANDRA-12863:
--
The patch is here, it applies cleanly to all branches.
||2.2||3.0||3.X||trunk||
|[patch|https://github.com/stef1927/cassandra/tree/12863-cqlsh-2.2]|[patch|https://github.com/stef1927/cassandra/tree/12863-cqlsh-3.0]|[patch|https://github.com/stef1927/cassandra/tree/12863-cqlsh-3.X]|[patch|https://github.com/stef1927/cassandra/tree/12863-cqlsh]|
|[cqlsh
tests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12863-cqlsh-2.2-cqlsh-tests/]|[cqlsh
tests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12863-cqlsh-3.0-cqlsh-tests/]|[cqlsh
tests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12863-cqlsh-3.X-cqlsh-tests/]|[cqlsh
tests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12863-cqlsh-cqlsh-tests/]|
[~pauloricardomg] or [~thobbs], would you have time to review this super-simple
patch?
> cqlsh COPY FROM cannot parse timestamp in partition key if table contains a
> counter value
> -
>
> Key: CASSANDRA-12863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12863
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> This sample table:
> {code}
> CREATE TABLE test (columnname text, day timestamp, israndom boolean,
> columnvalue text, counter counter, PRIMARY KEY ((columnname, day, israndom),
> columnvalue));
> {code}
> with this sample data:
> {code}
> origins|2016-10-01 00:00:00+|False|ACTUAL|6
> origins|2016-10-01 00:00:00+|False|ADGMOB|4
> origins|2016-10-01 00:00:00+|False|ANONPM|4
> origins|2016-10-01 00:00:00+|False|CSRT2L|76
> origins|2016-10-01 00:00:00+|False|DIAGOP|18
> origins|2016-10-01 00:00:00+|False|E-SOFT|17
> origins|2016-10-01 00:00:00+|False|E-TASK|10
> {code}
> when imported with
> {code}
> COPY ks.test FROM 'test.csv' WITH DELIMITER = '|';
> {code}
> will generate a parse error:
> {code}
> Failed to import 7 rows: ParseError - can't interpret u"'2016-10-01
> 00:00:00+'" as a date with this format: %Y-%m-%d %H:%M:%S%z, given up
> without retries
> {code}
> The problem is that when a counter value is present, we don't use prepared
> statements and hence add quotes to certain types, such as timestamps.
> However, because the timestamp is part of the partition key, we must parse it
> in order to determine the routing token. Here lies the problem, we do not
> remove the quotes before parsing the partition key, therefore ending up with
> a parse error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12863) cqlsh COPY FROM cannot parse timestamp in partition key if table contains a counter value
Stefania created CASSANDRA-12863:
Summary: cqlsh COPY FROM cannot parse timestamp in partition key
if table contains a counter value
Key: CASSANDRA-12863
URL: https://issues.apache.org/jira/browse/CASSANDRA-12863
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Stefania
Assignee: Stefania
Fix For: 2.2.x, 3.0.x, 3.x
This sample table:
{code}
CREATE TABLE test (columnname text, day timestamp, israndom boolean,
columnvalue text, counter counter, PRIMARY KEY ((columnname, day, israndom),
columnvalue));
{code}
with this sample data:
{code}
origins|2016-10-01 00:00:00+|False|ACTUAL|6
origins|2016-10-01 00:00:00+|False|ADGMOB|4
origins|2016-10-01 00:00:00+|False|ANONPM|4
origins|2016-10-01 00:00:00+|False|CSRT2L|76
origins|2016-10-01 00:00:00+|False|DIAGOP|18
origins|2016-10-01 00:00:00+|False|E-SOFT|17
origins|2016-10-01 00:00:00+|False|E-TASK|10
{code}
when imported with
{code}
COPY ks.test FROM 'test.csv' WITH DELIMITER = '|';
{code}
will generate a parse error:
{code}
Failed to import 7 rows: ParseError - can't interpret u"'2016-10-01
00:00:00+'" as a date with this format: %Y-%m-%d %H:%M:%S%z, given up
without retries
{code}
The problem is that when a counter value is present, we don't use prepared
statements and hence add quotes to certain types, such as timestamps. However,
because the timestamp is part of the partition key, we must parse it in order
to determine the routing token. Here lies the problem, we do not remove the
quotes before parsing the partition key, therefore ending up with a parse error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12862) LWT leaves corrupted state
Artur Siekielski created CASSANDRA-12862: Summary: LWT leaves corrupted state Key: CASSANDRA-12862 URL: https://issues.apache.org/jira/browse/CASSANDRA-12862 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.1.16, 3-node cluster with RF=3, NetworkTopology with 1 DC Reporter: Artur Siekielski When executing "INSERT ... IF NOT EXISTS" (with consistency LOCAL_QUORUM) while the concurrency level is high (about 50 simultaneous threads doing inserts, for the same partition key but different clustering keys) sometimes the INSERT returns applied=False, but the subsequent SELECTs return no data. The corrupted state is permanent - neither the INSERT or SELECTs succeed, making the PK "locked". I can easily reproduce this - for 100 simultaneous threads doing a single insert I get 1-2 corruptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12861) example/triggers build fail.
Yasuharu Goto created CASSANDRA-12861:
-
Summary: example/triggers build fail.
Key: CASSANDRA-12861
URL: https://issues.apache.org/jira/browse/CASSANDRA-12861
Project: Cassandra
Issue Type: Bug
Reporter: Yasuharu Goto
Assignee: Yasuharu Goto
Priority: Trivial
When I tried to build example/trigger on trunk branch, I found that "ant jar"
fails with an error like below.
(Sorry for my language settings for ant. I couldn't find how to change it. The
error indicated here is a "cannot find symboll" error of RowUpdateBuilder).
{code}
Buildfile: /Users/yasuharu/git/cassandra/examples/triggers/build.xml
init:
[mkdir] Created dir:
/Users/yasuharu/git/cassandra/examples/triggers/build/classes
build:
[javac] Compiling 1 source file to
/Users/yasuharu/git/cassandra/examples/triggers/build/classes
[javac] 警告: 注釈プロセッサ'org.openjdk.jmh.generators.BenchmarkProcessor'から-source
'1.8'より小さいソース・バージョン'RELEASE_6'がサポートされています
[javac]
/Users/yasuharu/git/cassandra/examples/triggers/src/org/apache/cassandra/triggers/AuditTrigger.java:27:
エラー: シンボルを見つけられません
[javac] import org.apache.cassandra.db.RowUpdateBuilder;
[javac] ^
[javac] シンボル: クラス RowUpdateBuilder
[javac] 場所: パッケージ org.apache.cassandra.db
[javac] エラー1個
[javac] 警告1個
BUILD FAILED
/Users/yasuharu/git/cassandra/examples/triggers/build.xml:45: Compile failed;
see the compiler error output for details.
Total time: 1 second
{code}
I think the movement of RowUpdateBuilder to test has broken this build.
https://github.com/apache/cassandra/commit/26838063de6246e3a1e18062114ca92fb81c00cf
In order to fix this, I moved back RowUpdateBuilder.java to src in my patch.
https://github.com/apache/cassandra/commit/d133eefe9c5fbebd8d389a9397c3948b8c36bd06
Could you please review my patch?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
