[jira] [Comment Edited] (CASSANDRA-11137) JSON datetime formatting needs timezone
[
https://issues.apache.org/jira/browse/CASSANDRA-11137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138469#comment-15138469
]
Ralf Steppacher edited comment on CASSANDRA-11137 at 2/9/16 7:48 AM:
-
My original issue was with the Java driver. I just used cqlsh to demonstrate
the issue.
Personally I think that adding the timezone is the correct fix. Every datetime
library will do the "right thing" if the information is included.
was (Author: ralfsteppacher):
My original issue was with the Java driver. I just used cqlsh to demonstrate
the issue. (The examples in the ticket description use two different table
names but they should be the same table. I cannot edit the description.)
Personally I think that adding the timezone is the correct fix. Every datetime
library will do the "right thing" if the information is included.
> JSON datetime formatting needs timezone
> ---
>
> Key: CASSANDRA-11137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11137
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Stefania
>
> The JSON date time string representation lacks the timezone information:
> {code}
> cqlsh:events> select toJson(created_at) AS created_at from
> event_by_user_timestamp ;
> created_at
> ---
> "2016-01-04 16:05:47.123"
> (1 rows)
> {code}
> vs.
> {code}
> cqlsh:events> select created_at FROM event_by_user_timestamp ;
> created_at
> --
> 2016-01-04 15:05:47+
> (1 rows)
> cqlsh:events>
> {code}
> To make things even more complicated the JSON timestamp is not returned in
> UTC.
> At the moment {{DateType}} picks this formatting string {{"-MM-dd
> HH:mm:ss.SSS"}}. Shouldn't we somehow make this configurable by users or at a
> minimum add the timezone?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11137) JSON datetime formatting needs timezone
[
https://issues.apache.org/jira/browse/CASSANDRA-11137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138492#comment-15138492
]
Stefania commented on CASSANDRA-11137:
--
bq. My original issue was with the Java driver.
I suspect the Java driver simply prints the JSON string like cqlsh does so the
fix is definitely in Cassandra.
bq. The examples in the ticket description use two different table names but
they should be the same table. I cannot edit the description.
Description amended, thank you.
> JSON datetime formatting needs timezone
> ---
>
> Key: CASSANDRA-11137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11137
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Stefania
>
> The JSON date time string representation lacks the timezone information:
> {code}
> cqlsh:events> select toJson(created_at) AS created_at from
> event_by_user_timestamp ;
> created_at
> ---
> "2016-01-04 16:05:47.123"
> (1 rows)
> {code}
> vs.
> {code}
> cqlsh:events> select created_at FROM event_by_user_timestamp ;
> created_at
> --
> 2016-01-04 15:05:47+
> (1 rows)
> cqlsh:events>
> {code}
> To make things even more complicated the JSON timestamp is not returned in
> UTC.
> At the moment {{DateType}} picks this formatting string {{"-MM-dd
> HH:mm:ss.SSS"}}. Shouldn't we somehow make this configurable by users or at a
> minimum add the timezone?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11138) cassandra-stress tool - clustering key values not distributed
[
https://issues.apache.org/jira/browse/CASSANDRA-11138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralf Steppacher updated CASSANDRA-11138:
Description:
I am trying to get the stress tool to generate random values for three
clustering keys. I am trying to simulate collecting events per user id (text,
partition key). Events have a session type (text), event type (text), and
creation time (timestamp) (clustering keys, in that order). For testing
purposes I ended up with the following column spec:
{noformat}
columnspec:
- name: created_at
cluster: uniform(10..10)
- name: event_type
size: uniform(5..10)
population: uniform(1..30)
cluster: uniform(1..30)
- name: session_type
size: fixed(5)
population: uniform(1..4)
cluster: uniform(1..4)
- name: user_id
size: fixed(15)
population: uniform(1..100)
- name: message
size: uniform(10..100)
population: uniform(1..100B)
{noformat}
My expectation was that this would lead to anywhere between 10 and 1200 rows to
be created per partition key. But it seems that exactly 10 rows are being
created, with the {{created_at}} timestamp being the only variable that is
assigned variable values (per partition key). The {{session_type}} and
{{event_type}} variables are assigned fixed values. This is even the case if I
set the cluster distribution to uniform(30..30) and uniform(4..4) respectively.
With this setting I expected 1200 rows per partition key to be created, as
announced when running the stress tool, but it is still 10.
{noformat}
[rsteppac@centos bin]$ ./cassandra-stress user profile=../batch_too_large.yaml
ops\(insert=1\) -log level=verbose
file=~/centos_eventy_patient_session_event_timestamp_insert_only.log -node
10.211.55.8
…
Created schema. Sleeping 1s for propagation.
Generating batches with [1..1] partitions and [1..1] rows (of [1200..1200]
total rows in the partitions)
Improvement over 4 threadCount: 19%
...
{noformat}
Sample of generated data:
{noformat}
cqlsh> select user_id, event_type, session_type, created_at from
stresscql.batch_too_large LIMIT 30 ;
user_id | event_type | session_type | created_at
-+--+--+--
%\x7f\x03/.d29
{noformat}
If I remove the {{created_at}} clustering key, then the other two clustering
keys are being assigned variable values per partition key.
was:
I am trying to get the stress tool to generate random values for three
clustering keys. I am trying to simulate collecting events per user id (text,
partition key). Events have a session type (text), event type (text), and
creation time (timestamp) (clustering keys, in that order). For testing
purposes I ended up with the following column spec:
{noformat}
columnspec:
- name: created_at
cluster: uniform(10..10)
- name: event_type
size: uniform(5..10)
population: uniform(1..30)
cluster: uniform(1..30)
- name: session_type
size: fixed(5)
population: uniform(1..4)
cluster: uniform(1..4)
- name: user_id
size: fixed(15)
population: uniform(1..100)
- name: message
size: uniform(10..100)
population: uniform(1..100B)
{noformat}
My expectation was that this would lead to anywhere between 10 and 1200 rows to
be created per partition key. But it seems that exactly 10 rows are being
created, with the {{created_at}} timestamp being the only variable that is
assigned variable values (per partition key). The {{session_type}} and
{{event_type}} variables are assigned fixed values. This is even the case if I
set the cluster distribution to uniform(30..30) and uniform(4..4) respectively.
With this setting I expected 1200 rows per partition key to be created, as
announced when running the stress tool, but it is still 10.
{noformat}
[rsteppac@centos bin]$ ./cassandra-stress user profile=../batch_too_large.yaml
ops\(insert=1\) -log level=verbose
file=~/centos_eventy_patient_session_event_timestamp_insert_only.log -node
10.211.55.8
…
Created schema. Sleeping 1s for propagation.
Generating batches with [1..1] partitions and [1..1] rows (of [1200..1200]
total rows in the partitions)
Improvement over 4 threadCount: 19%
...
{noformat}
Sample of generated data:
{noformat}
cqlsh> select user_id, event_type, session_type, created_at from
stresscql.batch_too_large LIMIT 30 ;
user_id | event_type | session_type | created_at
-+--+--+--
%\x7f\x03/.d29
{noformat}
If I remove the created_at clustering keys then the other two clustering keys
are assigned variable values per partition key.
> cassandra-stress tool - clustering key values not distributed
> -
>
> Key: CASSANDRA-11138
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11138
>
[jira] [Created] (CASSANDRA-11138) cassandra-stress tool - clustering key values not distributed
Ralf Steppacher created CASSANDRA-11138:
---
Summary: cassandra-stress tool - clustering key values not
distributed
Key: CASSANDRA-11138
URL: https://issues.apache.org/jira/browse/CASSANDRA-11138
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Cassandra 2.2.4, Centos 6.5, Java 8
Reporter: Ralf Steppacher
I am trying to get the stress tool to generate random values for three
clustering keys. I am trying to simulate collecting events per user id (text,
partition key). Events have a session type (text), event type (text), and
creation time (timestamp) (clustering keys, in that order). For testing
purposes I ended up with the following column spec:
{noformat}
columnspec:
- name: created_at
cluster: uniform(10..10)
- name: event_type
size: uniform(5..10)
population: uniform(1..30)
cluster: uniform(1..30)
- name: session_type
size: fixed(5)
population: uniform(1..4)
cluster: uniform(1..4)
- name: user_id
size: fixed(15)
population: uniform(1..100)
- name: message
size: uniform(10..100)
population: uniform(1..100B)
{noformat}
My expectation was that this would lead to anywhere between 10 and 1200 rows to
be created per partition key. But it seems that exactly 10 rows are being
created, with the {{created_at}} timestamp being the only variable that is
assigned variable values (per partition key). The {{session_type}} and
{{event_type}} variables are assigned fixed values. This is even the case if I
set the cluster distribution to uniform(30..30) and uniform(4..4) respectively.
With this setting I expected 1200 rows per partition key to be created, as
announced when running the stress tool, but it is still 10.
{noformat}
[rsteppac@centos bin]$ ./cassandra-stress user profile=../batch_too_large.yaml
ops\(insert=1\) -log level=verbose
file=~/centos_eventy_patient_session_event_timestamp_insert_only.log -node
10.211.55.8
…
Created schema. Sleeping 1s for propagation.
Generating batches with [1..1] partitions and [1..1] rows (of [1200..1200]
total rows in the partitions)
Improvement over 4 threadCount: 19%
...
{noformat}
Sample of generated data:
{noformat}
cqlsh> select user_id, event_type, session_type, created_at from
stresscql.batch_too_large LIMIT 30 ;
user_id | event_type | session_type | created_at
-+--+--+--
%\x7f\x03/.d29
{noformat}
If I remove the created_at clustering keys then the other two clustering keys
are assigned variable values per partition key.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11137) JSON datetime formatting needs timezone
[
https://issues.apache.org/jira/browse/CASSANDRA-11137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-11137:
-
Description:
The JSON date time string representation lacks the timezone information:
{code}
cqlsh:events> select toJson(created_at) AS created_at from
event_by_user_timestamp ;
created_at
---
"2016-01-04 16:05:47.123"
(1 rows)
{code}
vs.
{code}
cqlsh:events> select created_at FROM event_by_user_timestamp ;
created_at
--
2016-01-04 15:05:47+
(1 rows)
cqlsh:events>
{code}
To make things even more complicated the JSON timestamp is not returned in UTC.
At the moment {{DateType}} picks this formatting string {{"-MM-dd
HH:mm:ss.SSS"}}. Shouldn't we somehow make this configurable by users or at a
minimum add the timezone?
was:
The JSON date time string representation lacks the timezone information:
{code}
cqlsh:events> select toJson(created_at) AS created_at from
event_by_patient_timestamp ;
created_at
---
"2016-01-04 16:05:47.123"
(1 rows)
{code}
vs.
{code}
cqlsh:events> select created_at FROM event_by_user_timestamp ;
created_at
--
2016-01-04 15:05:47+
(1 rows)
cqlsh:events>
{code}
To make things even more complicated the JSON timestamp is not returned in UTC.
At the moment {{DateType}} picks this formatting string {{"-MM-dd
HH:mm:ss.SSS"}}. Shouldn't we somehow make this configurable by users or at a
minimum add the timezone?
> JSON datetime formatting needs timezone
> ---
>
> Key: CASSANDRA-11137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11137
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Stefania
>
> The JSON date time string representation lacks the timezone information:
> {code}
> cqlsh:events> select toJson(created_at) AS created_at from
> event_by_user_timestamp ;
> created_at
> ---
> "2016-01-04 16:05:47.123"
> (1 rows)
> {code}
> vs.
> {code}
> cqlsh:events> select created_at FROM event_by_user_timestamp ;
> created_at
> --
> 2016-01-04 15:05:47+
> (1 rows)
> cqlsh:events>
> {code}
> To make things even more complicated the JSON timestamp is not returned in
> UTC.
> At the moment {{DateType}} picks this formatting string {{"-MM-dd
> HH:mm:ss.SSS"}}. Shouldn't we somehow make this configurable by users or at a
> minimum add the timezone?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11137) JSON datetime formatting needs timezone
[
https://issues.apache.org/jira/browse/CASSANDRA-11137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138469#comment-15138469
]
Ralf Steppacher commented on CASSANDRA-11137:
-
My original issue was with the Java driver. I just used cqlsh to demonstrate
the issue. (The examples in the ticket description use two different table
names but they should be the same table. I cannot edit the description.)
Personally I think that adding the timezone is the correct fix. Every datetime
library will do the "right thing" if the information is included.
> JSON datetime formatting needs timezone
> ---
>
> Key: CASSANDRA-11137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11137
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Stefania
>
> The JSON date time string representation lacks the timezone information:
> {code}
> cqlsh:events> select toJson(created_at) AS created_at from
> event_by_patient_timestamp ;
> created_at
> ---
> "2016-01-04 16:05:47.123"
> (1 rows)
> {code}
> vs.
> {code}
> cqlsh:events> select created_at FROM event_by_user_timestamp ;
> created_at
> --
> 2016-01-04 15:05:47+
> (1 rows)
> cqlsh:events>
> {code}
> To make things even more complicated the JSON timestamp is not returned in
> UTC.
> At the moment {{DateType}} picks this formatting string {{"-MM-dd
> HH:mm:ss.SSS"}}. Shouldn't we somehow make this configurable by users or at a
> minimum add the timezone?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[12/14] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a598ebee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a598ebee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a598ebee Branch: refs/heads/cassandra-3.0 Commit: a598ebeef47e7affa9d59d0bb95abe71447eed5b Parents: 0d30540 c08aaf6 Author: Marcus Eriksson Authored: Tue Feb 9 07:14:23 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:15:40 2016 +0100 -- CHANGES.txt| 1 + doc/cql3/CQL.textile | 2 +- pylib/cqlshlib/cql3handling.py | 1 - .../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++ 4 files changed, 8 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a598ebee/CHANGES.txt -- diff --cc CHANGES.txt index c6111e5,fdd1122..4074c66 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -8,45 -4,10 +8,46 @@@ Merged from 2.2.6 Merged from 2.1: * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) + * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) +3.0.3 + * Remove double initialization of newly added tables (CASSANDRA-11027) + * Filter keys searcher results by target range (CASSANDRA-11104) + * Fix deserialization of legacy read commands (CASSANDRA-11087) + * Fix incorrect computation of deletion time in sstable metadata (CASSANDRA-11102) + * Avoid memory leak when collecting sstable metadata (CASSANDRA-11026) + * Mutations do not block for completion under view lock contention (CASSANDRA-10779) + * Invalidate legacy schema tables when unloading them (CASSANDRA-11071) + * (cqlsh) handle INSERT and UPDATE statements with LWT conditions correctly + (CASSANDRA-11003) + * Fix DISTINCT queries in mixed version clusters (CASSANDRA-10762) + * Migrate build status for indexes along with legacy schema (CASSANDRA-11046) + * Ensure SSTables for legacy KEYS indexes can be read (CASSANDRA-11045) + * Added support for IBM zSystems architecture (CASSANDRA-11054) + * Update CQL documentation (CASSANDRA-10899) + * Check the column name, not cell name, for dropped columns when reading + legacy sstables (CASSANDRA-11018) + * Don't attempt to index clustering values of static rows (CASSANDRA-11021) + * Remove checksum files after replaying hints (CASSANDRA-10947) + * Support passing base table metadata to custom 2i validation (CASSANDRA-10924) + * Ensure stale index entries are purged during reads (CASSANDRA-11013) + * Fix AssertionError when removing from list using UPDATE (CASSANDRA-10954) + * Fix UnsupportedOperationException when reading old sstable with range + tombstone (CASSANDRA-10743) + * MV should use the maximum timestamp of the primary key (CASSANDRA-10910) + * Fix potential assertion error during compaction (CASSANDRA-10944) + * Fix counting of received sstables in streaming (CASSANDRA-10949) + * Implement hints compression (CASSANDRA-9428) + * Fix potential assertion error when reading static columns (CASSANDRA-10903) + * Avoid NoSuchElementException when executing empty batch (CASSANDRA-10711) + * Avoid building PartitionUpdate in toString (CASSANDRA-10897) + * Reduce heap spent when receiving many SSTables (CASSANDRA-10797) + * Add back support for 3rd party auth providers to bulk loader (CASSANDRA-10873) + * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653) + * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes (CASSANDRA-10837) + * Fix sstableloader not working with upper case keyspace name (CASSANDRA-10806) +Merged from 2.2: 2.2.5 * maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949) * Apply change to compaction throughput in real time (CASSANDRA-10025) http://git-wip-us.apache.org/repos/asf/cassandra/blob/a598ebee/doc/cql3/CQL.textile -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a598ebee/pylib/cqlshlib/cql3handling.py --
[10/14] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c08aaf69 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c08aaf69 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c08aaf69 Branch: refs/heads/cassandra-2.2 Commit: c08aaf69b4bb62e2fe50342dfaa329dfd833ee1e Parents: 029b22e 725b9b1 Author: Marcus Eriksson Authored: Tue Feb 9 07:14:00 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:14:00 2016 +0100 -- CHANGES.txt| 3 ++- doc/cql3/CQL.textile | 2 +- pylib/cqlshlib/cql3handling.py | 1 - .../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++ 4 files changed, 9 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/CHANGES.txt -- diff --cc CHANGES.txt index 770c394,72b3d59..fdd1122 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,41 -1,11 +1,42 @@@ -2.1.14 - * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) +2.2.6 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) + * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) +Merged from 2.1: * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) ++ * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) + * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) -2.1.13 +2.2.5 + * maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949) + * Apply change to compaction throughput in real time (CASSANDRA-10025) + * Fix potential NPE on ORDER BY queries with IN (CASSANDRA-10955) + * Avoid over-fetching during the page of range queries (CASSANDRA-8521) + * Start L0 STCS-compactions even if there is a L0 -> L1 compaction + going (CASSANDRA-10979) + * Make UUID LSB unique per process (CASSANDRA-7925) + * Avoid NPE when performing sstable tasks (scrub etc.) (CASSANDRA-10980) + * Make sure client gets tombstone overwhelmed warning (CASSANDRA-9465) + * Fix error streaming section more than 2GB (CASSANDRA-10961) + * (cqlsh) Also apply --connect-timeout to control connection + timeout (CASSANDRA-10959) + * Histogram buckets exposed in jmx are sorted incorrectly (CASSANDRA-10975) + * Enable GC logging by default (CASSANDRA-10140) + * Optimize pending range computation (CASSANDRA-9258) + * Skip commit log and saved cache directories in SSTable version startup check (CASSANDRA-10902) + * drop/alter user should be case sensitive (CASSANDRA-10817) + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) + * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) + * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) + * Add new types to Stress (CASSANDRA-9556) + * Add property to allow listening on broadcast interface (CASSANDRA-9748) + * Fix regression in split size on CqlInputFormat (CASSANDRA-10835) + * Better handling of SSL connection errors inter-node (CASSANDRA-10816) + * Disable reloading of GossipingPropertyFileSnitch (CASSANDRA-9474) + * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761) + * (cqlsh) encode input correctly when saving history +Merged from 2.1: - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969) * Avoid NPE when incremental repair fails (CASSANDRA-10909) http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/doc/cql3/CQL.textile -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/pylib/cqlshlib/cql3handling.py --
[03/14] cassandra git commit: Make it clear what timestamp_resolution is used for
Make it clear what timestamp_resolution is used for
Patch by marcuse; reviewed by Jeff Jirsa for CASSANDRA-11041
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b8408f06
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b8408f06
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b8408f06
Branch: refs/heads/cassandra-2.2
Commit: b8408f068bf2fc73f632d09239ba892a9835416f
Parents: 6fe70c6
Author: Marcus Eriksson
Authored: Wed Jan 20 08:58:05 2016 +0100
Committer: Marcus Eriksson
Committed: Tue Feb 9 07:08:22 2016 +0100
--
CHANGES.txt| 1 +
doc/cql3/CQL.textile | 2 +-
pylib/cqlshlib/cql3handling.py | 1 -
.../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++
4 files changed, 8 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 806e6d5..e5d6ff1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.14
+ * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041)
* Gossiper#isEnabled is not thread safe (CASSANDRA-6)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 3b69fcc..812a75e 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -347,7 +347,7 @@ The @compaction@ property must at least define the
@'class'@ sub-option, that de
| @bucket_low@ | SizeTieredCompactionStrategy| 0.5
| Size tiered consider sstables to be within the same bucket if their size
is within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the
default groups sstable whose sizes diverges by at most 50%)|
| @bucket_high@| SizeTieredCompactionStrategy| 1.5
| Size tiered consider sstables to be within the same bucket if their size
is within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the
default groups sstable whose sizes diverges by at most 50%).|
| @sstable_size_in_mb@ | LeveledCompactionStrategy | 5MB
| The target size (in MB) for sstables in the leveled strategy. Note that
while sstable sizes should stay less or equal to @sstable_size_in_mb@, it is
possible to exceptionally have a larger sstable as during compaction, data for
a given partition key are never split into 2 sstables|
-| @timestamp_resolution@ | DateTieredCompactionStrategy|
MICROSECONDS | The timestamp resolution used when inserting data, could be
MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit)|
+| @timestamp_resolution@ | DateTieredCompactionStrategy|
MICROSECONDS | The timestamp resolution used when inserting data, could be
MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit) -
don't change this unless you do mutations with USING TIMESTAMP
(or equivalent directly in the client)|
| @base_time_seconds@ | DateTieredCompactionStrategy| 60
| The base size of the time windows. |
| @max_sstable_age_days@ | DateTieredCompactionStrategy| 365
| SSTables only containing data that is older than this will never be
compacted. |
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 38f118f..029e0c7 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -470,7 +470,6 @@ def cf_prop_val_mapkey_completer(ctxt, cass):
elif csc == 'DateTieredCompactionStrategy':
opts.add('base_time_seconds')
opts.add('max_sstable_age_days')
-opts.add('timestamp_resolution')
opts.add('min_threshold')
opts.add('max_window_size_seconds')
return map(escape_value, opts)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
--
diff --git
a/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
b/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
index 5803115..78a0cab 100644
---
a/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionS
[11/14] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c08aaf69 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c08aaf69 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c08aaf69 Branch: refs/heads/trunk Commit: c08aaf69b4bb62e2fe50342dfaa329dfd833ee1e Parents: 029b22e 725b9b1 Author: Marcus Eriksson Authored: Tue Feb 9 07:14:00 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:14:00 2016 +0100 -- CHANGES.txt| 3 ++- doc/cql3/CQL.textile | 2 +- pylib/cqlshlib/cql3handling.py | 1 - .../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++ 4 files changed, 9 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/CHANGES.txt -- diff --cc CHANGES.txt index 770c394,72b3d59..fdd1122 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,41 -1,11 +1,42 @@@ -2.1.14 - * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) +2.2.6 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) + * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) +Merged from 2.1: * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) ++ * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) + * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) -2.1.13 +2.2.5 + * maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949) + * Apply change to compaction throughput in real time (CASSANDRA-10025) + * Fix potential NPE on ORDER BY queries with IN (CASSANDRA-10955) + * Avoid over-fetching during the page of range queries (CASSANDRA-8521) + * Start L0 STCS-compactions even if there is a L0 -> L1 compaction + going (CASSANDRA-10979) + * Make UUID LSB unique per process (CASSANDRA-7925) + * Avoid NPE when performing sstable tasks (scrub etc.) (CASSANDRA-10980) + * Make sure client gets tombstone overwhelmed warning (CASSANDRA-9465) + * Fix error streaming section more than 2GB (CASSANDRA-10961) + * (cqlsh) Also apply --connect-timeout to control connection + timeout (CASSANDRA-10959) + * Histogram buckets exposed in jmx are sorted incorrectly (CASSANDRA-10975) + * Enable GC logging by default (CASSANDRA-10140) + * Optimize pending range computation (CASSANDRA-9258) + * Skip commit log and saved cache directories in SSTable version startup check (CASSANDRA-10902) + * drop/alter user should be case sensitive (CASSANDRA-10817) + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) + * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) + * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) + * Add new types to Stress (CASSANDRA-9556) + * Add property to allow listening on broadcast interface (CASSANDRA-9748) + * Fix regression in split size on CqlInputFormat (CASSANDRA-10835) + * Better handling of SSL connection errors inter-node (CASSANDRA-10816) + * Disable reloading of GossipingPropertyFileSnitch (CASSANDRA-9474) + * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761) + * (cqlsh) encode input correctly when saving history +Merged from 2.1: - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969) * Avoid NPE when incremental repair fails (CASSANDRA-10909) http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/doc/cql3/CQL.textile -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/pylib/cqlshlib/cql3handling.py --
[02/14] cassandra git commit: Make it clear what timestamp_resolution is used for
Make it clear what timestamp_resolution is used for
Patch by marcuse; reviewed by Jeff Jirsa for CASSANDRA-11041
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b8408f06
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b8408f06
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b8408f06
Branch: refs/heads/trunk
Commit: b8408f068bf2fc73f632d09239ba892a9835416f
Parents: 6fe70c6
Author: Marcus Eriksson
Authored: Wed Jan 20 08:58:05 2016 +0100
Committer: Marcus Eriksson
Committed: Tue Feb 9 07:08:22 2016 +0100
--
CHANGES.txt| 1 +
doc/cql3/CQL.textile | 2 +-
pylib/cqlshlib/cql3handling.py | 1 -
.../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++
4 files changed, 8 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 806e6d5..e5d6ff1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.14
+ * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041)
* Gossiper#isEnabled is not thread safe (CASSANDRA-6)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 3b69fcc..812a75e 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -347,7 +347,7 @@ The @compaction@ property must at least define the
@'class'@ sub-option, that de
| @bucket_low@ | SizeTieredCompactionStrategy| 0.5
| Size tiered consider sstables to be within the same bucket if their size
is within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the
default groups sstable whose sizes diverges by at most 50%)|
| @bucket_high@| SizeTieredCompactionStrategy| 1.5
| Size tiered consider sstables to be within the same bucket if their size
is within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the
default groups sstable whose sizes diverges by at most 50%).|
| @sstable_size_in_mb@ | LeveledCompactionStrategy | 5MB
| The target size (in MB) for sstables in the leveled strategy. Note that
while sstable sizes should stay less or equal to @sstable_size_in_mb@, it is
possible to exceptionally have a larger sstable as during compaction, data for
a given partition key are never split into 2 sstables|
-| @timestamp_resolution@ | DateTieredCompactionStrategy|
MICROSECONDS | The timestamp resolution used when inserting data, could be
MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit)|
+| @timestamp_resolution@ | DateTieredCompactionStrategy|
MICROSECONDS | The timestamp resolution used when inserting data, could be
MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit) -
don't change this unless you do mutations with USING TIMESTAMP
(or equivalent directly in the client)|
| @base_time_seconds@ | DateTieredCompactionStrategy| 60
| The base size of the time windows. |
| @max_sstable_age_days@ | DateTieredCompactionStrategy| 365
| SSTables only containing data that is older than this will never be
compacted. |
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 38f118f..029e0c7 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -470,7 +470,6 @@ def cf_prop_val_mapkey_completer(ctxt, cass):
elif csc == 'DateTieredCompactionStrategy':
opts.add('base_time_seconds')
opts.add('max_sstable_age_days')
-opts.add('timestamp_resolution')
opts.add('min_threshold')
opts.add('max_window_size_seconds')
return map(escape_value, opts)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
--
diff --git
a/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
b/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
index 5803115..78a0cab 100644
---
a/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyO
[04/14] cassandra git commit: Make it clear what timestamp_resolution is used for
Make it clear what timestamp_resolution is used for
Patch by marcuse; reviewed by Jeff Jirsa for CASSANDRA-11041
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b8408f06
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b8408f06
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b8408f06
Branch: refs/heads/cassandra-3.0
Commit: b8408f068bf2fc73f632d09239ba892a9835416f
Parents: 6fe70c6
Author: Marcus Eriksson
Authored: Wed Jan 20 08:58:05 2016 +0100
Committer: Marcus Eriksson
Committed: Tue Feb 9 07:08:22 2016 +0100
--
CHANGES.txt| 1 +
doc/cql3/CQL.textile | 2 +-
pylib/cqlshlib/cql3handling.py | 1 -
.../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++
4 files changed, 8 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 806e6d5..e5d6ff1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.14
+ * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041)
* Gossiper#isEnabled is not thread safe (CASSANDRA-6)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 3b69fcc..812a75e 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -347,7 +347,7 @@ The @compaction@ property must at least define the
@'class'@ sub-option, that de
| @bucket_low@ | SizeTieredCompactionStrategy| 0.5
| Size tiered consider sstables to be within the same bucket if their size
is within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the
default groups sstable whose sizes diverges by at most 50%)|
| @bucket_high@| SizeTieredCompactionStrategy| 1.5
| Size tiered consider sstables to be within the same bucket if their size
is within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the
default groups sstable whose sizes diverges by at most 50%).|
| @sstable_size_in_mb@ | LeveledCompactionStrategy | 5MB
| The target size (in MB) for sstables in the leveled strategy. Note that
while sstable sizes should stay less or equal to @sstable_size_in_mb@, it is
possible to exceptionally have a larger sstable as during compaction, data for
a given partition key are never split into 2 sstables|
-| @timestamp_resolution@ | DateTieredCompactionStrategy|
MICROSECONDS | The timestamp resolution used when inserting data, could be
MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit)|
+| @timestamp_resolution@ | DateTieredCompactionStrategy|
MICROSECONDS | The timestamp resolution used when inserting data, could be
MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit) -
don't change this unless you do mutations with USING TIMESTAMP
(or equivalent directly in the client)|
| @base_time_seconds@ | DateTieredCompactionStrategy| 60
| The base size of the time windows. |
| @max_sstable_age_days@ | DateTieredCompactionStrategy| 365
| SSTables only containing data that is older than this will never be
compacted. |
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 38f118f..029e0c7 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -470,7 +470,6 @@ def cf_prop_val_mapkey_completer(ctxt, cass):
elif csc == 'DateTieredCompactionStrategy':
opts.add('base_time_seconds')
opts.add('max_sstable_age_days')
-opts.add('timestamp_resolution')
opts.add('min_threshold')
opts.add('max_window_size_seconds')
return map(escape_value, opts)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
--
diff --git
a/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
b/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
index 5803115..78a0cab 100644
---
a/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionS
[08/14] cassandra git commit: fix CHANGES.txt after 2.1.13 release
fix CHANGES.txt after 2.1.13 release Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/725b9b1f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/725b9b1f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/725b9b1f Branch: refs/heads/cassandra-3.0 Commit: 725b9b1f7f16ff8ad8e77ad0f7679d39bc7f05b2 Parents: b8408f0 Author: Marcus Eriksson Authored: Tue Feb 9 07:09:54 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:09:54 2016 +0100 -- CHANGES.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/725b9b1f/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index e5d6ff1..72b3d59 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,11 +1,11 @@ 2.1.14 * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) + * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) 2.1.13 - * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969) * Avoid NPE when incremental repair fails (CASSANDRA-10909)
[14/14] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9adc6d82 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9adc6d82 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9adc6d82 Branch: refs/heads/trunk Commit: 9adc6d82097e30bc25f218a65ed71f36d3cf0dab Parents: c227b92 a598ebe Author: Marcus Eriksson Authored: Tue Feb 9 07:16:00 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:16:00 2016 +0100 -- CHANGES.txt| 1 + doc/cql3/CQL.textile | 2 +- pylib/cqlshlib/cql3handling.py | 1 - .../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++ 4 files changed, 8 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9adc6d82/CHANGES.txt -- diff --cc CHANGES.txt index 86996d9,4074c66..f2e37a5 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -24,13 -8,10 +24,14 @@@ Merged from 2.2.6 Merged from 2.1: * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) + * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) -3.0.3 +3.3 + * Avoid infinite loop if owned range is smaller than number of + data dirs (CASSANDRA-11034) + * Avoid bootstrap hanging when existing nodes have no data to stream (CASSANDRA-11010) +Merged from 3.0: * Remove double initialization of newly added tables (CASSANDRA-11027) * Filter keys searcher results by target range (CASSANDRA-11104) * Fix deserialization of legacy read commands (CASSANDRA-11087) http://git-wip-us.apache.org/repos/asf/cassandra/blob/9adc6d82/doc/cql3/CQL.textile -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9adc6d82/pylib/cqlshlib/cql3handling.py --
[09/14] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c08aaf69 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c08aaf69 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c08aaf69 Branch: refs/heads/cassandra-3.0 Commit: c08aaf69b4bb62e2fe50342dfaa329dfd833ee1e Parents: 029b22e 725b9b1 Author: Marcus Eriksson Authored: Tue Feb 9 07:14:00 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:14:00 2016 +0100 -- CHANGES.txt| 3 ++- doc/cql3/CQL.textile | 2 +- pylib/cqlshlib/cql3handling.py | 1 - .../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++ 4 files changed, 9 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/CHANGES.txt -- diff --cc CHANGES.txt index 770c394,72b3d59..fdd1122 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,41 -1,11 +1,42 @@@ -2.1.14 - * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) +2.2.6 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) + * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) +Merged from 2.1: * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) ++ * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) + * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) -2.1.13 +2.2.5 + * maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949) + * Apply change to compaction throughput in real time (CASSANDRA-10025) + * Fix potential NPE on ORDER BY queries with IN (CASSANDRA-10955) + * Avoid over-fetching during the page of range queries (CASSANDRA-8521) + * Start L0 STCS-compactions even if there is a L0 -> L1 compaction + going (CASSANDRA-10979) + * Make UUID LSB unique per process (CASSANDRA-7925) + * Avoid NPE when performing sstable tasks (scrub etc.) (CASSANDRA-10980) + * Make sure client gets tombstone overwhelmed warning (CASSANDRA-9465) + * Fix error streaming section more than 2GB (CASSANDRA-10961) + * (cqlsh) Also apply --connect-timeout to control connection + timeout (CASSANDRA-10959) + * Histogram buckets exposed in jmx are sorted incorrectly (CASSANDRA-10975) + * Enable GC logging by default (CASSANDRA-10140) + * Optimize pending range computation (CASSANDRA-9258) + * Skip commit log and saved cache directories in SSTable version startup check (CASSANDRA-10902) + * drop/alter user should be case sensitive (CASSANDRA-10817) + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) + * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) + * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) + * Add new types to Stress (CASSANDRA-9556) + * Add property to allow listening on broadcast interface (CASSANDRA-9748) + * Fix regression in split size on CqlInputFormat (CASSANDRA-10835) + * Better handling of SSL connection errors inter-node (CASSANDRA-10816) + * Disable reloading of GossipingPropertyFileSnitch (CASSANDRA-9474) + * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761) + * (cqlsh) encode input correctly when saving history +Merged from 2.1: - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969) * Avoid NPE when incremental repair fails (CASSANDRA-10909) http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/doc/cql3/CQL.textile -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c08aaf69/pylib/cqlshlib/cql3handling.py --
[01/14] cassandra git commit: Make it clear what timestamp_resolution is used for
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 6fe70c652 -> 725b9b1f7
refs/heads/cassandra-2.2 029b22e84 -> c08aaf69b
refs/heads/cassandra-3.0 0d30540f6 -> a598ebeef
refs/heads/trunk c227b928a -> 9adc6d820
Make it clear what timestamp_resolution is used for
Patch by marcuse; reviewed by Jeff Jirsa for CASSANDRA-11041
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b8408f06
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b8408f06
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b8408f06
Branch: refs/heads/cassandra-2.1
Commit: b8408f068bf2fc73f632d09239ba892a9835416f
Parents: 6fe70c6
Author: Marcus Eriksson
Authored: Wed Jan 20 08:58:05 2016 +0100
Committer: Marcus Eriksson
Committed: Tue Feb 9 07:08:22 2016 +0100
--
CHANGES.txt| 1 +
doc/cql3/CQL.textile | 2 +-
pylib/cqlshlib/cql3handling.py | 1 -
.../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++
4 files changed, 8 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 806e6d5..e5d6ff1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.14
+ * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041)
* Gossiper#isEnabled is not thread safe (CASSANDRA-6)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 3b69fcc..812a75e 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -347,7 +347,7 @@ The @compaction@ property must at least define the
@'class'@ sub-option, that de
| @bucket_low@ | SizeTieredCompactionStrategy| 0.5
| Size tiered consider sstables to be within the same bucket if their size
is within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the
default groups sstable whose sizes diverges by at most 50%)|
| @bucket_high@| SizeTieredCompactionStrategy| 1.5
| Size tiered consider sstables to be within the same bucket if their size
is within [average_size * @bucket_low@, average_size * @bucket_high@ ] (i.e the
default groups sstable whose sizes diverges by at most 50%).|
| @sstable_size_in_mb@ | LeveledCompactionStrategy | 5MB
| The target size (in MB) for sstables in the leveled strategy. Note that
while sstable sizes should stay less or equal to @sstable_size_in_mb@, it is
possible to exceptionally have a larger sstable as during compaction, data for
a given partition key are never split into 2 sstables|
-| @timestamp_resolution@ | DateTieredCompactionStrategy|
MICROSECONDS | The timestamp resolution used when inserting data, could be
MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit)|
+| @timestamp_resolution@ | DateTieredCompactionStrategy|
MICROSECONDS | The timestamp resolution used when inserting data, could be
MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit) -
don't change this unless you do mutations with USING TIMESTAMP
(or equivalent directly in the client)|
| @base_time_seconds@ | DateTieredCompactionStrategy| 60
| The base size of the time windows. |
| @max_sstable_age_days@ | DateTieredCompactionStrategy| 365
| SSTables only containing data that is older than this will never be
compacted. |
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 38f118f..029e0c7 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -470,7 +470,6 @@ def cf_prop_val_mapkey_completer(ctxt, cass):
elif csc == 'DateTieredCompactionStrategy':
opts.add('base_time_seconds')
opts.add('max_sstable_age_days')
-opts.add('timestamp_resolution')
opts.add('min_threshold')
opts.add('max_window_size_seconds')
return map(escape_value, opts)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b8408f06/src/java/org/apache/cassandra/db/compaction/DateTieredCompactionStrategyOptions.java
--
diff --git
a/src/java/org/apache/cassandra/db/compactio
[13/14] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a598ebee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a598ebee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a598ebee Branch: refs/heads/trunk Commit: a598ebeef47e7affa9d59d0bb95abe71447eed5b Parents: 0d30540 c08aaf6 Author: Marcus Eriksson Authored: Tue Feb 9 07:14:23 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:15:40 2016 +0100 -- CHANGES.txt| 1 + doc/cql3/CQL.textile | 2 +- pylib/cqlshlib/cql3handling.py | 1 - .../db/compaction/DateTieredCompactionStrategyOptions.java | 6 ++ 4 files changed, 8 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a598ebee/CHANGES.txt -- diff --cc CHANGES.txt index c6111e5,fdd1122..4074c66 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -8,45 -4,10 +8,46 @@@ Merged from 2.2.6 Merged from 2.1: * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) + * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) +3.0.3 + * Remove double initialization of newly added tables (CASSANDRA-11027) + * Filter keys searcher results by target range (CASSANDRA-11104) + * Fix deserialization of legacy read commands (CASSANDRA-11087) + * Fix incorrect computation of deletion time in sstable metadata (CASSANDRA-11102) + * Avoid memory leak when collecting sstable metadata (CASSANDRA-11026) + * Mutations do not block for completion under view lock contention (CASSANDRA-10779) + * Invalidate legacy schema tables when unloading them (CASSANDRA-11071) + * (cqlsh) handle INSERT and UPDATE statements with LWT conditions correctly + (CASSANDRA-11003) + * Fix DISTINCT queries in mixed version clusters (CASSANDRA-10762) + * Migrate build status for indexes along with legacy schema (CASSANDRA-11046) + * Ensure SSTables for legacy KEYS indexes can be read (CASSANDRA-11045) + * Added support for IBM zSystems architecture (CASSANDRA-11054) + * Update CQL documentation (CASSANDRA-10899) + * Check the column name, not cell name, for dropped columns when reading + legacy sstables (CASSANDRA-11018) + * Don't attempt to index clustering values of static rows (CASSANDRA-11021) + * Remove checksum files after replaying hints (CASSANDRA-10947) + * Support passing base table metadata to custom 2i validation (CASSANDRA-10924) + * Ensure stale index entries are purged during reads (CASSANDRA-11013) + * Fix AssertionError when removing from list using UPDATE (CASSANDRA-10954) + * Fix UnsupportedOperationException when reading old sstable with range + tombstone (CASSANDRA-10743) + * MV should use the maximum timestamp of the primary key (CASSANDRA-10910) + * Fix potential assertion error during compaction (CASSANDRA-10944) + * Fix counting of received sstables in streaming (CASSANDRA-10949) + * Implement hints compression (CASSANDRA-9428) + * Fix potential assertion error when reading static columns (CASSANDRA-10903) + * Avoid NoSuchElementException when executing empty batch (CASSANDRA-10711) + * Avoid building PartitionUpdate in toString (CASSANDRA-10897) + * Reduce heap spent when receiving many SSTables (CASSANDRA-10797) + * Add back support for 3rd party auth providers to bulk loader (CASSANDRA-10873) + * Eliminate the dependency on jgrapht for UDT resolution (CASSANDRA-10653) + * (Hadoop) Close Clusters and Sessions in Hadoop Input/Output classes (CASSANDRA-10837) + * Fix sstableloader not working with upper case keyspace name (CASSANDRA-10806) +Merged from 2.2: 2.2.5 * maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949) * Apply change to compaction throughput in real time (CASSANDRA-10025) http://git-wip-us.apache.org/repos/asf/cassandra/blob/a598ebee/doc/cql3/CQL.textile -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a598ebee/pylib/cqlshlib/cql3handling.py --
[06/14] cassandra git commit: fix CHANGES.txt after 2.1.13 release
fix CHANGES.txt after 2.1.13 release Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/725b9b1f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/725b9b1f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/725b9b1f Branch: refs/heads/cassandra-2.1 Commit: 725b9b1f7f16ff8ad8e77ad0f7679d39bc7f05b2 Parents: b8408f0 Author: Marcus Eriksson Authored: Tue Feb 9 07:09:54 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:09:54 2016 +0100 -- CHANGES.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/725b9b1f/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index e5d6ff1..72b3d59 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,11 +1,11 @@ 2.1.14 * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) + * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) 2.1.13 - * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969) * Avoid NPE when incremental repair fails (CASSANDRA-10909)
[05/14] cassandra git commit: fix CHANGES.txt after 2.1.13 release
fix CHANGES.txt after 2.1.13 release Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/725b9b1f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/725b9b1f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/725b9b1f Branch: refs/heads/trunk Commit: 725b9b1f7f16ff8ad8e77ad0f7679d39bc7f05b2 Parents: b8408f0 Author: Marcus Eriksson Authored: Tue Feb 9 07:09:54 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:09:54 2016 +0100 -- CHANGES.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/725b9b1f/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index e5d6ff1..72b3d59 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,11 +1,11 @@ 2.1.14 * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) + * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) 2.1.13 - * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969) * Avoid NPE when incremental repair fails (CASSANDRA-10909)
[07/14] cassandra git commit: fix CHANGES.txt after 2.1.13 release
fix CHANGES.txt after 2.1.13 release Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/725b9b1f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/725b9b1f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/725b9b1f Branch: refs/heads/cassandra-2.2 Commit: 725b9b1f7f16ff8ad8e77ad0f7679d39bc7f05b2 Parents: b8408f0 Author: Marcus Eriksson Authored: Tue Feb 9 07:09:54 2016 +0100 Committer: Marcus Eriksson Committed: Tue Feb 9 07:09:54 2016 +0100 -- CHANGES.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/725b9b1f/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index e5d6ff1..72b3d59 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,11 +1,11 @@ 2.1.14 * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) + * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) 2.1.13 - * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969) * Avoid NPE when incremental repair fails (CASSANDRA-10909)
[jira] [Updated] (CASSANDRA-11041) Make it clear what timestamp_resolution is used for with DTCS
[ https://issues.apache.org/jira/browse/CASSANDRA-11041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-11041: Reviewer: Jeff Jirsa > Make it clear what timestamp_resolution is used for with DTCS > - > > Key: CASSANDRA-11041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11041 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Labels: docs-impacting, dtcs > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > > We have had a few cases lately where users misunderstand what > timestamp_resolution does, we should; > * make the option not autocomplete in cqlsh > * update documentation > * log a warning -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11052) Cannot use Java 8 lambda expression inside UDF code body
[
https://issues.apache.org/jira/browse/CASSANDRA-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Bridges updated CASSANDRA-11052:
-
Attachment: 11052-2.patch
> Cannot use Java 8 lambda expression inside UDF code body
>
>
> Key: CASSANDRA-11052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11052
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: DOAN DuyHai
>Assignee: Robert Stupp
> Fix For: 3.x
>
> Attachments: 11052-2.patch, 11052.patch
>
>
> When creating the following **UDF** using Java 8 lambda syntax
> {code:sql}
> CREATE FUNCTION IF NOT EXISTS music.udf(state map, styles
> list)
> RETURNS NULL ON NULL INPUT
> RETURNS map
> LANGUAGE java
> AS $$
>styles.forEach((Object o) -> {
>String style = (String)o;
>if(state.containsKey(style)) {
> state.put(style, (Long)state.get(style)+1);
>} else {
> state.put(style, 1L);
>}
>});
>
>return state;
> $$;
> {code}
> I got the following exception:
> {code:java}
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Could
> not compile function 'music.udf' from Java source:
> org.apache.cassandra.exceptions.InvalidRequestException: Java source
> compilation failed:
> Line 2: The type java.util.function.Consumer cannot be resolved. It is
> indirectly referenced from required .class files
> Line 2: The method forEach(Consumer) from the type Iterable refers to the
> missing type Consumer
> Line 2: The target type of this expression must be a functional interface
> at
> com.datastax.driver.core.Responses$Error.asException(Responses.java:136)
> at
> com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:179)
> at
> com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:184)
> at
> com.datastax.driver.core.RequestHandler.access$2500(RequestHandler.java:43)
> at
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.setFinalResult(RequestHandler.java:798)
> at
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.onSet(RequestHandler.java:617)
> at
> com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:1005)
> at
> com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:928)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
> at
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:266)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:263)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> ... 1 more
> {code}
> It looks like the compiler requires importing java.util.Consumer but I have
> checked the source code and compiler options already support Java 8 source
> code so I'm pretty puzzled here ...
> /cc [~snazy]
--
This message was sent by Atl
[jira] [Commented] (CASSANDRA-9714) sstableloader appears to use the cassandra.yaml outgoing stream throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138292#comment-15138292 ] Yuki Morishita commented on CASSANDRA-9714: --- ||branch||testall||dtest|| |[9714-2.1|https://github.com/yukim/cassandra/tree/9714-2.1]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9714-2.1-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9714-2.1-dtest/lastCompletedBuild/testReport/]| |[9714-2.2|https://github.com/yukim/cassandra/tree/9714-2.2]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9714-2.2-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9714-2.2-dtest/lastCompletedBuild/testReport/]| |[9714-3.0|https://github.com/yukim/cassandra/tree/9714-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9714-3.0-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9714-3.0-dtest/lastCompletedBuild/testReport/]| |[9714-trunk|https://github.com/yukim/cassandra/tree/9714-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9714-trunk-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9714-trunk-dtest/lastCompletedBuild/testReport/]| Looks like sstableloader starts taking cassandra.yaml default after the change in CASSANDRA-7585. Patch fixes by explicitly assigning 0 to both streaming throughput and inter-dc streaming throughput. > sstableloader appears to use the cassandra.yaml outgoing stream throttle > > > Key: CASSANDRA-9714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9714 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jeremy Hanna >Assignee: Yuki Morishita > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > > When trying to use the sstableloader, we found (through the metrics in > opscenter) that the stream throughput was constant at about 24MB/s. We > didn't run it with the --throttle option so according to the help output and > the BulkLoader code it should be unthrottled. However when it was > unthrottled in the cassandra.yaml in the loader's classpath, it got up to the > low hundreds of MB/s.It sounds like when starting up it takes the > cassandra.yaml attributes and overrides the default throttle setting of the > loader. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9714) sstableloader appears to use the cassandra.yaml outgoing stream throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-9714: -- Fix Version/s: 3.x 3.0.x 2.2.x 2.1.x > sstableloader appears to use the cassandra.yaml outgoing stream throttle > > > Key: CASSANDRA-9714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9714 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jeremy Hanna >Assignee: Yuki Morishita > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > > When trying to use the sstableloader, we found (through the metrics in > opscenter) that the stream throughput was constant at about 24MB/s. We > didn't run it with the --throttle option so according to the help output and > the BulkLoader code it should be unthrottled. However when it was > unthrottled in the cassandra.yaml in the loader's classpath, it got up to the > low hundreds of MB/s.It sounds like when starting up it takes the > cassandra.yaml attributes and overrides the default throttle setting of the > loader. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-9714) sstableloader appears to use the cassandra.yaml outgoing stream throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita reassigned CASSANDRA-9714: - Assignee: Yuki Morishita > sstableloader appears to use the cassandra.yaml outgoing stream throttle > > > Key: CASSANDRA-9714 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9714 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jeremy Hanna >Assignee: Yuki Morishita > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x > > > When trying to use the sstableloader, we found (through the metrics in > opscenter) that the stream throughput was constant at about 24MB/s. We > didn't run it with the --throttle option so according to the help output and > the BulkLoader code it should be unthrottled. However when it was > unthrottled in the cassandra.yaml in the loader's classpath, it got up to the > low hundreds of MB/s.It sounds like when starting up it takes the > cassandra.yaml attributes and overrides the default throttle setting of the > loader. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[cassandra] Git Push Summary
Repository: cassandra Updated Tags: refs/tags/3.3-tentative [deleted] 5669c6967
[cassandra] Git Push Summary
Repository: cassandra Updated Tags: refs/tags/cassandra-3.3 [created] d92d8c429
[jira] [Commented] (CASSANDRA-8180) Optimize disk seek using min/max column name meta data when the LIMIT clause is used
[
https://issues.apache.org/jira/browse/CASSANDRA-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138226#comment-15138226
]
Stefania commented on CASSANDRA-8180:
-
Thanks for the review Branimir!
The patch for trunk is
[here|https://github.com/stef1927/cassandra/commits/8180], rebased and squashed.
Launched one more CI round, if all good will move the ticket to ready to commit:
||trunk||
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-8180-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-8180-dtest/]|
> Optimize disk seek using min/max column name meta data when the LIMIT clause
> is used
>
>
> Key: CASSANDRA-8180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8180
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
> Environment: Cassandra 2.0.10
>Reporter: DOAN DuyHai
>Assignee: Stefania
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 8180_001.yaml, 8180_002.yaml
>
>
> I was working on an example of sensor data table (timeseries) and face a use
> case where C* does not optimize read on disk.
> {code}
> cqlsh:test> CREATE TABLE test(id int, col int, val text, PRIMARY KEY(id,col))
> WITH CLUSTERING ORDER BY (col DESC);
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 10, '10');
> ...
> >nodetool flush test test
> ...
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 20, '20');
> ...
> >nodetool flush test test
> ...
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 30, '30');
> ...
> >nodetool flush test test
> {code}
> After that, I activate request tracing:
> {code}
> cqlsh:test> SELECT * FROM test WHERE id=1 LIMIT 1;
> activity |
> timestamp| source| source_elapsed
> ---+--+---+
> execute_cql3_query |
> 23:48:46,498 | 127.0.0.1 | 0
> Parsing SELECT * FROM test WHERE id=1 LIMIT 1; |
> 23:48:46,498 | 127.0.0.1 | 74
>Preparing statement |
> 23:48:46,499 | 127.0.0.1 |253
> Executing single-partition query on test |
> 23:48:46,499 | 127.0.0.1 |930
> Acquiring sstable references |
> 23:48:46,499 | 127.0.0.1 |943
>Merging memtable tombstones |
> 23:48:46,499 | 127.0.0.1 | 1032
>Key cache hit for sstable 3 |
> 23:48:46,500 | 127.0.0.1 | 1160
>Seeking to partition beginning in data file |
> 23:48:46,500 | 127.0.0.1 | 1173
>Key cache hit for sstable 2 |
> 23:48:46,500 | 127.0.0.1 | 1889
>Seeking to partition beginning in data file |
> 23:48:46,500 | 127.0.0.1 | 1901
>Key cache hit for sstable 1 |
> 23:48:46,501 | 127.0.0.1 | 2373
>Seeking to partition beginning in data file |
> 23:48:46,501 | 127.0.0.1 | 2384
> Skipped 0/3 non-slice-intersecting sstables, included 0 due to tombstones |
> 23:48:46,501 | 127.0.0.1 | 2768
> Merging data from memtables and 3 sstables |
> 23:48:46,501 | 127.0.0.1 | 2784
> Read 2 live and 0 tombstoned cells |
> 23:48:46,501 | 127.0.0.1 | 2976
> Request complete |
> 23:48:46,501 | 127.0.0.1 | 3551
> {code}
> We can clearly see that C* hits 3 SSTables on disk instead of just one,
> although it has the min/max column meta data to decide which SSTable contains
> the most recent data.
> Funny enough, if we add a clause on the clustering column to the select, this
> time C* optimizes the read path:
> {code}
> cqlsh:test> SELECT * FROM test WHERE id=1 AND col > 25 LIMIT 1;
> activity |
> timestamp| source| source_elapsed
> ---+--+---+
> execute_cql3_query |
> 23:52:31,888 | 127.0.0.1 | 0
>Parsing SELECT *
[jira] [Commented] (CASSANDRA-11090) Hinted Handoff loop
[ https://issues.apache.org/jira/browse/CASSANDRA-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138157#comment-15138157 ] Blake Eggleston commented on CASSANDRA-11090: - ah I missed that. +1 then > Hinted Handoff loop > --- > > Key: CASSANDRA-11090 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11090 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0.x, 3.x > > > After the hints executor finishes sending hints, another hints file is > created for the same host, which is then processed on the next go around. > This continues indefinitely. The new hint files are empty, so there shouldn't > be any network traffic. However, there's still unnecessary hint activity, and > the hint crc file isn't deleted in the 3.0 branch after hints are dispatched > (but is in trunk), so any hint activity will trigger ~8640 files being > created per day until the node is restarted. Restarting the node fixes the > problem, after the existing hint files are processed. > This can be duplicated on cassandra-3.0 to trunk with this script: > https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11082) netty's level hadn't prevent OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138147#comment-15138147 ] fujian edited comment on CASSANDRA-11082 at 2/9/16 12:58 AM: - The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. In other words, it is best practice for safe system though it is low ratio to happen. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. [~tjake] [~slebresne] WDYT? And Can I apply one patch for the solution? 3ks. Jian was (Author: fujian1115): The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. [~tjake] [~slebresne] WDYT? And Can I apply one patch for the solution? 3ks. Jian > netty's level hadn't prevent OOM when receiver handle slow. > --- > > Key: CASSANDRA-11082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11082 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: fujian > > as we know, netty will OOM when received client is slow. > due to if receiver can't handle response fast so that cassandra server can't > flush data. it will cause channeloutbuffer with big size. > we see the cassandra had configure write high/low water level, but I can't > found any code to judge iswritable. so it will have possible OOM > why cassandra hadn't handle this case? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11082) netty's level hadn't prevent OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138147#comment-15138147 ] fujian edited comment on CASSANDRA-11082 at 2/9/16 12:56 AM: - The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. [~tjake] WDYT? And Can I apply one patch for it? 3ks. Jian was (Author: fujian1115): The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. [~tjake]WDYT? And Can I apply one patch for it? 3ks. Jian > netty's level hadn't prevent OOM when receiver handle slow. > --- > > Key: CASSANDRA-11082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11082 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: fujian > > as we know, netty will OOM when received client is slow. > due to if receiver can't handle response fast so that cassandra server can't > flush data. it will cause channeloutbuffer with big size. > we see the cassandra had configure write high/low water level, but I can't > found any code to judge iswritable. so it will have possible OOM > why cassandra hadn't handle this case? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11082) netty's level hadn't prevent OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138147#comment-15138147 ] fujian edited comment on CASSANDRA-11082 at 2/9/16 12:57 AM: - The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. [~tjake] [~slebresne] WDYT? And Can I apply one patch for the solution? 3ks. Jian was (Author: fujian1115): The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. [~tjake] WDYT? And Can I apply one patch for it? 3ks. Jian > netty's level hadn't prevent OOM when receiver handle slow. > --- > > Key: CASSANDRA-11082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11082 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: fujian > > as we know, netty will OOM when received client is slow. > due to if receiver can't handle response fast so that cassandra server can't > flush data. it will cause channeloutbuffer with big size. > we see the cassandra had configure write high/low water level, but I can't > found any code to judge iswritable. so it will have possible OOM > why cassandra hadn't handle this case? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11082) netty's level hadn't prevent OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138147#comment-15138147 ] fujian edited comment on CASSANDRA-11082 at 2/9/16 12:56 AM: - The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. [~tjake]WDYT? And Can I apply one patch for it? 3ks. Jian was (Author: fujian1115): The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. WDYT? And Can I apply one patch for it? 3ks. Jian > netty's level hadn't prevent OOM when receiver handle slow. > --- > > Key: CASSANDRA-11082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11082 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: fujian > > as we know, netty will OOM when received client is slow. > due to if receiver can't handle response fast so that cassandra server can't > flush data. it will cause channeloutbuffer with big size. > we see the cassandra had configure write high/low water level, but I can't > found any code to judge iswritable. so it will have possible OOM > why cassandra hadn't handle this case? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11082) netty's level hadn't prevent OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138147#comment-15138147 ] fujian edited comment on CASSANDRA-11082 at 2/9/16 12:55 AM: - The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. WDYT? And Can I apply one patch for it? 3ks. Jian was (Author: fujian1115): The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. WDYT? And Can I apply one patch for it? 3ks. Jian > netty's level hadn't prevent OOM when receiver handle slow. > --- > > Key: CASSANDRA-11082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11082 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: fujian > > as we know, netty will OOM when received client is slow. > due to if receiver can't handle response fast so that cassandra server can't > flush data. it will cause channeloutbuffer with big size. > we see the cassandra had configure write high/low water level, but I can't > found any code to judge iswritable. so it will have possible OOM > why cassandra hadn't handle this case? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11082) netty's level hadn't prevent OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138147#comment-15138147 ] fujian commented on CASSANDRA-11082: The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. WDYT? Can I apply one patch for it? 3ks. Jian > netty's level hadn't prevent OOM when receiver handle slow. > --- > > Key: CASSANDRA-11082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11082 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: fujian > > as we know, netty will OOM when received client is slow. > due to if receiver can't handle response fast so that cassandra server can't > flush data. it will cause channeloutbuffer with big size. > we see the cassandra had configure write high/low water level, but I can't > found any code to judge iswritable. so it will have possible OOM > why cassandra hadn't handle this case? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11137) JSON datetime formatting needs timezone
Stefania created CASSANDRA-11137:
Summary: JSON datetime formatting needs timezone
Key: CASSANDRA-11137
URL: https://issues.apache.org/jira/browse/CASSANDRA-11137
Project: Cassandra
Issue Type: Improvement
Components: CQL
Reporter: Stefania
The JSON date time string representation lacks the timezone information:
{code}
cqlsh:events> select toJson(created_at) AS created_at from
event_by_patient_timestamp ;
created_at
---
"2016-01-04 16:05:47.123"
(1 rows)
{code}
vs.
{code}
cqlsh:events> select created_at FROM event_by_user_timestamp ;
created_at
--
2016-01-04 15:05:47+
(1 rows)
cqlsh:events>
{code}
To make things even more complicated the JSON timestamp is not returned in UTC.
At the moment {{DateType}} picks this formatting string {{"-MM-dd
HH:mm:ss.SSS"}}. Shouldn't we somehow make this configurable by users or at a
minimum add the timezone?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-11082) netty's level hadn't prevent OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138147#comment-15138147 ] fujian edited comment on CASSANDRA-11082 at 2/9/16 12:54 AM: - The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. WDYT? And Can I apply one patch for it? 3ks. Jian was (Author: fujian1115): The case is corner but it can happen if I write one driver to send lots of requests without read any response. so it is one protect method to prevent similar cases though it is very hard to happen such as slow clients. there are three solutions for it: (1) just check isWritable() and if the value is false, drop the response. it is safe but it is rude. (2) just check isWritable() and if the value is false, close the channel. if use this solution, if the high water mark is set low it maybe be confused with big data response. (3) just check isWritable() and if the value is false, set AutoRead to false so that the client can slow down and can't send request at last. WDYT? Can I apply one patch for it? 3ks. Jian > netty's level hadn't prevent OOM when receiver handle slow. > --- > > Key: CASSANDRA-11082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11082 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: fujian > > as we know, netty will OOM when received client is slow. > due to if receiver can't handle response fast so that cassandra server can't > flush data. it will cause channeloutbuffer with big size. > we see the cassandra had configure write high/low water level, but I can't > found any code to judge iswritable. so it will have possible OOM > why cassandra hadn't handle this case? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7276) Include keyspace and table names in logs where possible
[
https://issues.apache.org/jira/browse/CASSANDRA-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anubhav Kale updated CASSANDRA-7276:
Attachment: 0001-Better-Logging-for-KS-CF.patch
Attached first cut of this.
With current approach, I have omitted BatchLog*VerbHandler and
Repair*VerbHandler since they operate on Collection of mutations. This would
mean we change the interface to collection of KS, instead of just the KS as
originally suggested. We can do that, but we may lose the goal we are after
here if MessageDeliveryTask simply prints a collection of KS and CF when
something goes wrong.
I took a stab at manually updating log stmts in KFS and CompactionManager. We
can add logs in other places later once this first pass is committed (to keep
merges sane).
Also, there is a possibility of introducing a base class for
IKeyspaceAwareVerbHandler but I did not do that for readability sake (else the
tree starts getting too deep).
In logs, should we use KS and CF or Keyspace and Table ? I don't believe there
is a consistent pattern as such.
> Include keyspace and table names in logs where possible
> ---
>
> Key: CASSANDRA-7276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7276
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tyler Hobbs
>Priority: Minor
> Labels: bootcamp, lhf
> Fix For: 2.1.x
>
> Attachments: 0001-Better-Logging-for-KS-CF.patch,
> 2.1-CASSANDRA-7276-v1.txt, cassandra-2.1-7276-compaction.txt,
> cassandra-2.1-7276.txt, cassandra-2.1.9-7276-v2.txt, cassandra-2.1.9-7276.txt
>
>
> Most error messages and stacktraces give you no clue as to what keyspace or
> table was causing the problem. For example:
> {noformat}
> ERROR [MutationStage:61648] 2014-05-20 12:05:45,145 CassandraDaemon.java
> (line 198) Exception in thread Thread[MutationStage:61648,5,main]
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Unknown Source)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:63)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:98)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap$1.compareTo(SnapTreeMap.java:538)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1108)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.updateUnderRoot(SnapTreeMap.java:1059)
> at edu.stanford.ppl.concurrent.SnapTreeMap.update(SnapTreeMap.java:1023)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.putIfAbsent(SnapTreeMap.java:985)
> at
> org.apache.cassandra.db.AtomicSortedColumns$Holder.addColumn(AtomicSortedColumns.java:328)
> at
> org.apache.cassandra.db.AtomicSortedColumns.addAllWithSizeDelta(AtomicSortedColumns.java:200)
> at org.apache.cassandra.db.Memtable.resolve(Memtable.java:226)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:173)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:893)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:333)
> at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:206)
> at
> org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:56)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> We should try to include info on the keyspace and column family in the error
> messages or logs whenever possible. This includes reads, writes,
> compactions, flushes, repairs, and probably more.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11090) Hinted Handoff loop
[
https://issues.apache.org/jira/browse/CASSANDRA-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138023#comment-15138023
]
Aleksey Yeschenko commented on CASSANDRA-11090:
---
I could, but it would change the semantics around closing the current writer.
Right now we only close in {{flush()}} if we are forced to switch the writer if
it exceeds the max configured hint file size. With this change, we would do it
unconditionally.
> Hinted Handoff loop
> ---
>
> Key: CASSANDRA-11090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11090
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> After the hints executor finishes sending hints, another hints file is
> created for the same host, which is then processed on the next go around.
> This continues indefinitely. The new hint files are empty, so there shouldn't
> be any network traffic. However, there's still unnecessary hint activity, and
> the hint crc file isn't deleted in the 3.0 branch after hints are dispatched
> (but is in trunk), so any hint activity will trigger ~8640 files being
> created per day until the node is restarted. Restarting the node fixes the
> problem, after the existing hint files are processed.
> This can be duplicated on cassandra-3.0 to trunk with this script:
> https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10767) Checking version of Cassandra command creates `cassandra.logdir_IS_UNDEFINED/`
[
https://issues.apache.org/jira/browse/CASSANDRA-10767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138008#comment-15138008
]
Yuki Morishita commented on CASSANDRA-10767:
I ended up only fixing cassandra scripts for both *nix/windows.
Scripts for others are fixed in CASSANDRA-10679. (For 3.0+, and since this is
not a big deal, I don't think we need to backport it.)
||branch||testall||dtest||
|[10767-2.1|https://github.com/yukim/cassandra/tree/10767-2.1]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10767-2.1-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10767-2.1-dtest/lastCompletedBuild/testReport/]|
|[10767-2.2|https://github.com/yukim/cassandra/tree/10767-2.2]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10767-2.2-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10767-2.2-dtest/lastCompletedBuild/testReport/]|
|[10767-3.0|https://github.com/yukim/cassandra/tree/10767-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10767-3.0-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10767-3.0-dtest/lastCompletedBuild/testReport/]|
|[10767-trunk|https://github.com/yukim/cassandra/tree/10767-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10767-trunk-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-10767-trunk-dtest/lastCompletedBuild/testReport/]|
> Checking version of Cassandra command creates `cassandra.logdir_IS_UNDEFINED/`
> --
>
> Key: CASSANDRA-10767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10767
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: $ cassandra -v
>
> 2.1.2
> MacOSX 10.9.5
> $ brew info cassandra
> [14:15:41]
> cassandra: stable 2.2.3 (bottled)
> Eventually consistent, distributed key-value store
> https://cassandra.apache.org
> /usr/local/Cellar/cassandra/2.1.2 (3975 files, 92M) *
> Built from source
> From:
> https://github.com/Homebrew/homebrew/blob/master/Library/Formula/cassandra.rb
> ==> Caveats
> To have launchd start cassandra at login:
> ln -sfv /usr/local/opt/cassandra/*.plist ~/Library/LaunchAgents
> Then to load cassandra now:
> launchctl load ~/Library/LaunchAgents/homebrew.mxcl.cassandra.plist
>Reporter: Jens Rantil
>Assignee: Yuki Morishita
>Priority: Trivial
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> When I execute `cassandra -v` on the terminal the directory
> `cassandra.logdir_IS_UNDEFINED` is created in my CWD:
> {noformat}
> $ tree cassandra.logdir_IS_UNDEFINED
> cassandra.logdir_IS_UNDEFINED
> └── system.log
> 0 directories, 1 file
> {noformat}
> Expected: That no log file nor directory is created when I'm simply checking
> the version of Cassandra. Feels a bit ridiculous.
> Additionals: Just double checking, is this a bundling issue that should be
> reported to Homebrew? Probably not, right?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11090) Hinted Handoff loop
[
https://issues.apache.org/jira/browse/CASSANDRA-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138007#comment-15138007
]
Blake Eggleston commented on CASSANDRA-11090:
-
Functionally, this is fine, but could you're checking iterator.hasNext twice.
Could you move the flushInternal call under the original hasNext check? So it
looks like this:
{code}
if (!iterator.hasNext())
break;
flushInternal(iterator, store);
{code}
> Hinted Handoff loop
> ---
>
> Key: CASSANDRA-11090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11090
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> After the hints executor finishes sending hints, another hints file is
> created for the same host, which is then processed on the next go around.
> This continues indefinitely. The new hint files are empty, so there shouldn't
> be any network traffic. However, there's still unnecessary hint activity, and
> the hint crc file isn't deleted in the 3.0 branch after hints are dispatched
> (but is in trunk), so any hint activity will trigger ~8640 files being
> created per day until the node is restarted. Restarting the node fixes the
> problem, after the existing hint files are processed.
> This can be duplicated on cassandra-3.0 to trunk with this script:
> https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6719) redesign loadnewsstables
[ https://issues.apache.org/jira/browse/CASSANDRA-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-6719: -- Reviewer: Yuki Morishita > redesign loadnewsstables > > > Key: CASSANDRA-6719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6719 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Jonathan Ellis >Priority: Minor > Labels: lhf > Fix For: 3.x > > Attachments: 6719.patch > > > CFSMBean.loadNewSSTables scans data directories for new sstables dropped > there by an external agent. This is dangerous because of possible filename > conflicts with existing or newly generated sstables. > Instead, we should support leaving the new sstables in a separate directory > (specified by a parameter, or configured as a new location in yaml) and take > care of renaming as necessary automagically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6719) redesign loadnewsstables
[ https://issues.apache.org/jira/browse/CASSANDRA-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137997#comment-15137997 ] Yuki Morishita commented on CASSANDRA-6719: --- [~cngupte] Sorry for not responding this one for awhile. Are you still interested in working? Regarding your question, 1. Yes, you should take care of those as well all the way to nodetool. 2. For now, I want to keep current JXM API and behavior as they are, but with warning message for your new API/behavior. If you can still work, can you rebase your patch on top of current trunk? I looked at your current work, and I think you are going in the right direction. > redesign loadnewsstables > > > Key: CASSANDRA-6719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6719 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Jonathan Ellis >Priority: Minor > Labels: lhf > Fix For: 3.x > > Attachments: 6719.patch > > > CFSMBean.loadNewSSTables scans data directories for new sstables dropped > there by an external agent. This is dangerous because of possible filename > conflicts with existing or newly generated sstables. > Instead, we should support leaving the new sstables in a separate directory > (specified by a parameter, or configured as a new location in yaml) and take > care of renaming as necessary automagically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7276) Include keyspace and table names in logs where possible
[
https://issues.apache.org/jira/browse/CASSANDRA-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137825#comment-15137825
]
Anubhav Kale commented on CASSANDRA-7276:
-
I will take a stab at this.
> Include keyspace and table names in logs where possible
> ---
>
> Key: CASSANDRA-7276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7276
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tyler Hobbs
>Priority: Minor
> Labels: bootcamp, lhf
> Fix For: 2.1.x
>
> Attachments: 2.1-CASSANDRA-7276-v1.txt,
> cassandra-2.1-7276-compaction.txt, cassandra-2.1-7276.txt,
> cassandra-2.1.9-7276-v2.txt, cassandra-2.1.9-7276.txt
>
>
> Most error messages and stacktraces give you no clue as to what keyspace or
> table was causing the problem. For example:
> {noformat}
> ERROR [MutationStage:61648] 2014-05-20 12:05:45,145 CassandraDaemon.java
> (line 198) Exception in thread Thread[MutationStage:61648,5,main]
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Unknown Source)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:63)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:98)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap$1.compareTo(SnapTreeMap.java:538)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1108)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.updateUnderRoot(SnapTreeMap.java:1059)
> at edu.stanford.ppl.concurrent.SnapTreeMap.update(SnapTreeMap.java:1023)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.putIfAbsent(SnapTreeMap.java:985)
> at
> org.apache.cassandra.db.AtomicSortedColumns$Holder.addColumn(AtomicSortedColumns.java:328)
> at
> org.apache.cassandra.db.AtomicSortedColumns.addAllWithSizeDelta(AtomicSortedColumns.java:200)
> at org.apache.cassandra.db.Memtable.resolve(Memtable.java:226)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:173)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:893)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:333)
> at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:206)
> at
> org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:56)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> We should try to include info on the keyspace and column family in the error
> messages or logs whenever possible. This includes reads, writes,
> compactions, flushes, repairs, and probably more.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9945) Add transparent data encryption core classes
[ https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137406#comment-15137406 ] Jason Brown commented on CASSANDRA-9945: [~jeffl] I'm waiting on several more patches to be reviewed so more of the functionality can be complete (CASSANDRA-9633, CASSANDRA-11040), plus one or two more I need to open source. > Add transparent data encryption core classes > > > Key: CASSANDRA-9945 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9945 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown > Labels: encryption > Fix For: 3.2 > > > This patch will add the core infrastructure classes necessary for transparent > data encryption (file-level encryption), as required for CASSANDRA-6018 and > CASSANDRA-9633. The phrase "transparent data encryption", while not the most > aesthetically pleasing, seems to be used throughout the database industry > (Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption, > so we'll go with that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9945) Add transparent data encryption core classes
[ https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137372#comment-15137372 ] Jeff Liu commented on CASSANDRA-9945: - Thanks, [~jjordan], do you know when should I expect the transparent encryption to be fully available? we have some business requirement that comes in later this year that requires encryption for data at rest. I'm trying to align up the schedule. > Add transparent data encryption core classes > > > Key: CASSANDRA-9945 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9945 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown > Labels: encryption > Fix For: 3.2 > > > This patch will add the core infrastructure classes necessary for transparent > data encryption (file-level encryption), as required for CASSANDRA-6018 and > CASSANDRA-9633. The phrase "transparent data encryption", while not the most > aesthetically pleasing, seems to be used throughout the database industry > (Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption, > so we'll go with that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11090) Hinted Handoff loop
[ https://issues.apache.org/jira/browse/CASSANDRA-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137343#comment-15137343 ] Aleksey Yeschenko commented on CASSANDRA-11090: --- Pushed a simple fix here - checking for iterator emptiness before proceeding to create a file. ||branch||testall||dtest|| |[11090-3.0|https://github.com/iamaleksey/cassandra/tree/11090-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-11090-3.0-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-11090-3.0-dtest]| |[11090-3.4|https://github.com/iamaleksey/cassandra/tree/11090-3.4]|[testall|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-11090-3.4-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/iamaleksey/job/iamaleksey-11090-3.4-dtest]| > Hinted Handoff loop > --- > > Key: CASSANDRA-11090 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11090 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0.x, 3.x > > > After the hints executor finishes sending hints, another hints file is > created for the same host, which is then processed on the next go around. > This continues indefinitely. The new hint files are empty, so there shouldn't > be any network traffic. However, there's still unnecessary hint activity, and > the hint crc file isn't deleted in the 3.0 branch after hints are dispatched > (but is in trunk), so any hint activity will trigger ~8640 files being > created per day until the node is restarted. Restarting the node fixes the > problem, after the existing hint files are processed. > This can be duplicated on cassandra-3.0 to trunk with this script: > https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11128) Unexpected exception during request; AssertionError: null
[
https://issues.apache.org/jira/browse/CASSANDRA-11128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137309#comment-15137309
]
Russ Hatch commented on CASSANDRA-11128:
[~slebresne] I suspect it's not a regression, but on 3.0.2 there's another
issue cropping up earlier in the test run that could be masking
(CASSANDRA-10612, possibly a test problem(?), not certain at this point).
> Unexpected exception during request; AssertionError: null
> -
>
> Key: CASSANDRA-11128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11128
> Project: Cassandra
> Issue Type: Bug
>Reporter: Russ Hatch
> Fix For: 3.0.x
>
>
> Post upgrade from 2.1 to 3.0.3 (3.0.3-tentative) I'm intermittently seeing
> this exception:
> {noformat}
> ['ERROR [SharedPool-Worker-3] 2016-02-05 22:38:08,444 Message.java:611 -
> Unexpected exception during request; channel = [id: 0xb5fa21d0,
> /127.0.0.1:46096 => /127.0.0.1:9042]\njava.lang.AssertionError: null
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:619)
> ~[main/:na]
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:523)
> ~[main/:na]
> at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:166)
> ~[main/:na]
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:72)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:609)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:758)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:701)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendRRWithFailure(MessagingService.java:684)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor.makeRequests(AbstractReadExecutor.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor.makeDataRequests(AbstractReadExecutor.java:85)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor$SpeculatingReadExecutor.executeAsync(AbstractReadExecutor.java:264)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.doInitialQueries(StorageProxy.java:1689)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1644)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1591)
> ~[main/:na]
> at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1510)
> ~[main/:na]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.execute(SinglePartitionReadCommand.java:302)
> ~[main/:na]
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:67)
> ~[main/:na]
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:34)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:302)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:338)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:214)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:472)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:449)
> ~[main/:na]
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
> ~[main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
> [main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
> [main/:na]
> 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_51]
> at
> org.apache.cassandra.concurrent.AbstractLocal
[jira] [Updated] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-9633: --- Reviewer: Blake Eggleston > Add ability to encrypt sstables > --- > > Key: CASSANDRA-9633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9633 > Project: Cassandra > Issue Type: New Feature >Reporter: Jason Brown >Assignee: Jason Brown > Labels: encryption, security, sstable > Fix For: 3.x > > > Add option to allow encrypting of sstables. > I have a version of this functionality built on cassandra 2.0 that > piggy-backs on the existing sstable compression functionality and ICompressor > interface (similar in nature to what DataStax Enterprise does). However, if > we're adding the feature to the main OSS product, I'm not sure if we want to > use the pluggable compression framework or if it's worth investigating a > different path. I think there's a lot of upside in reusing the sstable > compression scheme, but perhaps add a new component in cqlsh for table > encryption and a corresponding field in CFMD. > Encryption configuration in the yaml can use the same mechanism as > CASSANDRA-6018 (which is currently pending internal review). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11076) LEAK detected after bootstrapping a new node
[
https://issues.apache.org/jira/browse/CASSANDRA-11076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson resolved CASSANDRA-11076.
-
Resolution: Cannot Reproduce
Fix Version/s: (was: 3.0.x)
ok, cannot reproduce, reopen if the test starts failing again
> LEAK detected after bootstrapping a new node
>
>
> Key: CASSANDRA-11076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11076
> Project: Cassandra
> Issue Type: Bug
>Reporter: Eduard Tudenhoefner
>Assignee: Marcus Eriksson
>
> Sequence of events:
> * start up a 2 node cluster
> * bootstrap one additional node so that the cluster consists of 3 nodes in
> total
> * the bootstrapped node will contain the LEAK error in the log file
> {code}
> INFO [main] 2016-01-26 10:59:06,206 Server.java:162 - Starting listening
> for CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2016-01-26 10:59:06,269 ThriftServer.java:119 - Binding thrift
> service to /0.0.0.0:9160
> INFO [Thread-6] 2016-01-26 10:59:06,280 ThriftServer.java:136 - Listening
> for thrift clients...
> INFO [HANDSHAKE-/10.200.178.183] 2016-01-26 10:59:06,703
> OutboundTcpConnection.java:503 - Handshaking version with /10.200.178.183
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,079
> StorageService.java:1099 - rebuild from dc: (any dc)
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,090
> RangeStreamer.java:339 - Some ranges of
> [(-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] are already available. Skipping
> streaming those ranges.
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,091
> RangeStreamer.java:339 - Some ranges of
> [(-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] are already available. Skipping
> streaming those ranges.
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,092
> RangeStreamer.java:339 - Some ranges of
> [(3074457345618258602,-9223372036854775808],
> (-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] are already available. Skipping
> streaming those ranges.
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,093
> RangeStreamer.java:339 - Some ranges of
> [(3074457345618258602,-9223372036854775808],
> (-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] are already available. Skipping
> streaming those ranges.
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,094
> StreamResultFuture.java:86 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Executing streaming plan for Rebuild
> INFO [StreamConnectionEstablisher:3] 2016-01-26 10:59:20,095
> StreamSession.java:238 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Starting streaming to /10.200.178.185
> INFO [StreamConnectionEstablisher:4] 2016-01-26 10:59:20,096
> StreamSession.java:238 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Starting streaming to /10.200.178.193
> INFO [StreamConnectionEstablisher:4] 2016-01-26 10:59:20,097
> StreamCoordinator.java:213 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03,
> ID#0] Beginning stream session with /10.200.178.193
> INFO [StreamConnectionEstablisher:3] 2016-01-26 10:59:20,098
> StreamCoordinator.java:213 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03,
> ID#0] Beginning stream session with /10.200.178.185
> INFO [STREAM-IN-/10.200.178.185] 2016-01-26 10:59:20,102
> StreamResultFuture.java:182 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Session with /10.200.178.185 is complete
> INFO [STREAM-IN-/10.200.178.193] 2016-01-26 10:59:20,359
> StreamResultFuture.java:182 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Session with /10.200.178.193 is complete
> INFO [STREAM-IN-/10.200.178.193] 2016-01-26 10:59:20,362
> StreamResultFuture.java:214 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> All sessions completed
> ERROR [Reference-Reaper:1] 2016-01-26 11:00:39,410 Ref.java:197 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@1c7d1dcf) to @2011417651 was
> not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2016-01-26 11:00:39,411 Ref.java:228 - Allocate
> trace org.apache.cassandra.utils.concurrent.Ref$State@1c7d1dcf:
> Thread[SharedPool-Worker-6,5,main]
> at java.lang.Thread.getStackTrace(Thread.java:1552)
> at org.apache.cassandra.utils.concurrent.Ref$Debug.(Ref.java:218)
> at org.apache.cassandra.utils.concurrent.Ref$State.(Ref.java:148)
> at org.apache.cassandra.utils.concurrent.Ref.(Ref.java:70)
> at
> org.apache.cassandra.utils.memory.BufferPool$Chunk.setAttachment(BufferPool.java:646)
> a
[jira] [Commented] (CASSANDRA-11099) Prepared metadata does not include CAS applied column
[ https://issues.apache.org/jira/browse/CASSANDRA-11099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137298#comment-15137298 ] Chris Bannister commented on CASSANDRA-11099: - I realised when I started looking into the returned metadata that is not as simple as I had thought. I would be great to have fixed for protocol 5 though. Another option to mitigate is that if a client requests skip_metadata for a CAS statement Cassandra should ignore it and return the result metadata, this shouldn't be breaking. > Prepared metadata does not include CAS applied column > - > > Key: CASSANDRA-11099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11099 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Bannister >Priority: Minor > Labels: protocolv5 > > When executing a CAS statement the first column is the [applied] boolean > column indicating success, but when preparing it does get returned. This > means that clients can not cache the prepared statement result metadata to > use instead of the execute metadata. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11090) Hinted Handoff loop
[ https://issues.apache.org/jira/browse/CASSANDRA-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-11090: -- Reviewer: Blake Eggleston > Hinted Handoff loop > --- > > Key: CASSANDRA-11090 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11090 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0.x, 3.x > > > After the hints executor finishes sending hints, another hints file is > created for the same host, which is then processed on the next go around. > This continues indefinitely. The new hint files are empty, so there shouldn't > be any network traffic. However, there's still unnecessary hint activity, and > the hint crc file isn't deleted in the 3.0 branch after hints are dispatched > (but is in trunk), so any hint activity will trigger ~8640 files being > created per day until the node is restarted. Restarting the node fixes the > problem, after the existing hint files are processed. > This can be duplicated on cassandra-3.0 to trunk with this script: > https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9967) Determine if a Materialized View is finished building, without having to query each node
[ https://issues.apache.org/jira/browse/CASSANDRA-9967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-9967: --- Assignee: Carl Yeksigian > Determine if a Materialized View is finished building, without having to > query each node > > > Key: CASSANDRA-9967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9967 > Project: Cassandra > Issue Type: New Feature >Reporter: Alan Boudreault >Assignee: Carl Yeksigian >Priority: Minor > Labels: lhf > Fix For: 3.x > > > Since MVs are eventually consistent with its base table, It would nice if we > could easily know the state of the MV after its creation, so we could wait > until the MV is built before doing some operations. > // cc [~mbroecheler] [~tjake] [~carlyeks] [~enigmacurry] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11090) Hinted Handoff loop
[ https://issues.apache.org/jira/browse/CASSANDRA-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-11090: -- Priority: Minor (was: Major) > Hinted Handoff loop > --- > > Key: CASSANDRA-11090 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11090 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0.x, 3.x > > > After the hints executor finishes sending hints, another hints file is > created for the same host, which is then processed on the next go around. > This continues indefinitely. The new hint files are empty, so there shouldn't > be any network traffic. However, there's still unnecessary hint activity, and > the hint crc file isn't deleted in the 3.0 branch after hints are dispatched > (but is in trunk), so any hint activity will trigger ~8640 files being > created per day until the node is restarted. Restarting the node fixes the > problem, after the existing hint files are processed. > This can be duplicated on cassandra-3.0 to trunk with this script: > https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10697) Leak detected while running offline scrub
[
https://issues.apache.org/jira/browse/CASSANDRA-10697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-10697:
-
Assignee: Marcus Eriksson
> Leak detected while running offline scrub
> -
>
> Key: CASSANDRA-10697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10697
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: C* 2.1.9 on Debian Wheezy
>Reporter: mlowicki
>Assignee: Marcus Eriksson
>Priority: Critical
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> I got couple of those:
> {code}
> ERROR 05:09:15 LEAK DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@3b60e162) to class
> org.apache.cassandra.io.sstable.SSTableReader$InstanceTidier@1433208674:/var/lib/cassandra/data/sync/entity2-e24b5040199b11e5a30f75bb514ae072/sync-entity2-ka-405434
> was not released before the reference was garbage collected
> {code}
> and then:
> {code}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:99)
> at
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:81)
> at
> org.apache.cassandra.io.util.RandomAccessReader.read(RandomAccessReader.java:353)
> at java.io.RandomAccessFile.readFully(RandomAccessFile.java:444)
> at java.io.RandomAccessFile.readFully(RandomAccessFile.java:424)
> at
> org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:378)
> at
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:348)
> at
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:327)
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:397)
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
> at
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:120)
> at
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:202)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.buildForCompaction(ColumnIndex.java:165)
> at
> org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:121)
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:192)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:127)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.tryAppend(SSTableRewriter.java:158)
> at
> org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:220)
> at
> org.apache.cassandra.tools.StandaloneScrubber.main(StandaloneScrubber.java:116)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11076) LEAK detected after bootstrapping a new node
[
https://issues.apache.org/jira/browse/CASSANDRA-11076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137182#comment-15137182
]
Eduard Tudenhoefner commented on CASSANDRA-11076:
-
[~krummas] for a while, it was happening every time in our tests, but as of Feb
3rd I also cannot reproduce the issue anymore in our tests.
> LEAK detected after bootstrapping a new node
>
>
> Key: CASSANDRA-11076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11076
> Project: Cassandra
> Issue Type: Bug
>Reporter: Eduard Tudenhoefner
>Assignee: Marcus Eriksson
> Fix For: 3.0.x
>
>
> Sequence of events:
> * start up a 2 node cluster
> * bootstrap one additional node so that the cluster consists of 3 nodes in
> total
> * the bootstrapped node will contain the LEAK error in the log file
> {code}
> INFO [main] 2016-01-26 10:59:06,206 Server.java:162 - Starting listening
> for CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2016-01-26 10:59:06,269 ThriftServer.java:119 - Binding thrift
> service to /0.0.0.0:9160
> INFO [Thread-6] 2016-01-26 10:59:06,280 ThriftServer.java:136 - Listening
> for thrift clients...
> INFO [HANDSHAKE-/10.200.178.183] 2016-01-26 10:59:06,703
> OutboundTcpConnection.java:503 - Handshaking version with /10.200.178.183
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,079
> StorageService.java:1099 - rebuild from dc: (any dc)
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,090
> RangeStreamer.java:339 - Some ranges of
> [(-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] are already available. Skipping
> streaming those ranges.
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,091
> RangeStreamer.java:339 - Some ranges of
> [(-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] are already available. Skipping
> streaming those ranges.
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,092
> RangeStreamer.java:339 - Some ranges of
> [(3074457345618258602,-9223372036854775808],
> (-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] are already available. Skipping
> streaming those ranges.
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,093
> RangeStreamer.java:339 - Some ranges of
> [(3074457345618258602,-9223372036854775808],
> (-9223372036854775808,-3074457345618258603],
> (-3074457345618258603,3074457345618258602]] are already available. Skipping
> streaming those ranges.
> INFO [RMI TCP Connection(4)-10.200.178.183] 2016-01-26 10:59:20,094
> StreamResultFuture.java:86 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Executing streaming plan for Rebuild
> INFO [StreamConnectionEstablisher:3] 2016-01-26 10:59:20,095
> StreamSession.java:238 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Starting streaming to /10.200.178.185
> INFO [StreamConnectionEstablisher:4] 2016-01-26 10:59:20,096
> StreamSession.java:238 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Starting streaming to /10.200.178.193
> INFO [StreamConnectionEstablisher:4] 2016-01-26 10:59:20,097
> StreamCoordinator.java:213 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03,
> ID#0] Beginning stream session with /10.200.178.193
> INFO [StreamConnectionEstablisher:3] 2016-01-26 10:59:20,098
> StreamCoordinator.java:213 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03,
> ID#0] Beginning stream session with /10.200.178.185
> INFO [STREAM-IN-/10.200.178.185] 2016-01-26 10:59:20,102
> StreamResultFuture.java:182 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Session with /10.200.178.185 is complete
> INFO [STREAM-IN-/10.200.178.193] 2016-01-26 10:59:20,359
> StreamResultFuture.java:182 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> Session with /10.200.178.193 is complete
> INFO [STREAM-IN-/10.200.178.193] 2016-01-26 10:59:20,362
> StreamResultFuture.java:214 - [Stream #d9bbe900-c41b-11e5-8540-d1e65b596c03]
> All sessions completed
> ERROR [Reference-Reaper:1] 2016-01-26 11:00:39,410 Ref.java:197 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@1c7d1dcf) to @2011417651 was
> not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2016-01-26 11:00:39,411 Ref.java:228 - Allocate
> trace org.apache.cassandra.utils.concurrent.Ref$State@1c7d1dcf:
> Thread[SharedPool-Worker-6,5,main]
> at java.lang.Thread.getStackTrace(Thread.java:1552)
> at org.apache.cassandra.utils.concurrent.Ref$Debug.(Ref.java:218)
> at org.apache.cassandra.utils.concurrent.Ref$State.(Ref.java:148)
> at org.apache.cassandra.utils.concurrent.Ref.(Ref.java:70)
>
[jira] [Commented] (CASSANDRA-11090) Hinted Handoff loop
[ https://issues.apache.org/jira/browse/CASSANDRA-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137155#comment-15137155 ] Blake Eggleston commented on CASSANDRA-11090: - Ok, looks like the crc problem is gone in the current 3.0 branch. The main issue I'm seeing though, is that any hint activity starts an infinite loop of empty hint file creation / processing. In the script I linked in the description, some data is inserted while there's a node down, creating a hints file. When the node is brought up, the hints are transmitted, as you'd expect. After that, every 10 seconds, another hints file (empty this time) is created for that node, and processed / deleted. It's less of an issue if the crc problem is fixed, but will still create a lot of noise in the logs for moderately sized clusters. > Hinted Handoff loop > --- > > Key: CASSANDRA-11090 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11090 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.x > > > After the hints executor finishes sending hints, another hints file is > created for the same host, which is then processed on the next go around. > This continues indefinitely. The new hint files are empty, so there shouldn't > be any network traffic. However, there's still unnecessary hint activity, and > the hint crc file isn't deleted in the 3.0 branch after hints are dispatched > (but is in trunk), so any hint activity will trigger ~8640 files being > created per day until the node is restarted. Restarting the node fixes the > problem, after the existing hint files are processed. > This can be duplicated on cassandra-3.0 to trunk with this script: > https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8643) merkle tree creation fails with NoSuchElementException
[
https://issues.apache.org/jira/browse/CASSANDRA-8643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137115#comment-15137115
]
Marcus Eriksson commented on CASSANDRA-8643:
[~Jan Karlsson] what version are you on now? Are you running incremental
repairs?
> merkle tree creation fails with NoSuchElementException
> --
>
> Key: CASSANDRA-8643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8643
> Project: Cassandra
> Issue Type: Bug
> Environment: We are running on a three node cluster with three in
> replication(C* 2.1.1). It uses a default C* installation and STCS.
>Reporter: Jan Karlsson
> Fix For: 2.1.3
>
>
> We have a problem that we encountered during testing over the weekend.
> During the tests we noticed that repairs started to fail. This error has
> occured on multiple non-coordinator nodes during repair. It also ran at least
> once without producing this error.
> We run repair -pr on all nodes on different days. CPU values were around 40%
> and disk was 50% full.
> From what I understand, the coordinator asked for merkle trees from the other
> two nodes. However one of the nodes fails to create his merkle tree.
> Unfortunately we do not have a way to reproduce this problem.
> The coordinator receives:
> {noformat}
> 2015-01-09T17:55:57.091+0100 INFO [RepairJobTask:4] RepairJob.java:145
> [repair #59455950-9820-11e4-b5c1-7797064e1316] requesting merkle trees for
> censored (to [/xx.90, /xx.98, /xx.82])
> 2015-01-09T17:55:58.516+0100 INFO [AntiEntropyStage:1]
> RepairSession.java:171 [repair #59455950-9820-11e4-b5c1-7797064e1316]
> Received merkle tree for censored from /xx.90
> 2015-01-09T17:55:59.581+0100 ERROR [AntiEntropySessions:76]
> RepairSession.java:303 [repair #59455950-9820-11e4-b5c1-7797064e1316] session
> completed with the following error
> org.apache.cassandra.exceptions.RepairException: [repair
> #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored,
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at
> org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:384)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:126)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> 2015-01-09T17:55:59.582+0100 ERROR [AntiEntropySessions:76]
> CassandraDaemon.java:153 Exception in thread
> Thread[AntiEntropySessions:76,5,RMI Runtime]
> java.lang.RuntimeException: org.apache.cassandra.exceptions.RepairException:
> [repair #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored,
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
>at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51] Caused by:
> org.apache.cassandra.exceptions.RepairException: [repair
> #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored,
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at
> org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:384)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:126)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> ... 3
[jira] [Reopened] (CASSANDRA-8643) merkle tree creation fails with NoSuchElementException
[
https://issues.apache.org/jira/browse/CASSANDRA-8643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reopened CASSANDRA-8643:
> merkle tree creation fails with NoSuchElementException
> --
>
> Key: CASSANDRA-8643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8643
> Project: Cassandra
> Issue Type: Bug
> Environment: We are running on a three node cluster with three in
> replication(C* 2.1.1). It uses a default C* installation and STCS.
>Reporter: Jan Karlsson
> Fix For: 2.1.3
>
>
> We have a problem that we encountered during testing over the weekend.
> During the tests we noticed that repairs started to fail. This error has
> occured on multiple non-coordinator nodes during repair. It also ran at least
> once without producing this error.
> We run repair -pr on all nodes on different days. CPU values were around 40%
> and disk was 50% full.
> From what I understand, the coordinator asked for merkle trees from the other
> two nodes. However one of the nodes fails to create his merkle tree.
> Unfortunately we do not have a way to reproduce this problem.
> The coordinator receives:
> {noformat}
> 2015-01-09T17:55:57.091+0100 INFO [RepairJobTask:4] RepairJob.java:145
> [repair #59455950-9820-11e4-b5c1-7797064e1316] requesting merkle trees for
> censored (to [/xx.90, /xx.98, /xx.82])
> 2015-01-09T17:55:58.516+0100 INFO [AntiEntropyStage:1]
> RepairSession.java:171 [repair #59455950-9820-11e4-b5c1-7797064e1316]
> Received merkle tree for censored from /xx.90
> 2015-01-09T17:55:59.581+0100 ERROR [AntiEntropySessions:76]
> RepairSession.java:303 [repair #59455950-9820-11e4-b5c1-7797064e1316] session
> completed with the following error
> org.apache.cassandra.exceptions.RepairException: [repair
> #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored,
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at
> org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:384)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:126)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> 2015-01-09T17:55:59.582+0100 ERROR [AntiEntropySessions:76]
> CassandraDaemon.java:153 Exception in thread
> Thread[AntiEntropySessions:76,5,RMI Runtime]
> java.lang.RuntimeException: org.apache.cassandra.exceptions.RepairException:
> [repair #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored,
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
>at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51] Caused by:
> org.apache.cassandra.exceptions.RepairException: [repair
> #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored,
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at
> org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:384)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:126)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> ... 3 common frames omitted
> {noformat}
> While one of the other nodes produces this error:
> {noformat}
> 2015-01-09T17:55:59.574+0100 ERROR [V
[jira] [Updated] (CASSANDRA-11116) Gossiper#isEnabled is not thread safe
[
https://issues.apache.org/jira/browse/CASSANDRA-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-6:
--
Fix Version/s: 2.1.14
> Gossiper#isEnabled is not thread safe
> -
>
> Key: CASSANDRA-6
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Sergio Bossa
>Assignee: Ariel Weisberg
>Priority: Critical
> Fix For: 2.1.14, 2.2.6, 3.0.4, 3.4
>
>
> {{Gossiper#isEnabled()}} relies on the presence of {{scheduledGossipTask}},
> which is not final nor volatile. As a consequence, when such method is called
> on a different thread, i.e. the gossip stage thread, it is sometimes detected
> as not enabled, causing particularly obscure failures.
> This is shown by the following logs. First the gossiper is started:
> {noformat}
> 1 TRACE [Thread-29] 2016-02-03 19:21:31,232 Gossiper.java (line 1310) gossip
> started with generation 1454527291
> {noformat}
> Then the same node misses a gossip message because the gossiper is seen as
> disabled:
> {noformat}
> 1 TRACE [GossipStage:1] 2016-02-03 19:21:32,016
> GossipDigestSynVerbHandler.java (line 44) Ignoring GossipDigestSynMessage
> because gossip is disabled
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11116) Gossiper#isEnabled is not thread safe
[
https://issues.apache.org/jira/browse/CASSANDRA-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137109#comment-15137109
]
Aleksey Yeschenko commented on CASSANDRA-6:
---
Additionally committed to 2.1 in {{6fe70c65291d01f1f1b1c5edaa727fbbb79eb617}}.
> Gossiper#isEnabled is not thread safe
> -
>
> Key: CASSANDRA-6
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Sergio Bossa
>Assignee: Ariel Weisberg
>Priority: Critical
> Fix For: 2.1.14, 2.2.6, 3.0.4, 3.4
>
>
> {{Gossiper#isEnabled()}} relies on the presence of {{scheduledGossipTask}},
> which is not final nor volatile. As a consequence, when such method is called
> on a different thread, i.e. the gossip stage thread, it is sometimes detected
> as not enabled, causing particularly obscure failures.
> This is shown by the following logs. First the gossiper is started:
> {noformat}
> 1 TRACE [Thread-29] 2016-02-03 19:21:31,232 Gossiper.java (line 1310) gossip
> started with generation 1454527291
> {noformat}
> Then the same node misses a gossip message because the gossiper is seen as
> disabled:
> {noformat}
> 1 TRACE [GossipStage:1] 2016-02-03 19:21:32,016
> GossipDigestSynVerbHandler.java (line 44) Ignoring GossipDigestSynMessage
> because gossip is disabled
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[09/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0d30540f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0d30540f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0d30540f Branch: refs/heads/trunk Commit: 0d30540f6a93d4ee711a629d622efdf0c02315ef Parents: 15092e6 029b22e Author: Aleksey Yeschenko Authored: Mon Feb 8 15:53:36 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:53:36 2016 + -- CHANGES.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d30540f/CHANGES.txt -- diff --cc CHANGES.txt index 03a8bc8,770c394..c6111e5 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,11 -1,8 +1,12 @@@ -2.2.6 +3.0.4 + * Fix leak detection strong reference loop using weak reference (CASSANDRA-11120) + * Configurie BatchlogManager to stop delayed tasks on shutdown (CASSANDRA-11062) + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 (CASSANDRA-11001) - Merged from 2.2.6 ++Merged from 2.2.6: * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) - * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) Merged from 2.1: + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3)
[10/10] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c227b928 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c227b928 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c227b928 Branch: refs/heads/trunk Commit: c227b928a9cfd49450fda6bc349e75f9b783c083 Parents: 1d7f312 0d30540 Author: Aleksey Yeschenko Authored: Mon Feb 8 15:53:48 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:53:48 2016 + -- CHANGES.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c227b928/CHANGES.txt --
[06/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/029b22e8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/029b22e8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/029b22e8 Branch: refs/heads/cassandra-2.2 Commit: 029b22e84d13f714b9a999fe7d6a1e6f8a5cfc0a Parents: d295c7c 6fe70c6 Author: Aleksey Yeschenko Authored: Mon Feb 8 15:52:07 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:52:07 2016 + -- CHANGES.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/029b22e8/CHANGES.txt -- diff --cc CHANGES.txt index b0a5062,806e6d5..770c394 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,40 -1,9 +1,40 @@@ -2.1.14 +2.2.6 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) - * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) +Merged from 2.1: + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) -2.1.13 - * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) +2.2.5 + * maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949) + * Apply change to compaction throughput in real time (CASSANDRA-10025) + * Fix potential NPE on ORDER BY queries with IN (CASSANDRA-10955) + * Avoid over-fetching during the page of range queries (CASSANDRA-8521) + * Start L0 STCS-compactions even if there is a L0 -> L1 compaction + going (CASSANDRA-10979) + * Make UUID LSB unique per process (CASSANDRA-7925) + * Avoid NPE when performing sstable tasks (scrub etc.) (CASSANDRA-10980) + * Make sure client gets tombstone overwhelmed warning (CASSANDRA-9465) + * Fix error streaming section more than 2GB (CASSANDRA-10961) + * (cqlsh) Also apply --connect-timeout to control connection + timeout (CASSANDRA-10959) + * Histogram buckets exposed in jmx are sorted incorrectly (CASSANDRA-10975) + * Enable GC logging by default (CASSANDRA-10140) + * Optimize pending range computation (CASSANDRA-9258) + * Skip commit log and saved cache directories in SSTable version startup check (CASSANDRA-10902) + * drop/alter user should be case sensitive (CASSANDRA-10817) + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) + * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) + * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) + * Add new types to Stress (CASSANDRA-9556) + * Add property to allow listening on broadcast interface (CASSANDRA-9748) + * Fix regression in split size on CqlInputFormat (CASSANDRA-10835) + * Better handling of SSL connection errors inter-node (CASSANDRA-10816) + * Disable reloading of GossipingPropertyFileSnitch (CASSANDRA-9474) + * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761) + * (cqlsh) encode input correctly when saving history +Merged from 2.1: * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969)
[04/10] cassandra git commit: Gossiper#isEnabled is not thread safe
Gossiper#isEnabled is not thread safe patch by aweisberg; reviewed by jasobrown for CASSANDRA-6 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6fe70c65 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6fe70c65 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6fe70c65 Branch: refs/heads/trunk Commit: 6fe70c65291d01f1f1b1c5edaa727fbbb79eb617 Parents: dd23adf Author: Ariel Weisberg Authored: Fri Feb 5 13:59:38 2016 -0800 Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:50:59 2016 + -- CHANGES.txt | 4 src/java/org/apache/cassandra/gms/Gossiper.java | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fe70c65/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 054ad1d..806e6d5 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,7 @@ +2.1.14 + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + + 2.1.13 * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fe70c65/src/java/org/apache/cassandra/gms/Gossiper.java -- diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java b/src/java/org/apache/cassandra/gms/Gossiper.java index ebdd5bd..ae99829 100644 --- a/src/java/org/apache/cassandra/gms/Gossiper.java +++ b/src/java/org/apache/cassandra/gms/Gossiper.java @@ -78,7 +78,7 @@ public class Gossiper implements IFailureDetectionEventListener, GossiperMBean SILENT_SHUTDOWN_STATES.add(VersionedValue.STATUS_BOOTSTRAPPING); } -private ScheduledFuture scheduledGossipTask; +private volatile ScheduledFuture scheduledGossipTask; private static final ReentrantLock taskLock = new ReentrantLock(); public final static int intervalInMillis = 1000; public final static int QUARANTINE_DELAY = StorageService.RING_DELAY * 2;
[02/10] cassandra git commit: Gossiper#isEnabled is not thread safe
Gossiper#isEnabled is not thread safe patch by aweisberg; reviewed by jasobrown for CASSANDRA-6 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6fe70c65 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6fe70c65 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6fe70c65 Branch: refs/heads/cassandra-2.2 Commit: 6fe70c65291d01f1f1b1c5edaa727fbbb79eb617 Parents: dd23adf Author: Ariel Weisberg Authored: Fri Feb 5 13:59:38 2016 -0800 Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:50:59 2016 + -- CHANGES.txt | 4 src/java/org/apache/cassandra/gms/Gossiper.java | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fe70c65/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 054ad1d..806e6d5 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,7 @@ +2.1.14 + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + + 2.1.13 * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fe70c65/src/java/org/apache/cassandra/gms/Gossiper.java -- diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java b/src/java/org/apache/cassandra/gms/Gossiper.java index ebdd5bd..ae99829 100644 --- a/src/java/org/apache/cassandra/gms/Gossiper.java +++ b/src/java/org/apache/cassandra/gms/Gossiper.java @@ -78,7 +78,7 @@ public class Gossiper implements IFailureDetectionEventListener, GossiperMBean SILENT_SHUTDOWN_STATES.add(VersionedValue.STATUS_BOOTSTRAPPING); } -private ScheduledFuture scheduledGossipTask; +private volatile ScheduledFuture scheduledGossipTask; private static final ReentrantLock taskLock = new ReentrantLock(); public final static int intervalInMillis = 1000; public final static int QUARANTINE_DELAY = StorageService.RING_DELAY * 2;
[05/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/029b22e8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/029b22e8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/029b22e8 Branch: refs/heads/cassandra-3.0 Commit: 029b22e84d13f714b9a999fe7d6a1e6f8a5cfc0a Parents: d295c7c 6fe70c6 Author: Aleksey Yeschenko Authored: Mon Feb 8 15:52:07 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:52:07 2016 + -- CHANGES.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/029b22e8/CHANGES.txt -- diff --cc CHANGES.txt index b0a5062,806e6d5..770c394 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,40 -1,9 +1,40 @@@ -2.1.14 +2.2.6 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) - * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) +Merged from 2.1: + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) -2.1.13 - * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) +2.2.5 + * maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949) + * Apply change to compaction throughput in real time (CASSANDRA-10025) + * Fix potential NPE on ORDER BY queries with IN (CASSANDRA-10955) + * Avoid over-fetching during the page of range queries (CASSANDRA-8521) + * Start L0 STCS-compactions even if there is a L0 -> L1 compaction + going (CASSANDRA-10979) + * Make UUID LSB unique per process (CASSANDRA-7925) + * Avoid NPE when performing sstable tasks (scrub etc.) (CASSANDRA-10980) + * Make sure client gets tombstone overwhelmed warning (CASSANDRA-9465) + * Fix error streaming section more than 2GB (CASSANDRA-10961) + * (cqlsh) Also apply --connect-timeout to control connection + timeout (CASSANDRA-10959) + * Histogram buckets exposed in jmx are sorted incorrectly (CASSANDRA-10975) + * Enable GC logging by default (CASSANDRA-10140) + * Optimize pending range computation (CASSANDRA-9258) + * Skip commit log and saved cache directories in SSTable version startup check (CASSANDRA-10902) + * drop/alter user should be case sensitive (CASSANDRA-10817) + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) + * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) + * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) + * Add new types to Stress (CASSANDRA-9556) + * Add property to allow listening on broadcast interface (CASSANDRA-9748) + * Fix regression in split size on CqlInputFormat (CASSANDRA-10835) + * Better handling of SSL connection errors inter-node (CASSANDRA-10816) + * Disable reloading of GossipingPropertyFileSnitch (CASSANDRA-9474) + * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761) + * (cqlsh) encode input correctly when saving history +Merged from 2.1: * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969)
[07/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/029b22e8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/029b22e8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/029b22e8 Branch: refs/heads/trunk Commit: 029b22e84d13f714b9a999fe7d6a1e6f8a5cfc0a Parents: d295c7c 6fe70c6 Author: Aleksey Yeschenko Authored: Mon Feb 8 15:52:07 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:52:07 2016 + -- CHANGES.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/029b22e8/CHANGES.txt -- diff --cc CHANGES.txt index b0a5062,806e6d5..770c394 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,40 -1,9 +1,40 @@@ -2.1.14 +2.2.6 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) - * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) +Merged from 2.1: + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) -2.1.13 - * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) +2.2.5 + * maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949) + * Apply change to compaction throughput in real time (CASSANDRA-10025) + * Fix potential NPE on ORDER BY queries with IN (CASSANDRA-10955) + * Avoid over-fetching during the page of range queries (CASSANDRA-8521) + * Start L0 STCS-compactions even if there is a L0 -> L1 compaction + going (CASSANDRA-10979) + * Make UUID LSB unique per process (CASSANDRA-7925) + * Avoid NPE when performing sstable tasks (scrub etc.) (CASSANDRA-10980) + * Make sure client gets tombstone overwhelmed warning (CASSANDRA-9465) + * Fix error streaming section more than 2GB (CASSANDRA-10961) + * (cqlsh) Also apply --connect-timeout to control connection + timeout (CASSANDRA-10959) + * Histogram buckets exposed in jmx are sorted incorrectly (CASSANDRA-10975) + * Enable GC logging by default (CASSANDRA-10140) + * Optimize pending range computation (CASSANDRA-9258) + * Skip commit log and saved cache directories in SSTable version startup check (CASSANDRA-10902) + * drop/alter user should be case sensitive (CASSANDRA-10817) + * jemalloc detection fails due to quoting issues in regexv (CASSANDRA-10946) + * Support counter-columns for native aggregates (sum,avg,max,min) (CASSANDRA-9977) + * (cqlsh) show correct column names for empty result sets (CASSANDRA-9813) + * Add new types to Stress (CASSANDRA-9556) + * Add property to allow listening on broadcast interface (CASSANDRA-9748) + * Fix regression in split size on CqlInputFormat (CASSANDRA-10835) + * Better handling of SSL connection errors inter-node (CASSANDRA-10816) + * Disable reloading of GossipingPropertyFileSnitch (CASSANDRA-9474) + * Verify tables in pseudo-system keyspaces at startup (CASSANDRA-10761) + * (cqlsh) encode input correctly when saving history +Merged from 2.1: * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * Fix isJoined return true only after becoming cluster member (CASANDRA-11007) * Fix bad gossip generation seen in long-running clusters (CASSANDRA-10969)
[08/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0d30540f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0d30540f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0d30540f Branch: refs/heads/cassandra-3.0 Commit: 0d30540f6a93d4ee711a629d622efdf0c02315ef Parents: 15092e6 029b22e Author: Aleksey Yeschenko Authored: Mon Feb 8 15:53:36 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:53:36 2016 + -- CHANGES.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d30540f/CHANGES.txt -- diff --cc CHANGES.txt index 03a8bc8,770c394..c6111e5 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,11 -1,8 +1,12 @@@ -2.2.6 +3.0.4 + * Fix leak detection strong reference loop using weak reference (CASSANDRA-11120) + * Configurie BatchlogManager to stop delayed tasks on shutdown (CASSANDRA-11062) + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 (CASSANDRA-11001) - Merged from 2.2.6 ++Merged from 2.2.6: * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) - * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) Merged from 2.1: + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3)
[03/10] cassandra git commit: Gossiper#isEnabled is not thread safe
Gossiper#isEnabled is not thread safe patch by aweisberg; reviewed by jasobrown for CASSANDRA-6 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6fe70c65 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6fe70c65 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6fe70c65 Branch: refs/heads/cassandra-3.0 Commit: 6fe70c65291d01f1f1b1c5edaa727fbbb79eb617 Parents: dd23adf Author: Ariel Weisberg Authored: Fri Feb 5 13:59:38 2016 -0800 Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:50:59 2016 + -- CHANGES.txt | 4 src/java/org/apache/cassandra/gms/Gossiper.java | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fe70c65/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 054ad1d..806e6d5 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,7 @@ +2.1.14 + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + + 2.1.13 * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fe70c65/src/java/org/apache/cassandra/gms/Gossiper.java -- diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java b/src/java/org/apache/cassandra/gms/Gossiper.java index ebdd5bd..ae99829 100644 --- a/src/java/org/apache/cassandra/gms/Gossiper.java +++ b/src/java/org/apache/cassandra/gms/Gossiper.java @@ -78,7 +78,7 @@ public class Gossiper implements IFailureDetectionEventListener, GossiperMBean SILENT_SHUTDOWN_STATES.add(VersionedValue.STATUS_BOOTSTRAPPING); } -private ScheduledFuture scheduledGossipTask; +private volatile ScheduledFuture scheduledGossipTask; private static final ReentrantLock taskLock = new ReentrantLock(); public final static int intervalInMillis = 1000; public final static int QUARANTINE_DELAY = StorageService.RING_DELAY * 2;
[01/10] cassandra git commit: Gossiper#isEnabled is not thread safe
Repository: cassandra Updated Branches: refs/heads/cassandra-2.1 dd23adf14 -> 6fe70c652 refs/heads/cassandra-2.2 d295c7c69 -> 029b22e84 refs/heads/cassandra-3.0 15092e634 -> 0d30540f6 refs/heads/trunk 1d7f3129a -> c227b928a Gossiper#isEnabled is not thread safe patch by aweisberg; reviewed by jasobrown for CASSANDRA-6 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6fe70c65 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6fe70c65 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6fe70c65 Branch: refs/heads/cassandra-2.1 Commit: 6fe70c65291d01f1f1b1c5edaa727fbbb79eb617 Parents: dd23adf Author: Ariel Weisberg Authored: Fri Feb 5 13:59:38 2016 -0800 Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:50:59 2016 + -- CHANGES.txt | 4 src/java/org/apache/cassandra/gms/Gossiper.java | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fe70c65/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 054ad1d..806e6d5 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,7 @@ +2.1.14 + * Gossiper#isEnabled is not thread safe (CASSANDRA-6) + + 2.1.13 * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fe70c65/src/java/org/apache/cassandra/gms/Gossiper.java -- diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java b/src/java/org/apache/cassandra/gms/Gossiper.java index ebdd5bd..ae99829 100644 --- a/src/java/org/apache/cassandra/gms/Gossiper.java +++ b/src/java/org/apache/cassandra/gms/Gossiper.java @@ -78,7 +78,7 @@ public class Gossiper implements IFailureDetectionEventListener, GossiperMBean SILENT_SHUTDOWN_STATES.add(VersionedValue.STATUS_BOOTSTRAPPING); } -private ScheduledFuture scheduledGossipTask; +private volatile ScheduledFuture scheduledGossipTask; private static final ReentrantLock taskLock = new ReentrantLock(); public final static int intervalInMillis = 1000; public final static int QUARANTINE_DELAY = StorageService.RING_DELAY * 2;
[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1d7f3129 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1d7f3129 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1d7f3129 Branch: refs/heads/trunk Commit: 1d7f3129ad95f5303c0fc71d00e5764b5e53424e Parents: 1e6e3d4 15092e6 Author: Aleksey Yeschenko Authored: Mon Feb 8 15:42:08 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 15:42:08 2016 + -- CHANGES.txt | 1 + .../io/sstable/format/SSTableReader.java| 17 + .../apache/cassandra/utils/concurrent/Ref.java | 15 ++-- .../utils/concurrent/RefCountedTest.java| 36 4 files changed, 60 insertions(+), 9 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/1d7f3129/CHANGES.txt -- diff --cc CHANGES.txt index 8351032,03a8bc8..0f1b4d3 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,20 -1,5 +1,21 @@@ -3.0.4 +3.4 + * Add LIKE support to CQL3 (CASSANDRA-11067) + * Generic Java UDF types (CASSANDRA-10819) + * cqlsh: Include sub-second precision in timestamps by default (CASSANDRA-10428) + * Set javac encoding to utf-8 (CASSANDRA-11077) + * Integrate SASI index into Cassandra (CASSANDRA-10661) + * Add --skip-flush option to nodetool snapshot + * Skip values for non-queried columns (CASSANDRA-10657) + * Add support for secondary indexes on static columns (CASSANDRA-8103) + * CommitLogUpgradeTestMaker creates broken commit logs (CASSANDRA-11051) + * Add metric for number of dropped mutations (CASSANDRA-10866) + * Simplify row cache invalidation code (CASSANDRA-10396) + * Support user-defined compaction through nodetool (CASSANDRA-10660) + * Stripe view locks by key and table ID to reduce contention (CASSANDRA-10981) + * Add nodetool gettimeout and settimeout commands (CASSANDRA-10953) + * Add 3.0 metadata to sstablemetadata output (CASSANDRA-10838) +Merged from 3.0: + * Fix leak detection strong reference loop using weak reference (CASSANDRA-11120) * Configurie BatchlogManager to stop delayed tasks on shutdown (CASSANDRA-11062) * Hadoop integration is incompatible with Cassandra Driver 3.0.0 (CASSANDRA-11001) Merged from 2.2.6 http://git-wip-us.apache.org/repos/asf/cassandra/blob/1d7f3129/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java --
[2/3] cassandra git commit: Fix leak detection strong reference loop using weak reference
Fix leak detection strong reference loop using weak reference
patch by Ariel Weisberg; reviewed by by Jeremiah Jordan for
CASSANDRA-11120
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/15092e63
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/15092e63
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/15092e63
Branch: refs/heads/trunk
Commit: 15092e6344a23612cb1793b82d1f80a1cbb1dafa
Parents: 0a1cfaa
Author: Ariel Weisberg
Authored: Fri Feb 5 11:09:00 2016 -0500
Committer: Aleksey Yeschenko
Committed: Mon Feb 8 15:38:19 2016 +
--
CHANGES.txt | 1 +
.../io/sstable/format/SSTableReader.java| 17 +
.../apache/cassandra/utils/concurrent/Ref.java | 15 ++--
.../utils/concurrent/RefCountedTest.java| 36
4 files changed, 60 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/15092e63/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1fbe301..03a8bc8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.4
+ * Fix leak detection strong reference loop using weak reference
(CASSANDRA-11120)
* Configurie BatchlogManager to stop delayed tasks on shutdown
(CASSANDRA-11062)
* Hadoop integration is incompatible with Cassandra Driver 3.0.0
(CASSANDRA-11001)
Merged from 2.2.6
http://git-wip-us.apache.org/repos/asf/cassandra/blob/15092e63/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
index 8788766..1618516 100644
--- a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
@@ -18,6 +18,7 @@
package org.apache.cassandra.io.sstable.format;
import java.io.*;
+import java.lang.ref.WeakReference;
import java.nio.ByteBuffer;
import java.util.*;
import java.util.concurrent.*;
@@ -2200,6 +2201,7 @@ public abstract class SSTableReader extends SSTable
implements SelfRefCounted> NULL = new
WeakReference<>(null);
// keyed by descriptor, mapping to the shared GlobalTidy for that
descriptor
static final ConcurrentMap> lookup = new
ConcurrentHashMap<>();
@@ -2209,7 +2211,7 @@ public abstract class SSTableReader extends SSTable
implements SelfRefCounted> readMeterSyncFuture = NULL;
// shared state managing if the logical sstable has been compacted;
this is used in cleanup
private volatile Runnable obsoletion;
@@ -2228,13 +2230,13 @@ public abstract class SSTableReader extends SSTable
implements SelfRefCounted(syncExecutor.scheduleAtFixedRate(new Runnable()
{
public void run()
{
@@ -2244,15 +2246,16 @@ public abstract class SSTableReader extends SSTable
implements SelfRefCounted readMeterSyncFutureLocal =
readMeterSyncFuture.get();
+if (readMeterSyncFutureLocal != null)
{
-readMeterSyncFuture.cancel(true);
-readMeterSyncFuture = null;
+readMeterSyncFutureLocal.cancel(true);
+readMeterSyncFuture = NULL;
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/15092e63/src/java/org/apache/cassandra/utils/concurrent/Ref.java
--
diff --git a/src/java/org/apache/cassandra/utils/concurrent/Ref.java
b/src/java/org/apache/cassandra/utils/concurrent/Ref.java
index 25ebde9..02eccbb 100644
--- a/src/java/org/apache/cassandra/utils/concurrent/Ref.java
+++ b/src/java/org/apache/cassandra/utils/concurrent/Ref.java
@@ -1,7 +1,9 @@
package org.apache.cassandra.utils.concurrent;
import java.lang.ref.PhantomReference;
+import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
+import java.lang.ref.WeakReference;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.util.*;
@@ -14,7 +16,6 @@ import org.slf4j.LoggerFactory;
import com.google.common.annotations.VisibleForTesting;
import com.google.common.base.Preconditions;
-import com.google.common.collect.Iterables;
import org.apache.cassandra.concurrent.NamedThreadFactory;
import org.apache.cassandra.db.ColumnFamilyStore;
@@ -466,7 +467,7 @@ public final class Ref implements RefCounted
while (collectionIterator.hasNext() && (nextItem =
collectionIterator.next()) == null){}
if (nextItem != null)
{
-if (isMapIterator && nextItem
[jira] [Commented] (CASSANDRA-11120) Leak Detected while bringing nodes up and down when under stress.
[
https://issues.apache.org/jira/browse/CASSANDRA-11120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137094#comment-15137094
]
Aleksey Yeschenko commented on CASSANDRA-11120:
---
Thanks. Committed as
[15092e6344a23612cb1793b82d1f80a1cbb1dafa|https://github.com/apache/cassandra/commit/15092e6344a23612cb1793b82d1f80a1cbb1dafa]
to 3.0 and merged with trunk.
> Leak Detected while bringing nodes up and down when under stress.
> -
>
> Key: CASSANDRA-11120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11120
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> So after CASSANDRA-10688 has been fixed I'm able to reproduce some leaks
> consistently with my stress test suite that is doing repairs/stress/bringing
> nodes up and down.
> One such example:
> {noformat}
> ERROR [Strong-Reference-Leak-Detector:1] 2016-02-03 23:32:38,827
> NoSpamLogger.java:97 - Strong self-ref loop detected
> [/var/lib/cassandra/data/keyspace1/standard1-7cddd4c1cacc11e5aa69f375b464842d/ma-14-big,
> private java.util.concurrent.ScheduledFuture
> org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy.readMeterSyncFuture-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> final java.util.concurrent.ScheduledThreadPoolExecutor
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.this$0-java.util.concurrent.ScheduledThreadPoolExecutor,
> private final java.util.HashSet
> java.util.concurrent.ThreadPoolExecutor.workers-java.util.HashSet, private
> transient java.util.HashMap java.util.HashSet.map-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> final java.lang.Object
> java.util.HashMap$Node.key-java.util.concurrent.ThreadPoolExecutor$Worker,
> final java.lang.Thread
> java.util.concurrent.ThreadPoolExecutor$Worker.thread-java.lang.Thread,
> private java.lang.ThreadGroup java.lang.Thread.group-java.lang.ThreadGroup,
> private final java.lang.ThreadGroup
> java.lang.ThreadGroup.parent-java.lang.ThreadGroup, java.lang.Thread[]
> java.lang.ThreadGroup.threads-[Ljava.lang.Thread;, java.lang.Thread[]
> java.lang.ThreadGroup.threads-java.lang.Thread, private java.lang.Runnable
> java.lang.Thread.target-java.util.concurrent.ThreadPoolExecutor$Worker, final
> java.util.concurrent.ThreadPoolExecutor
> java.util.concurrent.ThreadPoolExecutor$Worker.this$0-java.util.concurrent.ScheduledThreadPoolExecutor,
> private final java.util.concurrent.BlockingQueue
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue,
> private final java.util.concurrent.BlockingQueue
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> private java.util.concurrent.Callable
> java.util.concurrent.FutureTask.callable-java.util.concurrent.Executors$RunnableAdapter,
> final java.lang.Runnable
> java.util.concurrent.Executors$RunnableAdapter.task-sun.rmi.transport.DGCImpl$1,
> final sun.rmi.transport.DGCImpl
> sun.rmi.transport.DGCImpl$1.this$0-sun.rmi.transport.DGCImpl, private
> java.util.Map sun.rmi.transport.DGCImpl.leaseTable-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> java.lang.Object
> java.util.HashMap$Node.value-sun.rmi.transport.DGCImpl$LeaseInfo,
> java.util.Set
> sun.rmi.transport.DGCImpl$LeaseInfo.notifySet-java.util.HashSet, private
> transient java.util.HashMap java.util.HashSet.map-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> final java.lang.Object java.util.HashMap$Node.key-sun.rmi.transport.Target,
> private final sun.rmi.transport.WeakRef
> sun.rmi.transport.Target.weakImpl-sun.rmi.transport.WeakRef, private
> java.lang.Object
> sun.rmi.transport.WeakRef.strongRef-javax.management.remote.rmi.RMIJRMPServerImpl,
> private final java.util.List
> javax.management.remote.rmi.RMIServerImpl.clientList-java.util.ArrayList,
> transient java.lang.Object[]
> java.util.ArrayList.elementData-[Ljava.lang.Object;, transient
> java.lang.Object[]
> java.util.ArrayList.elementData-java.lang.ref.WeakReference, private
> java.lang.Object
> java.lang.ref.Reference.referent-javax.management.remote.rmi.RMIConnectionImpl,
> priva
[1/3] cassandra git commit: Fix leak detection strong reference loop using weak reference
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 0a1cfaace -> 15092e634
refs/heads/trunk 1e6e3d4d2 -> 1d7f3129a
Fix leak detection strong reference loop using weak reference
patch by Ariel Weisberg; reviewed by by Jeremiah Jordan for
CASSANDRA-11120
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/15092e63
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/15092e63
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/15092e63
Branch: refs/heads/cassandra-3.0
Commit: 15092e6344a23612cb1793b82d1f80a1cbb1dafa
Parents: 0a1cfaa
Author: Ariel Weisberg
Authored: Fri Feb 5 11:09:00 2016 -0500
Committer: Aleksey Yeschenko
Committed: Mon Feb 8 15:38:19 2016 +
--
CHANGES.txt | 1 +
.../io/sstable/format/SSTableReader.java| 17 +
.../apache/cassandra/utils/concurrent/Ref.java | 15 ++--
.../utils/concurrent/RefCountedTest.java| 36
4 files changed, 60 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/15092e63/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1fbe301..03a8bc8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.4
+ * Fix leak detection strong reference loop using weak reference
(CASSANDRA-11120)
* Configurie BatchlogManager to stop delayed tasks on shutdown
(CASSANDRA-11062)
* Hadoop integration is incompatible with Cassandra Driver 3.0.0
(CASSANDRA-11001)
Merged from 2.2.6
http://git-wip-us.apache.org/repos/asf/cassandra/blob/15092e63/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
index 8788766..1618516 100644
--- a/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java
@@ -18,6 +18,7 @@
package org.apache.cassandra.io.sstable.format;
import java.io.*;
+import java.lang.ref.WeakReference;
import java.nio.ByteBuffer;
import java.util.*;
import java.util.concurrent.*;
@@ -2200,6 +2201,7 @@ public abstract class SSTableReader extends SSTable
implements SelfRefCounted> NULL = new
WeakReference<>(null);
// keyed by descriptor, mapping to the shared GlobalTidy for that
descriptor
static final ConcurrentMap> lookup = new
ConcurrentHashMap<>();
@@ -2209,7 +2211,7 @@ public abstract class SSTableReader extends SSTable
implements SelfRefCounted> readMeterSyncFuture = NULL;
// shared state managing if the logical sstable has been compacted;
this is used in cleanup
private volatile Runnable obsoletion;
@@ -2228,13 +2230,13 @@ public abstract class SSTableReader extends SSTable
implements SelfRefCounted(syncExecutor.scheduleAtFixedRate(new Runnable()
{
public void run()
{
@@ -2244,15 +2246,16 @@ public abstract class SSTableReader extends SSTable
implements SelfRefCounted readMeterSyncFutureLocal =
readMeterSyncFuture.get();
+if (readMeterSyncFutureLocal != null)
{
-readMeterSyncFuture.cancel(true);
-readMeterSyncFuture = null;
+readMeterSyncFutureLocal.cancel(true);
+readMeterSyncFuture = NULL;
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/15092e63/src/java/org/apache/cassandra/utils/concurrent/Ref.java
--
diff --git a/src/java/org/apache/cassandra/utils/concurrent/Ref.java
b/src/java/org/apache/cassandra/utils/concurrent/Ref.java
index 25ebde9..02eccbb 100644
--- a/src/java/org/apache/cassandra/utils/concurrent/Ref.java
+++ b/src/java/org/apache/cassandra/utils/concurrent/Ref.java
@@ -1,7 +1,9 @@
package org.apache.cassandra.utils.concurrent;
import java.lang.ref.PhantomReference;
+import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
+import java.lang.ref.WeakReference;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.util.*;
@@ -14,7 +16,6 @@ import org.slf4j.LoggerFactory;
import com.google.common.annotations.VisibleForTesting;
import com.google.common.base.Preconditions;
-import com.google.common.collect.Iterables;
import org.apache.cassandra.concurrent.NamedThreadFactory;
import org.apache.cassandra.db.ColumnFamilyStore;
@@ -466,7 +467,7 @@ public final class Ref implements RefCounted
while (collectionIterator.hasNext() && (nextItem =
coll
[jira] [Commented] (CASSANDRA-11128) Unexpected exception during request; AssertionError: null
[
https://issues.apache.org/jira/browse/CASSANDRA-11128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137045#comment-15137045
]
Sylvain Lebresne commented on CASSANDRA-11128:
--
Do we know if it's a regression or not? That is, have we run this on 3.0.2 for
instance enough to be sure it's not affected. Can we try to bisect if so?
> Unexpected exception during request; AssertionError: null
> -
>
> Key: CASSANDRA-11128
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11128
> Project: Cassandra
> Issue Type: Bug
>Reporter: Russ Hatch
> Fix For: 3.0.x
>
>
> Post upgrade from 2.1 to 3.0.3 (3.0.3-tentative) I'm intermittently seeing
> this exception:
> {noformat}
> ['ERROR [SharedPool-Worker-3] 2016-02-05 22:38:08,444 Message.java:611 -
> Unexpected exception during request; channel = [id: 0xb5fa21d0,
> /127.0.0.1:46096 => /127.0.0.1:9042]\njava.lang.AssertionError: null
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:619)
> ~[main/:na]
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:523)
> ~[main/:na]
> at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:166)
> ~[main/:na]
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:72)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:609)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:758)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:701)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendRRWithFailure(MessagingService.java:684)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor.makeRequests(AbstractReadExecutor.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor.makeDataRequests(AbstractReadExecutor.java:85)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor$SpeculatingReadExecutor.executeAsync(AbstractReadExecutor.java:264)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.doInitialQueries(StorageProxy.java:1689)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1644)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1591)
> ~[main/:na]
> at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1510)
> ~[main/:na]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.execute(SinglePartitionReadCommand.java:302)
> ~[main/:na]
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:67)
> ~[main/:na]
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:34)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:302)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:338)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:214)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:472)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:449)
> ~[main/:na]
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
> ~[main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
> [main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
> [main/:na]
> 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_51]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocal
[jira] [Commented] (CASSANDRA-11120) Leak Detected while bringing nodes up and down when under stress.
[
https://issues.apache.org/jira/browse/CASSANDRA-11120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137040#comment-15137040
]
Ariel Weisberg commented on CASSANDRA-11120:
Code is the same across all versions. You can ignore the 3.3 and trunk branches.
> Leak Detected while bringing nodes up and down when under stress.
> -
>
> Key: CASSANDRA-11120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11120
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> So after CASSANDRA-10688 has been fixed I'm able to reproduce some leaks
> consistently with my stress test suite that is doing repairs/stress/bringing
> nodes up and down.
> One such example:
> {noformat}
> ERROR [Strong-Reference-Leak-Detector:1] 2016-02-03 23:32:38,827
> NoSpamLogger.java:97 - Strong self-ref loop detected
> [/var/lib/cassandra/data/keyspace1/standard1-7cddd4c1cacc11e5aa69f375b464842d/ma-14-big,
> private java.util.concurrent.ScheduledFuture
> org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy.readMeterSyncFuture-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> final java.util.concurrent.ScheduledThreadPoolExecutor
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.this$0-java.util.concurrent.ScheduledThreadPoolExecutor,
> private final java.util.HashSet
> java.util.concurrent.ThreadPoolExecutor.workers-java.util.HashSet, private
> transient java.util.HashMap java.util.HashSet.map-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> final java.lang.Object
> java.util.HashMap$Node.key-java.util.concurrent.ThreadPoolExecutor$Worker,
> final java.lang.Thread
> java.util.concurrent.ThreadPoolExecutor$Worker.thread-java.lang.Thread,
> private java.lang.ThreadGroup java.lang.Thread.group-java.lang.ThreadGroup,
> private final java.lang.ThreadGroup
> java.lang.ThreadGroup.parent-java.lang.ThreadGroup, java.lang.Thread[]
> java.lang.ThreadGroup.threads-[Ljava.lang.Thread;, java.lang.Thread[]
> java.lang.ThreadGroup.threads-java.lang.Thread, private java.lang.Runnable
> java.lang.Thread.target-java.util.concurrent.ThreadPoolExecutor$Worker, final
> java.util.concurrent.ThreadPoolExecutor
> java.util.concurrent.ThreadPoolExecutor$Worker.this$0-java.util.concurrent.ScheduledThreadPoolExecutor,
> private final java.util.concurrent.BlockingQueue
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue,
> private final java.util.concurrent.BlockingQueue
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> private java.util.concurrent.Callable
> java.util.concurrent.FutureTask.callable-java.util.concurrent.Executors$RunnableAdapter,
> final java.lang.Runnable
> java.util.concurrent.Executors$RunnableAdapter.task-sun.rmi.transport.DGCImpl$1,
> final sun.rmi.transport.DGCImpl
> sun.rmi.transport.DGCImpl$1.this$0-sun.rmi.transport.DGCImpl, private
> java.util.Map sun.rmi.transport.DGCImpl.leaseTable-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> java.lang.Object
> java.util.HashMap$Node.value-sun.rmi.transport.DGCImpl$LeaseInfo,
> java.util.Set
> sun.rmi.transport.DGCImpl$LeaseInfo.notifySet-java.util.HashSet, private
> transient java.util.HashMap java.util.HashSet.map-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> final java.lang.Object java.util.HashMap$Node.key-sun.rmi.transport.Target,
> private final sun.rmi.transport.WeakRef
> sun.rmi.transport.Target.weakImpl-sun.rmi.transport.WeakRef, private
> java.lang.Object
> sun.rmi.transport.WeakRef.strongRef-javax.management.remote.rmi.RMIJRMPServerImpl,
> private final java.util.List
> javax.management.remote.rmi.RMIServerImpl.clientList-java.util.ArrayList,
> transient java.lang.Object[]
> java.util.ArrayList.elementData-[Ljava.lang.Object;, transient
> java.lang.Object[]
> java.util.ArrayList.elementData-java.lang.ref.WeakReference, private
> java.lang.Object
> java.lang.ref.Reference.referent-javax.management.remote.rmi.RMIConnectionImpl,
> private final javax.management.MBeanServer
> javax.management.remote.rmi.RMIConnectionImpl.mbeanServer-com.su
[jira] [Updated] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
[
https://issues.apache.org/jira/browse/CASSANDRA-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-11062:
--
Component/s: Local Write-Read Paths
> BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
> -
>
> Key: CASSANDRA-11062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Caleb William Rackliffe
>Assignee: Caleb William Rackliffe
>Priority: Minor
> Fix For: 3.0.4, 3.4
>
> Attachments: 11062-3.0.txt
>
>
> {{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
> tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
> call {{replayFailedBatches()}} after drain has instructed both it and the
> {{HintsService}} to shut down. When this happens, we get an exception when
> that tries to submit a task to the executor in {{HintsWriteExecutor}}:
> {noformat}
> ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
> Exception in thread Thread[BatchlogTasks:1,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> [na:1.8.0_65]
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> ~[na:1.8.0_65]
> at
> org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_65]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
[
https://issues.apache.org/jira/browse/CASSANDRA-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137037#comment-15137037
]
Aleksey Yeschenko commented on CASSANDRA-11062:
---
+1 and committed as
[0a1cfaaceade1317e9fc802d77e39371e745dee3|https://github.com/apache/cassandra/commit/0a1cfaaceade1317e9fc802d77e39371e745dee3]
to 3.0 and merged with trunk.
I did run the tests locally. In the future, though, even for patches as minor
as this one, please have cassci results attached to your patch available
tickets.
> BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
> -
>
> Key: CASSANDRA-11062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
> Project: Cassandra
> Issue Type: Bug
>Reporter: Caleb William Rackliffe
>Assignee: Caleb William Rackliffe
>Priority: Minor
> Fix For: 3.0.4, 3.4
>
> Attachments: 11062-3.0.txt
>
>
> {{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
> tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
> call {{replayFailedBatches()}} after drain has instructed both it and the
> {{HintsService}} to shut down. When this happens, we get an exception when
> that tries to submit a task to the executor in {{HintsWriteExecutor}}:
> {noformat}
> ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
> Exception in thread Thread[BatchlogTasks:1,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> [na:1.8.0_65]
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> ~[na:1.8.0_65]
> at
> org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_65]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1e6e3d4d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1e6e3d4d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1e6e3d4d Branch: refs/heads/trunk Commit: 1e6e3d4d2737c81cade4afe33effa7125934cf8b Parents: 71ccb16 0a1cfaa Author: Aleksey Yeschenko Authored: Mon Feb 8 13:09:58 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 13:09:58 2016 + -- CHANGES.txt | 1 + src/java/org/apache/cassandra/batchlog/BatchlogManager.java | 9 - 2 files changed, 9 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e6e3d4d/CHANGES.txt -- diff --cc CHANGES.txt index 2d50c10,1fbe301..8351032 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,20 -1,5 +1,21 @@@ -3.0.4 +3.4 + * Add LIKE support to CQL3 (CASSANDRA-11067) + * Generic Java UDF types (CASSANDRA-10819) + * cqlsh: Include sub-second precision in timestamps by default (CASSANDRA-10428) + * Set javac encoding to utf-8 (CASSANDRA-11077) + * Integrate SASI index into Cassandra (CASSANDRA-10661) + * Add --skip-flush option to nodetool snapshot + * Skip values for non-queried columns (CASSANDRA-10657) + * Add support for secondary indexes on static columns (CASSANDRA-8103) + * CommitLogUpgradeTestMaker creates broken commit logs (CASSANDRA-11051) + * Add metric for number of dropped mutations (CASSANDRA-10866) + * Simplify row cache invalidation code (CASSANDRA-10396) + * Support user-defined compaction through nodetool (CASSANDRA-10660) + * Stripe view locks by key and table ID to reduce contention (CASSANDRA-10981) + * Add nodetool gettimeout and settimeout commands (CASSANDRA-10953) + * Add 3.0 metadata to sstablemetadata output (CASSANDRA-10838) +Merged from 3.0: + * Configurie BatchlogManager to stop delayed tasks on shutdown (CASSANDRA-11062) * Hadoop integration is incompatible with Cassandra Driver 3.0.0 (CASSANDRA-11001) Merged from 2.2.6 * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
[1/3] cassandra git commit: Configurie BatchlogManager to stop delayed tasks on shutdown
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 23f629628 -> 0a1cfaace
refs/heads/trunk 71ccb16bf -> 1e6e3d4d2
Configurie BatchlogManager to stop delayed tasks on shutdown
patch by Caleb Rackliffe; reviewed by Aleksey Yeschenko for
CASSANDRA-11062
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0a1cfaac
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0a1cfaac
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0a1cfaac
Branch: refs/heads/cassandra-3.0
Commit: 0a1cfaaceade1317e9fc802d77e39371e745dee3
Parents: 23f6296
Author: Caleb Rackliffe
Authored: Fri Jan 22 18:04:09 2016 -0800
Committer: Aleksey Yeschenko
Committed: Mon Feb 8 13:08:38 2016 +
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/batchlog/BatchlogManager.java | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a1cfaac/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6302ce6..1fbe301 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.4
+ * Configurie BatchlogManager to stop delayed tasks on shutdown
(CASSANDRA-11062)
* Hadoop integration is incompatible with Cassandra Driver 3.0.0
(CASSANDRA-11001)
Merged from 2.2.6
* (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a1cfaac/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
--
diff --git a/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
b/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
index 1c98c2a..7ccc6f8 100644
--- a/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
+++ b/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
@@ -72,7 +72,14 @@ public class BatchlogManager implements BatchlogManagerMBean
private volatile UUID lastReplayedUuid = UUIDGen.minTimeUUID(0);
// Single-thread executor service for scheduling and serializing log
replay.
-private final ScheduledExecutorService batchlogTasks = new
DebuggableScheduledThreadPoolExecutor("BatchlogTasks");
+private final ScheduledExecutorService batchlogTasks;
+
+public BatchlogManager()
+{
+ScheduledThreadPoolExecutor executor = new
DebuggableScheduledThreadPoolExecutor("BatchlogTasks");
+executor.setExecuteExistingDelayedTasksAfterShutdownPolicy(false);
+batchlogTasks = executor;
+}
public void start()
{
[jira] [Commented] (CASSANDRA-10540) RangeAwareCompaction
[ https://issues.apache.org/jira/browse/CASSANDRA-10540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137020#comment-15137020 ] Marcus Eriksson commented on CASSANDRA-10540: - [rebased|https://github.com/krummas/cassandra/commits/marcuse/10540] and test runs looks clean: http://cassci.datastax.com/job/krummas-marcuse-10540-dtest/ http://cassci.datastax.com/job/krummas-marcuse-10540-testall/ > RangeAwareCompaction > > > Key: CASSANDRA-10540 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10540 > Project: Cassandra > Issue Type: New Feature >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.x > > > Broken out from CASSANDRA-6696, we should split sstables based on ranges > during compaction. > Requirements; > * dont create tiny sstables - keep them bunched together until a single vnode > is big enough (configurable how big that is) > * make it possible to run existing compaction strategies on the per-range > sstables > We should probably add a global compaction strategy parameter that states > whether this should be enabled or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/3] cassandra git commit: Configurie BatchlogManager to stop delayed tasks on shutdown
Configurie BatchlogManager to stop delayed tasks on shutdown
patch by Caleb Rackliffe; reviewed by Aleksey Yeschenko for
CASSANDRA-11062
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0a1cfaac
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0a1cfaac
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0a1cfaac
Branch: refs/heads/trunk
Commit: 0a1cfaaceade1317e9fc802d77e39371e745dee3
Parents: 23f6296
Author: Caleb Rackliffe
Authored: Fri Jan 22 18:04:09 2016 -0800
Committer: Aleksey Yeschenko
Committed: Mon Feb 8 13:08:38 2016 +
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/batchlog/BatchlogManager.java | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a1cfaac/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6302ce6..1fbe301 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.4
+ * Configurie BatchlogManager to stop delayed tasks on shutdown
(CASSANDRA-11062)
* Hadoop integration is incompatible with Cassandra Driver 3.0.0
(CASSANDRA-11001)
Merged from 2.2.6
* (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a1cfaac/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
--
diff --git a/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
b/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
index 1c98c2a..7ccc6f8 100644
--- a/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
+++ b/src/java/org/apache/cassandra/batchlog/BatchlogManager.java
@@ -72,7 +72,14 @@ public class BatchlogManager implements BatchlogManagerMBean
private volatile UUID lastReplayedUuid = UUIDGen.minTimeUUID(0);
// Single-thread executor service for scheduling and serializing log
replay.
-private final ScheduledExecutorService batchlogTasks = new
DebuggableScheduledThreadPoolExecutor("BatchlogTasks");
+private final ScheduledExecutorService batchlogTasks;
+
+public BatchlogManager()
+{
+ScheduledThreadPoolExecutor executor = new
DebuggableScheduledThreadPoolExecutor("BatchlogTasks");
+executor.setExecuteExistingDelayedTasksAfterShutdownPolicy(false);
+batchlogTasks = executor;
+}
public void start()
{
[jira] [Commented] (CASSANDRA-8643) merkle tree creation fails with NoSuchElementException
[
https://issues.apache.org/jira/browse/CASSANDRA-8643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136995#comment-15136995
]
Jan Karlsson commented on CASSANDRA-8643:
-
We hit it again. This time we had more time debugging the situation and we
might have found the problem. It started occuring when we switched to
LeveledCompactionStrategy. However it does not occur consistently. We usually
get it once every 2-3 runs.
We enabled assertions and got "received out of order wrt". The problem we found
is that the ranges of the tables are intersecting but the getScanners method in
LCS expects them to be non-intersecting (as all sstables in the same level
should not be intersecting).
It could be that during the snapshot, a compaction occurs which writes more
sstables into the level. Then when it is supplied to the repair job, it fails
due to the ranges intersecting in the new and old sstables.
When we tried repairing with -par, we did not hit it. It also worked with 2.2.4
(which runs -par by default).
> merkle tree creation fails with NoSuchElementException
> --
>
> Key: CASSANDRA-8643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8643
> Project: Cassandra
> Issue Type: Bug
> Environment: We are running on a three node cluster with three in
> replication(C* 2.1.1). It uses a default C* installation and STCS.
>Reporter: Jan Karlsson
> Fix For: 2.1.3
>
>
> We have a problem that we encountered during testing over the weekend.
> During the tests we noticed that repairs started to fail. This error has
> occured on multiple non-coordinator nodes during repair. It also ran at least
> once without producing this error.
> We run repair -pr on all nodes on different days. CPU values were around 40%
> and disk was 50% full.
> From what I understand, the coordinator asked for merkle trees from the other
> two nodes. However one of the nodes fails to create his merkle tree.
> Unfortunately we do not have a way to reproduce this problem.
> The coordinator receives:
> {noformat}
> 2015-01-09T17:55:57.091+0100 INFO [RepairJobTask:4] RepairJob.java:145
> [repair #59455950-9820-11e4-b5c1-7797064e1316] requesting merkle trees for
> censored (to [/xx.90, /xx.98, /xx.82])
> 2015-01-09T17:55:58.516+0100 INFO [AntiEntropyStage:1]
> RepairSession.java:171 [repair #59455950-9820-11e4-b5c1-7797064e1316]
> Received merkle tree for censored from /xx.90
> 2015-01-09T17:55:59.581+0100 ERROR [AntiEntropySessions:76]
> RepairSession.java:303 [repair #59455950-9820-11e4-b5c1-7797064e1316] session
> completed with the following error
> org.apache.cassandra.exceptions.RepairException: [repair
> #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored,
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at
> org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:384)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:126)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> 2015-01-09T17:55:59.582+0100 ERROR [AntiEntropySessions:76]
> CassandraDaemon.java:153 Exception in thread
> Thread[AntiEntropySessions:76,5,RMI Runtime]
> java.lang.RuntimeException: org.apache.cassandra.exceptions.RepairException:
> [repair #59455950-9820-11e4-b5c1-7797064e1316 on censored/censored,
> (-6476420463551243930,-6471459119674373580]] Validation failed in /xx.98
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
>at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51] Caused by:
> org.apache.cassandr
[jira] [Commented] (CASSANDRA-8180) Optimize disk seek using min/max column name meta data when the LIMIT clause is used
[
https://issues.apache.org/jira/browse/CASSANDRA-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136987#comment-15136987
]
Branimir Lambov commented on CASSANDRA-8180:
Changes look good and patch looks good.
> Optimize disk seek using min/max column name meta data when the LIMIT clause
> is used
>
>
> Key: CASSANDRA-8180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8180
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
> Environment: Cassandra 2.0.10
>Reporter: DOAN DuyHai
>Assignee: Stefania
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 8180_001.yaml, 8180_002.yaml
>
>
> I was working on an example of sensor data table (timeseries) and face a use
> case where C* does not optimize read on disk.
> {code}
> cqlsh:test> CREATE TABLE test(id int, col int, val text, PRIMARY KEY(id,col))
> WITH CLUSTERING ORDER BY (col DESC);
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 10, '10');
> ...
> >nodetool flush test test
> ...
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 20, '20');
> ...
> >nodetool flush test test
> ...
> cqlsh:test> INSERT INTO test(id, col , val ) VALUES ( 1, 30, '30');
> ...
> >nodetool flush test test
> {code}
> After that, I activate request tracing:
> {code}
> cqlsh:test> SELECT * FROM test WHERE id=1 LIMIT 1;
> activity |
> timestamp| source| source_elapsed
> ---+--+---+
> execute_cql3_query |
> 23:48:46,498 | 127.0.0.1 | 0
> Parsing SELECT * FROM test WHERE id=1 LIMIT 1; |
> 23:48:46,498 | 127.0.0.1 | 74
>Preparing statement |
> 23:48:46,499 | 127.0.0.1 |253
> Executing single-partition query on test |
> 23:48:46,499 | 127.0.0.1 |930
> Acquiring sstable references |
> 23:48:46,499 | 127.0.0.1 |943
>Merging memtable tombstones |
> 23:48:46,499 | 127.0.0.1 | 1032
>Key cache hit for sstable 3 |
> 23:48:46,500 | 127.0.0.1 | 1160
>Seeking to partition beginning in data file |
> 23:48:46,500 | 127.0.0.1 | 1173
>Key cache hit for sstable 2 |
> 23:48:46,500 | 127.0.0.1 | 1889
>Seeking to partition beginning in data file |
> 23:48:46,500 | 127.0.0.1 | 1901
>Key cache hit for sstable 1 |
> 23:48:46,501 | 127.0.0.1 | 2373
>Seeking to partition beginning in data file |
> 23:48:46,501 | 127.0.0.1 | 2384
> Skipped 0/3 non-slice-intersecting sstables, included 0 due to tombstones |
> 23:48:46,501 | 127.0.0.1 | 2768
> Merging data from memtables and 3 sstables |
> 23:48:46,501 | 127.0.0.1 | 2784
> Read 2 live and 0 tombstoned cells |
> 23:48:46,501 | 127.0.0.1 | 2976
> Request complete |
> 23:48:46,501 | 127.0.0.1 | 3551
> {code}
> We can clearly see that C* hits 3 SSTables on disk instead of just one,
> although it has the min/max column meta data to decide which SSTable contains
> the most recent data.
> Funny enough, if we add a clause on the clustering column to the select, this
> time C* optimizes the read path:
> {code}
> cqlsh:test> SELECT * FROM test WHERE id=1 AND col > 25 LIMIT 1;
> activity |
> timestamp| source| source_elapsed
> ---+--+---+
> execute_cql3_query |
> 23:52:31,888 | 127.0.0.1 | 0
>Parsing SELECT * FROM test WHERE id=1 AND col > 25 LIMIT 1; |
> 23:52:31,888 | 127.0.0.1 | 60
>Preparing statement |
> 23:52:31,888 | 127.0.0.1 |277
> Executing single-partition query on test |
> 23:52:31,889 | 127.0.0.1 |961
>
svn commit: r1729177 - in /cassandra/site: publish/download/index.html publish/index.html src/settings.py
Author: jake Date: Mon Feb 8 14:15:18 2016 New Revision: 1729177 URL: http://svn.apache.org/viewvc?rev=1729177&view=rev Log: 2.2.5 and 2.1.13 release Modified: cassandra/site/publish/download/index.html cassandra/site/publish/index.html cassandra/site/src/settings.py Modified: cassandra/site/publish/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1729177&r1=1729176&r2=1729177&view=diff == --- cassandra/site/publish/download/index.html (original) +++ cassandra/site/publish/download/index.html Mon Feb 8 14:15:18 2016 @@ -89,16 +89,16 @@ Apache Cassandra 2.2 is supported until November 2016. - The latest release is 2.2.4, - released on 2015-12-07. + The latest release is 2.2.5, + released on 2016-02-08. - http://www.apache.org/dyn/closer.lua/cassandra/2.2.4/apache-cassandra-2.2.4-bin.tar.gz";>apache-cassandra-2.2.4-bin.tar.gz - [http://www.apache.org/dist/cassandra/2.2.4/apache-cassandra-2.2.4-bin.tar.gz.asc";>PGP] - [http://www.apache.org/dist/cassandra/2.2.4/apache-cassandra-2.2.4-bin.tar.gz.md5";>MD5] - [http://www.apache.org/dist/cassandra/2.2.4/apache-cassandra-2.2.4-bin.tar.gz.sha1";>SHA1] + http://www.apache.org/dyn/closer.lua/cassandra/2.2.5/apache-cassandra-2.2.5-bin.tar.gz";>apache-cassandra-2.2.5-bin.tar.gz + [http://www.apache.org/dist/cassandra/2.2.5/apache-cassandra-2.2.5-bin.tar.gz.asc";>PGP] + [http://www.apache.org/dist/cassandra/2.2.5/apache-cassandra-2.2.5-bin.tar.gz.md5";>MD5] + [http://www.apache.org/dist/cassandra/2.2.5/apache-cassandra-2.2.5-bin.tar.gz.sha1";>SHA1] http://wiki.apache.org/cassandra/DebianPackaging";>Debian installation instructions @@ -109,15 +109,15 @@ Apache Cassandra 2.1 is supported until November 2016 with critical fixes only. -The latest release is 2.1.12, released on 2015-12-07. +The latest release is 2.1.13, released on 2016-02-08. -http://www.apache.org/dyn/closer.lua/cassandra/2.1.12/apache-cassandra-2.1.12-bin.tar.gz";>apache-cassandra-2.1.12-bin.tar.gz -[http://www.apache.org/dist/cassandra/2.1.12/apache-cassandra-2.1.12-bin.tar.gz.asc";>PGP] -[http://www.apache.org/dist/cassandra/2.1.12/apache-cassandra-2.1.12-bin.tar.gz.md5";>MD5] -[http://www.apache.org/dist/cassandra/2.1.12/apache-cassandra-2.1.12-bin.tar.gz.sha1";>SHA1] +http://www.apache.org/dyn/closer.lua/cassandra/2.1.13/apache-cassandra-2.1.13-bin.tar.gz";>apache-cassandra-2.1.13-bin.tar.gz +[http://www.apache.org/dist/cassandra/2.1.13/apache-cassandra-2.1.13-bin.tar.gz.asc";>PGP] +[http://www.apache.org/dist/cassandra/2.1.13/apache-cassandra-2.1.13-bin.tar.gz.md5";>MD5] +[http://www.apache.org/dist/cassandra/2.1.13/apache-cassandra-2.1.13-bin.tar.gz.sha1";>SHA1] @@ -169,16 +169,16 @@ [http://www.apache.org/dist/cassandra/3.0.2/apache-cassandra-3.0.2-src.tar.gz.sha1";>SHA1] -http://www.apache.org/dyn/closer.lua/cassandra/2.2.4/apache-cassandra-2.2.4-src.tar.gz";>apache-cassandra-2.2.4-src.tar.gz -[http://www.apache.org/dist/cassandra/2.2.4/apache-cassandra-2.2.4-src.tar.gz.asc";>PGP] -[http://www.apache.org/dist/cassandra/2.2.4/apache-cassandra-2.2.4-src.tar.gz.md5";>MD5] -[http://www.apache.org/dist/cassandra/2.2.4/apache-cassandra-2.2.4-src.tar.gz.sha1";>SHA1] +http://www.apache.org/dyn/closer.lua/cassandra/2.2.5/apache-cassandra-2.2.5-src.tar.gz";>apache-cassandra-2.2.5-src.tar.gz +[http://www.apache.org/dist/cassandra/2.2.5/apache-cassandra-2.2.5-src.tar.gz.asc";>PGP] +[http://www.apache.org/dist/cassandra/2.2.5/apache-cassandra-2.2.5-src.tar.gz.md5";>MD5] +[http://www.apache.org/dist/cassandra/2.2.5/apache-cassandra-2.2.5-src.tar.gz.sha1";>SHA1] -http://www.apache.org/dyn/closer.lua/cassandra/2.1.12/apache-cassandra-2.1.12-src.tar.gz";>apache-cassandra-2.1.12-src.tar.gz -[http://www.apache.org/dist/cassandra/2.1.12/apache-cassandra-2.1.12-src.tar.gz.asc";>PGP] -[http://www.apache.org/dist/cassandra/2.1.12/apache-cassandra-2.1.12-src.tar.gz.md5";>MD5] -[http://www.apache.org/dist/cassandra/2.1.12/apache-cassandra-2.1.12-src.tar.gz.sha1";>SHA1] +http://www.apache.org/dyn/closer.lua/cassandra/2.1.13/apache-cassandra-2.1.13-src.tar.gz";>apache-cassandra-2.1.13-src.tar.gz +[http://www.apache.org/dist/cassandra/2.1.13/apache-cassandra-2.1.13-src.tar.gz.asc";>PGP] +[http://www.apache.org/dist/cassandra/2.1.13/apache-cassandra-2.1.13-src.tar.gz.md5";>MD5] +[http://www.apache.org/dist/cassandra/2.1.13/apache-cassandra-2.1.13-src.tar.gz.sha1";>SHA1] Modified: cassandra/site/publish/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/index.html?rev=1729177&r1=1729176&r2=1729177&view=diff
[jira] [Commented] (CASSANDRA-11082) netty's level hadn't prevent OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136968#comment-15136968 ] T Jake Luciani commented on CASSANDRA-11082: It's true, we should be checking isWritable() though I don't imagine we should condone/support many slow clients as a good use case for cassandra (it should be behind a firewall with local connections). The simplest place to put it is in our flushing logic. But what should we do drop the data on the floor? I imagine that would break the protocol so might be better to simply close the connection? wdyt [~slebresne] > netty's level hadn't prevent OOM when receiver handle slow. > --- > > Key: CASSANDRA-11082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11082 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: fujian > > as we know, netty will OOM when received client is slow. > due to if receiver can't handle response fast so that cassandra server can't > flush data. it will cause channeloutbuffer with big size. > we see the cassandra had configure write high/low water level, but I can't > found any code to judge iswritable. so it will have possible OOM > why cassandra hadn't handle this case? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11056) Use max timestamp to decide DTCS-timewindow-membership
[ https://issues.apache.org/jira/browse/CASSANDRA-11056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136942#comment-15136942 ] Marcus Eriksson commented on CASSANDRA-11056: - [~Bj0rn] had any time to think about this yet? The easy way (for us) would be to add yet another configuration option for this, but that really sucks for the user > Use max timestamp to decide DTCS-timewindow-membership > -- > > Key: CASSANDRA-11056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11056 > Project: Cassandra > Issue Type: Improvement > Components: Compaction >Reporter: Marcus Eriksson >Assignee: Björn Hegerfors > Labels: dtcs > Attachments: cassandra-2.2-CASSANDRA-11056.txt > > > TWCS (CASSANDRA-9666) uses max timestamp to decide time window membership, we > should do the same in DTCS so that users can configure DTCS to work exactly > like TWCS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11090) Hinted Handoff loop
[ https://issues.apache.org/jira/browse/CASSANDRA-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136934#comment-15136934 ] Aleksey Yeschenko commented on CASSANDRA-11090: --- bq. the hint crc file isn't deleted in the 3.0 branch after hints are dispatched (but is in trunk) CASSANDRA-10947 is definitely there in both 3.0 and trunk (so 3.0.3, 3.3, future 3.4). Are you certain you've tested with a recent cassandra-3.0 branch? > Hinted Handoff loop > --- > > Key: CASSANDRA-11090 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11090 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.x > > > After the hints executor finishes sending hints, another hints file is > created for the same host, which is then processed on the next go around. > This continues indefinitely. The new hint files are empty, so there shouldn't > be any network traffic. However, there's still unnecessary hint activity, and > the hint crc file isn't deleted in the 3.0 branch after hints are dispatched > (but is in trunk), so any hint activity will trigger ~8640 files being > created per day until the node is restarted. Restarting the node fixes the > problem, after the existing hint files are processed. > This can be duplicated on cassandra-3.0 to trunk with this script: > https://gist.github.com/bdeggleston/13fbb9e70c0c0bd277c7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
[
https://issues.apache.org/jira/browse/CASSANDRA-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-11062:
--
Fix Version/s: 3.x
> BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
> -
>
> Key: CASSANDRA-11062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
> Project: Cassandra
> Issue Type: Bug
>Reporter: Caleb William Rackliffe
>Assignee: Caleb William Rackliffe
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
> Attachments: 11062-3.0.txt
>
>
> {{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
> tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
> call {{replayFailedBatches()}} after drain has instructed both it and the
> {{HintsService}} to shut down. When this happens, we get an exception when
> that tries to submit a task to the executor in {{HintsWriteExecutor}}:
> {noformat}
> ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
> Exception in thread Thread[BatchlogTasks:1,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> [na:1.8.0_65]
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> ~[na:1.8.0_65]
> at
> org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_65]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10867) thrift_tests.py:TestCQLAccesses.test_range_tombstone_and_static failing on C* 2.1
[ https://issues.apache.org/jira/browse/CASSANDRA-10867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136900#comment-15136900 ] Aleksey Yeschenko commented on CASSANDRA-10867: --- Bummer. +1. > thrift_tests.py:TestCQLAccesses.test_range_tombstone_and_static failing on C* > 2.1 > - > > Key: CASSANDRA-10867 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10867 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Sylvain Lebresne > Labels: dtest > > http://cassci.datastax.com/job/cassandra-2.1_dtest/376/testReport/thrift_tests/TestCQLAccesses/test_range_tombstone_and_static/history/ > I haven't had enough experience with thrift or the thrift tests to debug > this. It passes on 2.2+. I've reproduced this failure locally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9928) Add Support for multiple non-primary key columns in Materialized View primary keys
[ https://issues.apache.org/jira/browse/CASSANDRA-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136898#comment-15136898 ] Aleksey Yeschenko commented on CASSANDRA-9928: -- [~mbroecheler] Is the limitation outlined by Tyler above still compatible with the use case you got in mind? > Add Support for multiple non-primary key columns in Materialized View primary > keys > -- > > Key: CASSANDRA-9928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9928 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani > Labels: materializedviews > Fix For: 3.x > > > Currently we don't allow > 1 non primary key from the base table in a MV > primary key. We should remove this restriction assuming we continue > filtering out nulls. With allowing nulls in the MV columns there are a lot > of multiplicative implications we need to think through. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11118) Consider removing support for custom types
[
https://issues.apache.org/jira/browse/CASSANDRA-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko resolved CASSANDRA-8.
---
Resolution: Not A Problem
> Consider removing support for custom types
> --
>
> Key: CASSANDRA-8
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8
> Project: Cassandra
> Issue Type: Wish
>Reporter: Robert Stupp
>Priority: Minor
>
> Custom types (and maybe all types that extend AbstractType but have no CQL3
> counterpart) become difficult to be properly supported.
> There are a couple of reasons:
> * Custom types and even composite types need to be expressed using 'blob
> syntax' as in CASSANDRA-11064 to provide full end-to-end support (C* nodes
> and all drivers).
> * Custom-type implementations become more difficult to maintain (by their
> developers) as we add more functionality (e.g. JSON or CQL literal
> generation) and contracts (like the different comparison modes and
> implementations) to AbstractType
> * Operational support for custom types (installing and upgrading C* releases)
> is more difficult (provide the correct custom-type implementations for the
> specific C* release; not a new reason, of course)
> * We still maintain two type hierarchies for the "same thing" (column types):
> one starting at CQL3Type and one at AbstractType (plus serializers), which
> are closely related and coupled.
> * There is "no need" to maintain AbstractType as a client protocol
> requirement starting with 4.x as Thrift will be removed. In reality, the
> support of drivers for composite types or even custom types is fairly
> rudimentary, if existent.
> * I'm also a bit concerned that there might be hidden issues related to this
> _old and rarely used and even least thought-of stuff_. I mean, we (at least
> I) don't always think about these old types. Like CASSANDRA-11064 that has
> the potential to bring down a cluster.
> I would not propose to remove custom types in 4.x but officially deprecate
> the functionality in the near future and communicate an "official" date
> (version number) when it will be removed.
> In the mean time there might be a configuration option like
> {{enable_custom_types}} or {{allow_non_cql3_types}} which defaults to
> {{false}} and either issues warnings (in the log and via native protocol)
> when those types are used in DDL statements or completely prevents that
> (returning an error, prevent startup, whatever). We can also convert all
> non-CQL3 types to BLOB in the schema tables as the "implementation to remove
> custom types".
> TBH, I have absolutely no idea how many people really use composite types or
> even custom types. But I assume that "only a handful" of applications really
> use non-CQL3 types with C* 4.x (so without Thrift).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11118) Consider removing support for custom types
[
https://issues.apache.org/jira/browse/CASSANDRA-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136889#comment-15136889
]
Aleksey Yeschenko commented on CASSANDRA-8:
---
Don't have much to add to Sylvain's arguments, just throwing in my -1 to the
idea of removing support for them.
There is one thing that we care about when it comes to custom types - and that
is the ability to mandate them being byte order compatible in the future. But
we already decided to do so (see CASSANDRA-9901 and CASSANDRA-6936 discussions).
Closing the issue as Not A Problem.
> Consider removing support for custom types
> --
>
> Key: CASSANDRA-8
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8
> Project: Cassandra
> Issue Type: Wish
>Reporter: Robert Stupp
>Priority: Minor
>
> Custom types (and maybe all types that extend AbstractType but have no CQL3
> counterpart) become difficult to be properly supported.
> There are a couple of reasons:
> * Custom types and even composite types need to be expressed using 'blob
> syntax' as in CASSANDRA-11064 to provide full end-to-end support (C* nodes
> and all drivers).
> * Custom-type implementations become more difficult to maintain (by their
> developers) as we add more functionality (e.g. JSON or CQL literal
> generation) and contracts (like the different comparison modes and
> implementations) to AbstractType
> * Operational support for custom types (installing and upgrading C* releases)
> is more difficult (provide the correct custom-type implementations for the
> specific C* release; not a new reason, of course)
> * We still maintain two type hierarchies for the "same thing" (column types):
> one starting at CQL3Type and one at AbstractType (plus serializers), which
> are closely related and coupled.
> * There is "no need" to maintain AbstractType as a client protocol
> requirement starting with 4.x as Thrift will be removed. In reality, the
> support of drivers for composite types or even custom types is fairly
> rudimentary, if existent.
> * I'm also a bit concerned that there might be hidden issues related to this
> _old and rarely used and even least thought-of stuff_. I mean, we (at least
> I) don't always think about these old types. Like CASSANDRA-11064 that has
> the potential to bring down a cluster.
> I would not propose to remove custom types in 4.x but officially deprecate
> the functionality in the near future and communicate an "official" date
> (version number) when it will be removed.
> In the mean time there might be a configuration option like
> {{enable_custom_types}} or {{allow_non_cql3_types}} which defaults to
> {{false}} and either issues warnings (in the log and via native protocol)
> when those types are used in DDL statements or completely prevents that
> (returning an error, prevent startup, whatever). We can also convert all
> non-CQL3 types to BLOB in the schema tables as the "implementation to remove
> custom types".
> TBH, I have absolutely no idea how many people really use composite types or
> even custom types. But I assume that "only a handful" of applications really
> use non-CQL3 types with C* 4.x (so without Thrift).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11120) Leak Detected while bringing nodes up and down when under stress.
[
https://issues.apache.org/jira/browse/CASSANDRA-11120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136887#comment-15136887
]
Aleksey Yeschenko commented on CASSANDRA-11120:
---
Any code differences in 3.3 and trunk branches, or should I just merge ahead
ignoring them (your 3.3 + trunk branches) entirely?
> Leak Detected while bringing nodes up and down when under stress.
> -
>
> Key: CASSANDRA-11120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11120
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Ariel Weisberg
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> So after CASSANDRA-10688 has been fixed I'm able to reproduce some leaks
> consistently with my stress test suite that is doing repairs/stress/bringing
> nodes up and down.
> One such example:
> {noformat}
> ERROR [Strong-Reference-Leak-Detector:1] 2016-02-03 23:32:38,827
> NoSpamLogger.java:97 - Strong self-ref loop detected
> [/var/lib/cassandra/data/keyspace1/standard1-7cddd4c1cacc11e5aa69f375b464842d/ma-14-big,
> private java.util.concurrent.ScheduledFuture
> org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy.readMeterSyncFuture-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> final java.util.concurrent.ScheduledThreadPoolExecutor
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.this$0-java.util.concurrent.ScheduledThreadPoolExecutor,
> private final java.util.HashSet
> java.util.concurrent.ThreadPoolExecutor.workers-java.util.HashSet, private
> transient java.util.HashMap java.util.HashSet.map-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> final java.lang.Object
> java.util.HashMap$Node.key-java.util.concurrent.ThreadPoolExecutor$Worker,
> final java.lang.Thread
> java.util.concurrent.ThreadPoolExecutor$Worker.thread-java.lang.Thread,
> private java.lang.ThreadGroup java.lang.Thread.group-java.lang.ThreadGroup,
> private final java.lang.ThreadGroup
> java.lang.ThreadGroup.parent-java.lang.ThreadGroup, java.lang.Thread[]
> java.lang.ThreadGroup.threads-[Ljava.lang.Thread;, java.lang.Thread[]
> java.lang.ThreadGroup.threads-java.lang.Thread, private java.lang.Runnable
> java.lang.Thread.target-java.util.concurrent.ThreadPoolExecutor$Worker, final
> java.util.concurrent.ThreadPoolExecutor
> java.util.concurrent.ThreadPoolExecutor$Worker.this$0-java.util.concurrent.ScheduledThreadPoolExecutor,
> private final java.util.concurrent.BlockingQueue
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue,
> private final java.util.concurrent.BlockingQueue
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> private java.util.concurrent.Callable
> java.util.concurrent.FutureTask.callable-java.util.concurrent.Executors$RunnableAdapter,
> final java.lang.Runnable
> java.util.concurrent.Executors$RunnableAdapter.task-sun.rmi.transport.DGCImpl$1,
> final sun.rmi.transport.DGCImpl
> sun.rmi.transport.DGCImpl$1.this$0-sun.rmi.transport.DGCImpl, private
> java.util.Map sun.rmi.transport.DGCImpl.leaseTable-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> java.lang.Object
> java.util.HashMap$Node.value-sun.rmi.transport.DGCImpl$LeaseInfo,
> java.util.Set
> sun.rmi.transport.DGCImpl$LeaseInfo.notifySet-java.util.HashSet, private
> transient java.util.HashMap java.util.HashSet.map-java.util.HashMap,
> transient java.util.HashMap$Node[]
> java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient
> java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node,
> final java.lang.Object java.util.HashMap$Node.key-sun.rmi.transport.Target,
> private final sun.rmi.transport.WeakRef
> sun.rmi.transport.Target.weakImpl-sun.rmi.transport.WeakRef, private
> java.lang.Object
> sun.rmi.transport.WeakRef.strongRef-javax.management.remote.rmi.RMIJRMPServerImpl,
> private final java.util.List
> javax.management.remote.rmi.RMIServerImpl.clientList-java.util.ArrayList,
> transient java.lang.Object[]
> java.util.ArrayList.elementData-[Ljava.lang.Object;, transient
> java.lang.Object[]
> java.util.ArrayList.elementData-java.lang.ref.WeakReference, private
> java.lang.Object
> java.lang.ref.Reference.referent-javax.management.remote.rmi.RMIConnectionImpl,
> private final javax.management.MBeanServer
> javax.man
[jira] [Commented] (CASSANDRA-11030) utf-8 characters incorrectly displayed/inserted on cqlsh on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-11030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136884#comment-15136884
]
Aleksey Yeschenko commented on CASSANDRA-11030:
---
Committed as
[d295c7c69886f63739792d60d876b012a408cc07|https://github.com/apache/cassandra/commit/d295c7c69886f63739792d60d876b012a408cc07]
to 2.2, merged with 3.0 and trunk. Thanks.
> utf-8 characters incorrectly displayed/inserted on cqlsh on Windows
> ---
>
> Key: CASSANDRA-11030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11030
> Project: Cassandra
> Issue Type: Bug
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh, windows
> Fix For: 2.2.6, 3.0.4, 3.4
>
>
> {noformat}
> C:\Users\Paulo\Repositories\cassandra [2.2-10948 +6 ~1 -0 !]> .\bin\cqlsh.bat
> --encoding utf-8
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.2.4-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
> Use HELP for help.
> cqlsh> INSERT INTO bla.test (bla ) VALUES ('não') ;
> cqlsh> select * from bla.test;
> bla
> -
> n?o
> (1 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[5/6] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/23f62962 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/23f62962 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/23f62962 Branch: refs/heads/cassandra-3.0 Commit: 23f629628ecb00bc997b88c9ffcc296be5d4f701 Parents: 58821ce d295c7c Author: Aleksey Yeschenko Authored: Mon Feb 8 12:19:38 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 12:19:38 2016 + -- CHANGES.txt | 1 + bin/cqlsh.py | 41 - 2 files changed, 37 insertions(+), 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/23f62962/CHANGES.txt -- diff --cc CHANGES.txt index 0fb8f34,b0a5062..6302ce6 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,7 -1,7 +1,8 @@@ -2.2.6 +3.0.4 + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 (CASSANDRA-11001) +Merged from 2.2.6 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) * Gossiper#isEnabled is not thread safe (CASSANDRA-6) - * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) Merged from 2.1: * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) http://git-wip-us.apache.org/repos/asf/cassandra/blob/23f62962/bin/cqlsh.py --
[4/6] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/23f62962 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/23f62962 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/23f62962 Branch: refs/heads/trunk Commit: 23f629628ecb00bc997b88c9ffcc296be5d4f701 Parents: 58821ce d295c7c Author: Aleksey Yeschenko Authored: Mon Feb 8 12:19:38 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 8 12:19:38 2016 + -- CHANGES.txt | 1 + bin/cqlsh.py | 41 - 2 files changed, 37 insertions(+), 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/23f62962/CHANGES.txt -- diff --cc CHANGES.txt index 0fb8f34,b0a5062..6302ce6 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,7 -1,7 +1,8 @@@ -2.2.6 +3.0.4 + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 (CASSANDRA-11001) +Merged from 2.2.6 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030) * Gossiper#isEnabled is not thread safe (CASSANDRA-6) - * Fix paging on DISTINCT queries repeats result when first row in partition changes (CASSANDRA-10010) Merged from 2.1: * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) http://git-wip-us.apache.org/repos/asf/cassandra/blob/23f62962/bin/cqlsh.py --
[3/6] cassandra git commit: (cqlsh) Support utf-8/cp65001 encoding on Windows
(cqlsh) Support utf-8/cp65001 encoding on Windows
patch by Paulo Motta; reviewed by Stefania Alborghetti for CASSANDRA-11030
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d295c7c6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d295c7c6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d295c7c6
Branch: refs/heads/trunk
Commit: d295c7c69886f63739792d60d876b012a408cc07
Parents: 6982aaa
Author: Paulo Motta
Authored: Tue Jan 19 13:10:59 2016 -0200
Committer: Aleksey Yeschenko
Committed: Mon Feb 8 12:16:23 2016 +
--
CHANGES.txt | 1 +
bin/cqlsh.py | 41 -
2 files changed, 37 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d295c7c6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 12198e4..b0a5062 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.6
+ * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
* Gossiper#isEnabled is not thread safe (CASSANDRA-6)
* Fix paging on DISTINCT queries repeats result when first row in partition
changes (CASSANDRA-10010)
Merged from 2.1:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d295c7c6/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 17c42a6..630c92b 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -52,6 +52,9 @@ from uuid import UUID
if sys.version_info[0] != 2 or sys.version_info[1] != 7:
sys.exit("\nCQL Shell supports only Python 2.7\n")
+UTF8 = 'utf-8'
+CP65001 = 'cp65001' # Win utf-8 variant
+
description = "CQL Shell for Apache Cassandra"
version = "5.0.1"
@@ -101,6 +104,12 @@ elif webbrowser._tryorder[0] == 'xdg-open' and
os.environ.get('XDG_DATA_DIRS', '
# is a ../lib dir, use bundled libs there preferentially.
ZIPLIB_DIRS = [os.path.join(CASSANDRA_PATH, 'lib')]
myplatform = platform.system()
+is_win = myplatform == 'Windows'
+
+# Workaround for supporting CP65001 encoding on python < 3.3
(https://bugs.python.org/issue13216)
+if is_win and sys.version_info < (3, 3):
+codecs.register(lambda name: codecs.lookup(UTF8) if name == CP65001 else
None)
+
if myplatform == 'Linux':
ZIPLIB_DIRS.append('/usr/share/cassandra/lib')
@@ -723,11 +732,15 @@ class Shell(cmd.Cmd):
self.max_trace_wait = max_trace_wait
self.session.max_trace_wait = max_trace_wait
+
+self.tty = tty
if encoding is None:
encoding = locale.getpreferredencoding()
if encoding is None:
-encoding = 'utf-8'
+encoding = UTF8
self.encoding = encoding
+self.check_windows_encoding()
+
self.output_codec = codecs.lookup(encoding)
self.statement = StringIO()
@@ -737,7 +750,7 @@ class Shell(cmd.Cmd):
self.prompt = ''
if stdin is None:
stdin = sys.stdin
-self.tty = tty
+
if tty:
self.reset_prompt()
self.report_connection()
@@ -753,6 +766,19 @@ class Shell(cmd.Cmd):
self.statement_error = False
self.single_statement = single_statement
+@property
+def is_using_utf8(self):
+# utf8 encodings from https://docs.python.org/{2,3}/library/codecs.html
+return self.encoding.replace('-', '_').lower() in ['utf', 'utf_8',
'u8', 'utf8', CP65001]
+
+def check_windows_encoding(self):
+if is_win and os.name == 'nt' and self.tty and \
+ self.is_using_utf8 and sys.stdout.encoding != CP65001:
+self.printerr("\nWARNING: console codepage must be set to cp65001 "
+ "to support {} encoding on Windows platforms.\n"
+ "If you experience encoding problems, change your
console"
+ " codepage with 'chcp 65001' before starting
cqlsh.\n".format(self.encoding))
+
def refresh_schema_metadata_best_effort(self):
try:
self.conn.refresh_schema_metadata(5) # will throw exception if
there is a schema mismatch
@@ -1004,7 +1030,7 @@ class Shell(cmd.Cmd):
try:
import readline
except ImportError:
-if myplatform == 'Windows':
+if is_win:
print "WARNING: pyreadline dependency missing. Install to
enable tab completion."
pass
else:
@@ -1024,7 +1050,12 @@ class Shell(cmd.Cmd):
def get_input_line(self, prompt=''):
if self.tty:
-self.lastcmd = raw_input(prompt).decode(self.encoding)
+try:
+self.lastcmd = raw_input(prompt).decode(self.encoding)
[6/6] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71ccb16b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71ccb16b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71ccb16b
Branch: refs/heads/trunk
Commit: 71ccb16bf9149a01cc353d39f088917b74ee353a
Parents: 696cd91 23f6296
Author: Aleksey Yeschenko
Authored: Mon Feb 8 12:28:32 2016 +
Committer: Aleksey Yeschenko
Committed: Mon Feb 8 12:28:32 2016 +
--
CHANGES.txt | 1 +
bin/cqlsh.py | 41 -
2 files changed, 37 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71ccb16b/CHANGES.txt
--
diff --cc CHANGES.txt
index 179da46,6302ce6..2d50c10
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,22 -1,7 +1,23 @@@
-3.0.4
+3.4
+ * Add LIKE support to CQL3 (CASSANDRA-11067)
+ * Generic Java UDF types (CASSANDRA-10819)
+ * cqlsh: Include sub-second precision in timestamps by default
(CASSANDRA-10428)
+ * Set javac encoding to utf-8 (CASSANDRA-11077)
+ * Integrate SASI index into Cassandra (CASSANDRA-10661)
+ * Add --skip-flush option to nodetool snapshot
+ * Skip values for non-queried columns (CASSANDRA-10657)
+ * Add support for secondary indexes on static columns (CASSANDRA-8103)
+ * CommitLogUpgradeTestMaker creates broken commit logs (CASSANDRA-11051)
+ * Add metric for number of dropped mutations (CASSANDRA-10866)
+ * Simplify row cache invalidation code (CASSANDRA-10396)
+ * Support user-defined compaction through nodetool (CASSANDRA-10660)
+ * Stripe view locks by key and table ID to reduce contention
(CASSANDRA-10981)
+ * Add nodetool gettimeout and settimeout commands (CASSANDRA-10953)
+ * Add 3.0 metadata to sstablemetadata output (CASSANDRA-10838)
+Merged from 3.0:
* Hadoop integration is incompatible with Cassandra Driver 3.0.0
(CASSANDRA-11001)
Merged from 2.2.6
+ * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
* Gossiper#isEnabled is not thread safe (CASSANDRA-6)
Merged from 2.1:
* Avoid major compaction mixing repaired and unrepaired sstables in DTCS
(CASSANDRA-3)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71ccb16b/bin/cqlsh.py
--
diff --cc bin/cqlsh.py
index dcb90b6,a7292e6..02952c3
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@@ -52,10 -52,9 +52,13 @@@ from uuid import UUI
if sys.version_info[0] != 2 or sys.version_info[1] != 7:
sys.exit("\nCQL Shell supports only Python 2.7\n")
+# see CASSANDRA-10428
+if platform.python_implementation().startswith('Jython'):
+sys.exit("\nCQL Shell does not run on Jython\n")
+
+ UTF8 = 'utf-8'
+ CP65001 = 'cp65001' # Win utf-8 variant
+
description = "CQL Shell for Apache Cassandra"
version = "5.0.1"
@@@ -727,8 -732,14 +736,10 @@@ class Shell(cmd.Cmd)
self.current_keyspace = keyspace
-self.display_timestamp_format = display_timestamp_format
-self.display_nanotime_format = display_nanotime_format
-self.display_date_format = display_date_format
-
self.max_trace_wait = max_trace_wait
self.session.max_trace_wait = max_trace_wait
+
+ self.tty = tty
if encoding is None:
encoding = locale.getpreferredencoding()
if encoding is None:
