[jira] [Commented] (CASSANDRA-8803) Implement transitional mode in C* that will accept both encrypted and non-encrypted client traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14907779#comment-14907779 ] Norman Maurer commented on CASSANDRA-8803: -- [~brandon.williams] against which branch I should do the patch ? > Implement transitional mode in C* that will accept both encrypted and > non-encrypted client traffic > -- > > Key: CASSANDRA-8803 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8803 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Vishy Kasar > > We have some non-secure clusters taking live traffic in production from > active clients. We want to enable client to node encryption on these > clusters. Once we set the client_encryption_options enabled to true in yaml > and bounce a cassandra node in the ring, the existing clients that do not do > SSL will fail to connect to that node. > There does not seem to be a good way to roll this change with out taking an > outage. Can we implement a transitional mode in C* that will accept both > encrypted and non-encrypted client traffic? We would enable this during > transition and turn it off after both server and client start talking SSL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8844) Change Data Capture (CDC)
[ https://issues.apache.org/jira/browse/CASSANDRA-8844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14907866#comment-14907866 ] DOAN DuyHai commented on CASSANDRA-8844: bq. We recently added a form of mutation-based-repair on the path on repair for MV -> it passes the mutation through to apply to view replicas without applying to the local CommitLog as the SSTables are swapped in to the Tracker. With minimal modification we can use a similar path for repair on CDC-enabled tables. Excellent, it will reduce the overhead for repair bq. we could either allow write-survey nodes to participate in CDC and thus open them to throwing UE if CDC logs aren't consumed I believe the primary goal of write survey mode, as its name states, is to watch the behavior of a new node under write workload with various settings. Since adding CDC will have a perf impact on the write path (be it small impact or not doesn't matter), I think it is relevant to activate CDC on write survey node too so that the user has the real perf metrics > Change Data Capture (CDC) > - > > Key: CASSANDRA-8844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8844 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Tupshin Harper >Assignee: Joshua McKenzie >Priority: Critical > Fix For: 3.x > > > "In databases, change data capture (CDC) is a set of software design patterns > used to determine (and track) the data that has changed so that action can be > taken using the changed data. Also, Change data capture (CDC) is an approach > to data integration that is based on the identification, capture and delivery > of the changes made to enterprise data sources." > -Wikipedia > As Cassandra is increasingly being used as the Source of Record (SoR) for > mission critical data in large enterprises, it is increasingly being called > upon to act as the central hub of traffic and data flow to other systems. In > order to try to address the general need, we (cc [~brianmhess]), propose > implementing a simple data logging mechanism to enable per-table CDC patterns. > h2. The goals: > # Use CQL as the primary ingestion mechanism, in order to leverage its > Consistency Level semantics, and in order to treat it as the single > reliable/durable SoR for the data. > # To provide a mechanism for implementing good and reliable > (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) > continuous semi-realtime feeds of mutations going into a Cassandra cluster. > # To eliminate the developmental and operational burden of users so that they > don't have to do dual writes to other systems. > # For users that are currently doing batch export from a Cassandra system, > give them the opportunity to make that realtime with a minimum of coding. > h2. The mechanism: > We propose a durable logging mechanism that functions similar to a commitlog, > with the following nuances: > - Takes place on every node, not just the coordinator, so RF number of copies > are logged. > - Separate log per table. > - Per-table configuration. Only tables that are specified as CDC_LOG would do > any logging. > - Per DC. We are trying to keep the complexity to a minimum to make this an > easy enhancement, but most likely use cases would prefer to only implement > CDC logging in one (or a subset) of the DCs that are being replicated to > - In the critical path of ConsistencyLevel acknowledgment. Just as with the > commitlog, failure to write to the CDC log should fail that node's write. If > that means the requested consistency level was not met, then clients *should* > experience UnavailableExceptions. > - Be written in a Row-centric manner such that it is easy for consumers to > reconstitute rows atomically. > - Written in a simple format designed to be consumed *directly* by daemons > written in non JVM languages > h2. Nice-to-haves > I strongly suspect that the following features will be asked for, but I also > believe that they can be deferred for a subsequent release, and to guage > actual interest. > - Multiple logs per table. This would make it easy to have multiple > "subscribers" to a single table's changes. A workaround would be to create a > forking daemon listener, but that's not a great answer. > - Log filtering. Being able to apply filters, including UDF-based filters > would make Casandra a much more versatile feeder into other systems, and > again, reduce complexity that would otherwise need to be built into the > daemons. > h2. Format and Consumption > - Cassandra would only write to the CDC log, and never delete from it. > - Cleaning up consumed logfiles would be the client daemon's responibility > - Logfile size should probably be configurable. > - Logfiles should be name
[jira] [Updated] (CASSANDRA-10397) CQLSH not displaying correct timezone
[ https://issues.apache.org/jira/browse/CASSANDRA-10397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suleman Rai updated CASSANDRA-10397: Description: CQLSH is not adding the timezone offset to the timestamp after it has been inserted into a table. create table test(id int PRIMARY KEY, time timestamp); INSERT INTO test(id,time) values (1,dateof(now())); select *from test; id | time +- 1 | 2015-09-25 13:00:32 It is just displaying the default UTC timestamp without adding the timezone offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is +0800. was: CQLSH is adding the timezone offset to the timestamp after it has been inserted into a table. create table test(id int PRIMARY KEY, time timestamp); INSERT INTO test(id,time) values (1,dateof(now())); select *from test; id | time +- 1 | 2015-09-25 13:00:32 It is just displaying the default UTC timestamp without adding the timezone offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is +0800. > CQLSH not displaying correct timezone > - > > Key: CASSANDRA-10397 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10397 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Ubuntu 14.04 LTS >Reporter: Suleman Rai >Priority: Blocker > Fix For: 2.1.x, 2.2.x > > > CQLSH is not adding the timezone offset to the timestamp after it has been > inserted into a table. > create table test(id int PRIMARY KEY, time timestamp); > INSERT INTO test(id,time) values (1,dateof(now())); > select *from test; > id | time > +- > 1 | 2015-09-25 13:00:32 > It is just displaying the default UTC timestamp without adding the timezone > offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is > +0800. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10397) CQLSH not displaying correct timezone
Suleman Rai created CASSANDRA-10397: --- Summary: CQLSH not displaying correct timezone Key: CASSANDRA-10397 URL: https://issues.apache.org/jira/browse/CASSANDRA-10397 Project: Cassandra Issue Type: Bug Components: Core Environment: Ubuntu 14.04 LTS Reporter: Suleman Rai Priority: Blocker Fix For: 2.1.x, 2.2.x CQLSH is adding the timezone offset to the timestamp after it has been inserted into a table. create table test(id int PRIMARY KEY, time timestamp); INSERT INTO test(id,time) values (1,dateof(now())); select *from test; id | time +- 1 | 2015-09-25 13:00:32 It is just displaying the default UTC timestamp without adding the timezone offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is +0800. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8803) Implement transitional mode in C* that will accept both encrypted and non-encrypted client traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908019#comment-14908019 ] Brandon Williams commented on CASSANDRA-8803: - Trunk is probably the best bet right now. > Implement transitional mode in C* that will accept both encrypted and > non-encrypted client traffic > -- > > Key: CASSANDRA-8803 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8803 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Vishy Kasar > > We have some non-secure clusters taking live traffic in production from > active clients. We want to enable client to node encryption on these > clusters. Once we set the client_encryption_options enabled to true in yaml > and bounce a cassandra node in the ring, the existing clients that do not do > SSL will fail to connect to that node. > There does not seem to be a good way to roll this change with out taking an > outage. Can we implement a transitional mode in C* that will accept both > encrypted and non-encrypted client traffic? We would enable this during > transition and turn it off after both server and client start talking SSL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10000) Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908108#comment-14908108
]
Aaron Ploetz commented on CASSANDRA-1:
--
I have a feeling that this ticket may have a bug that is causing a bug with how
timestamps are displayed in 'nix based systems. I noticed yesterday that my
2.2.1 instance was showing times in UTC. I was too busy to think much of it at
the time. But then this morning I ran across this question on StackOverflow
(http://stackoverflow.com/questions/32778433/cassandra-cqlsh-not-displaying-correct-timezone)
which basically confirms that this is happening in 2.2.1 and 1.2.9.
Note, times appear to be going in correctly, but are always displayed in UTC.
{{aploetz@cqlsh:stackoverflow> INSERT INTO timestamptest
(userid,activetime,value) VALUES ('b','2015-09-25 09:40:11-0500','value1');}}
{{aploetz@cqlsh:stackoverflow> SELECT * FROM stackoverflow.timestamptest ;}}
{{userid | activetime | value}}
{{+--+}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{(4 rows)}}
> Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
>
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
> Issue Type: Bug
> Environment: windows
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh, windows
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
>
> The following test fails on Windows:
> {code:none}
> def test_past_and_future_dates(self):
> self.cluster.populate(1)
> self.cluster.start(wait_for_binary_proto=True)
> node1, = self.cluster.nodelist()
> node1.run_cqlsh(cmds="""
> CREATE KEYSPACE simple WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> use simple;
> create TABLE simpledate (id int PRIMARY KEY , value timestamp ) ;
> insert into simpledate (id, value) VALUES (1,
> '2143-04-19T11:21:01+');
> insert into simpledate (id, value) VALUES (2,
> '1943-04-19T11:21:01+')""")
> session = self.patient_cql_connection(node1)
> rows = session.execute("select id, value from simple.simpledate")
> output, err = self.run_cqlsh(node1, 'use simple; SELECT * FROM
> simpledate')
> self.assertIn("2143-04", output)
> self.assertIn("1943-04", output)
> {code}
> With the following message:
> {noformat}
> AssertionError: '1943-04' not found in "\r\n id |
> value\r\n+---\r\n 1 |
> 2143-04-19 08:21:01.-0300\r\n 2 | datetime.datetime(1943, 4, 19, 11,
> 21, 1)\r\n\r\n(2 rows)\r\nFailed to format value datetime.datetime(1943, 4,
> 19, 11, 21, 1) : (22, 'Invalid argument')\r\n"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10000) Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908108#comment-14908108
]
Aaron Ploetz edited comment on CASSANDRA-1 at 9/25/15 2:50 PM:
---
I have a feeling that this ticket may have a bug that is causing a bug with how
timestamps are displayed in 'nix based systems. I noticed yesterday that my
2.2.1 instance was showing times in UTC. I was too busy to think much of it at
the time. But then this morning I ran across this question on StackOverflow
(http://stackoverflow.com/questions/32778433/cassandra-cqlsh-not-displaying-correct-timezone)
which basically confirms that this is happening in 2.2.1 and 2.1.9.
Note, times appear to be going in correctly, but are always displayed in UTC.
{{aploetz@cqlsh:stackoverflow> INSERT INTO timestamptest
(userid,activetime,value) VALUES ('b','2015-09-25 09:40:11-0500','value1');}}
{{aploetz@cqlsh:stackoverflow> SELECT * FROM stackoverflow.timestamptest ;}}
{{userid | activetime | value}}
{{+--+}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{(4 rows)}}
was (Author: aploetz):
I have a feeling that this ticket may have a bug that is causing a bug with how
timestamps are displayed in 'nix based systems. I noticed yesterday that my
2.2.1 instance was showing times in UTC. I was too busy to think much of it at
the time. But then this morning I ran across this question on StackOverflow
(http://stackoverflow.com/questions/32778433/cassandra-cqlsh-not-displaying-correct-timezone)
which basically confirms that this is happening in 2.2.1 and 1.2.9.
Note, times appear to be going in correctly, but are always displayed in UTC.
{{aploetz@cqlsh:stackoverflow> INSERT INTO timestamptest
(userid,activetime,value) VALUES ('b','2015-09-25 09:40:11-0500','value1');}}
{{aploetz@cqlsh:stackoverflow> SELECT * FROM stackoverflow.timestamptest ;}}
{{userid | activetime | value}}
{{+--+}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{(4 rows)}}
> Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
>
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
> Issue Type: Bug
> Environment: windows
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh, windows
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
>
> The following test fails on Windows:
> {code:none}
> def test_past_and_future_dates(self):
> self.cluster.populate(1)
> self.cluster.start(wait_for_binary_proto=True)
> node1, = self.cluster.nodelist()
> node1.run_cqlsh(cmds="""
> CREATE KEYSPACE simple WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> use simple;
> create TABLE simpledate (id int PRIMARY KEY , value timestamp ) ;
> insert into simpledate (id, value) VALUES (1,
> '2143-04-19T11:21:01+');
> insert into simpledate (id, value) VALUES (2,
> '1943-04-19T11:21:01+')""")
> session = self.patient_cql_connection(node1)
> rows = session.execute("select id, value from simple.simpledate")
> output, err = self.run_cqlsh(node1, 'use simple; SELECT * FROM
> simpledate')
> self.assertIn("2143-04", output)
> self.assertIn("1943-04", output)
> {code}
> With the following message:
> {noformat}
> AssertionError: '1943-04' not found in "\r\n id |
> value\r\n+---\r\n 1 |
> 2143-04-19 08:21:01.-0300\r\n 2 | datetime.datetime(1943, 4, 19, 11,
> 21, 1)\r\n\r\n(2 rows)\r\nFailed to format value datetime.datetime(1943, 4,
> 19, 11, 21, 1) : (22, 'Invalid argument')\r\n"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10000) Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908108#comment-14908108
]
Aaron Ploetz edited comment on CASSANDRA-1 at 9/25/15 3:05 PM:
---
I have a feeling that this ticket may be causing a bug with how timestamps are
displayed in 'nix based systems. I noticed yesterday that my 2.2.1 instance
was showing times in UTC. I was too busy to think much of it at the time. But
then this morning I ran across this question on StackOverflow
(http://stackoverflow.com/questions/32778433/cassandra-cqlsh-not-displaying-correct-timezone)
which basically confirms that this is happening in 2.2.1 and 2.1.9.
Note, times appear to be going in correctly, but are always displayed in UTC.
{{aploetz@cqlsh:stackoverflow> INSERT INTO timestamptest
(userid,activetime,value) VALUES ('b','2015-09-25 09:40:11-0500','value1');}}
{{aploetz@cqlsh:stackoverflow> SELECT * FROM stackoverflow.timestamptest ;}}
{{userid | activetime | value}}
{{+--+}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{(4 rows)}}
was (Author: aploetz):
I have a feeling that this ticket may have a bug that is causing a bug with how
timestamps are displayed in 'nix based systems. I noticed yesterday that my
2.2.1 instance was showing times in UTC. I was too busy to think much of it at
the time. But then this morning I ran across this question on StackOverflow
(http://stackoverflow.com/questions/32778433/cassandra-cqlsh-not-displaying-correct-timezone)
which basically confirms that this is happening in 2.2.1 and 2.1.9.
Note, times appear to be going in correctly, but are always displayed in UTC.
{{aploetz@cqlsh:stackoverflow> INSERT INTO timestamptest
(userid,activetime,value) VALUES ('b','2015-09-25 09:40:11-0500','value1');}}
{{aploetz@cqlsh:stackoverflow> SELECT * FROM stackoverflow.timestamptest ;}}
{{userid | activetime | value}}
{{+--+}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{a | 2015-09-25 11:30:17+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{b | 2015-09-25 14:40:11+ | value1}}
{{(4 rows)}}
> Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
>
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
> Issue Type: Bug
> Environment: windows
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh, windows
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
>
> The following test fails on Windows:
> {code:none}
> def test_past_and_future_dates(self):
> self.cluster.populate(1)
> self.cluster.start(wait_for_binary_proto=True)
> node1, = self.cluster.nodelist()
> node1.run_cqlsh(cmds="""
> CREATE KEYSPACE simple WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> use simple;
> create TABLE simpledate (id int PRIMARY KEY , value timestamp ) ;
> insert into simpledate (id, value) VALUES (1,
> '2143-04-19T11:21:01+');
> insert into simpledate (id, value) VALUES (2,
> '1943-04-19T11:21:01+')""")
> session = self.patient_cql_connection(node1)
> rows = session.execute("select id, value from simple.simpledate")
> output, err = self.run_cqlsh(node1, 'use simple; SELECT * FROM
> simpledate')
> self.assertIn("2143-04", output)
> self.assertIn("1943-04", output)
> {code}
> With the following message:
> {noformat}
> AssertionError: '1943-04' not found in "\r\n id |
> value\r\n+---\r\n 1 |
> 2143-04-19 08:21:01.-0300\r\n 2 | datetime.datetime(1943, 4, 19, 11,
> 21, 1)\r\n\r\n(2 rows)\r\nFailed to format value datetime.datetime(1943, 4,
> 19, 11, 21, 1) : (22, 'Invalid argument')\r\n"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8821) Errors in JVM_OPTS and cassandra_parms environment vars
[ https://issues.apache.org/jira/browse/CASSANDRA-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-8821: -- Reviewer: Eric Evans (was: Brandon Williams) > Errors in JVM_OPTS and cassandra_parms environment vars > --- > > Key: CASSANDRA-8821 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8821 > Project: Cassandra > Issue Type: Bug > Environment: Ubuntu 14.04 LTS amd64 >Reporter: Terry Moschou >Assignee: Michael Shuler >Priority: Minor > Fix For: 2.1.x, 2.2.x > > Attachments: 8821_2.0.txt, 8821_2.1.txt > > > Repos: > deb http://www.apache.org/dist/cassandra/debian 21x main > deb-src http://www.apache.org/dist/cassandra/debian 21x main > The cassandra init script > /etc/init.d/cassandra > is sourcing the environment file > /etc/cassandra/cassandra-env.sh > twice. Once directly from the init script, and again inside > /usr/sbin/cassandra > The result is arguments in JVM_OPTS are duplicated. > Further the JVM opt > -XX:CMSWaitDuration=1 > is defined twice if jvm >= 1.7.60. > Also, for the environment variable CASSANDRA_CONF used in this context > -XX:CompileCommandFile=$CASSANDRA_CONF/hotspot_compiler" > is undefined when > /etc/cassandra/cassandra-env.sh > is sourced from the init script. > Lastly the variable cassandra_storagedir is undefined in > /usr/sbin/cassandra > when used in this context > -Dcassandra.storagedir=$cassandra_storagedir -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8821) Errors in JVM_OPTS and cassandra_parms environment vars
[
https://issues.apache.org/jira/browse/CASSANDRA-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908248#comment-14908248
]
Eric Evans commented on CASSANDRA-8821:
---
[~mshuler]:
{{debian/init}}:
This is all a throwback to when the init script used {{jsvc}}, and there is a
bit more of it that can be excised; You can also remove the bits that source
{{cassandra-env.sh}}, and the zero-length test of {{$JVM_OPTS}}. See:
CASSANDRA-10251.
{{conf/cassandra-env.\{sh,ps1\}}}:
I don't think we should be promoting the use of {{JVM_EXTRA_OPTS}} from within
{{cassandra-env.*}}. By which I mean, if you are editing one of those files
then it's probably sanest to just edit {{JVM_OPTS}}, and leave
{{JVM_EXTRA_OPTS}} as a way of injecting options from elsewhere. I suggest
that we remove the commented out assignment, adjust the documenting comments
accordingly, or remove them entirely. You can put a commented out
{{JVM_EXTRA_OPTS}} assignment, and corresponding documentation in
{{debian/default}}.
Does this sounds reasonable?
> Errors in JVM_OPTS and cassandra_parms environment vars
> ---
>
> Key: CASSANDRA-8821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8821
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 14.04 LTS amd64
>Reporter: Terry Moschou
>Assignee: Michael Shuler
>Priority: Minor
> Fix For: 2.1.x, 2.2.x
>
> Attachments: 8821_2.0.txt, 8821_2.1.txt
>
>
> Repos:
> deb http://www.apache.org/dist/cassandra/debian 21x main
> deb-src http://www.apache.org/dist/cassandra/debian 21x main
> The cassandra init script
> /etc/init.d/cassandra
> is sourcing the environment file
> /etc/cassandra/cassandra-env.sh
> twice. Once directly from the init script, and again inside
> /usr/sbin/cassandra
> The result is arguments in JVM_OPTS are duplicated.
> Further the JVM opt
> -XX:CMSWaitDuration=1
> is defined twice if jvm >= 1.7.60.
> Also, for the environment variable CASSANDRA_CONF used in this context
> -XX:CompileCommandFile=$CASSANDRA_CONF/hotspot_compiler"
> is undefined when
> /etc/cassandra/cassandra-env.sh
> is sourced from the init script.
> Lastly the variable cassandra_storagedir is undefined in
> /usr/sbin/cassandra
> when used in this context
> -Dcassandra.storagedir=$cassandra_storagedir
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10397) CQLSH not displaying correct timezone
[ https://issues.apache.org/jira/browse/CASSANDRA-10397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908267#comment-14908267 ] Stefania commented on CASSANDRA-10397: -- This may be the same problem as CASSANDRA-10313. > CQLSH not displaying correct timezone > - > > Key: CASSANDRA-10397 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10397 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Ubuntu 14.04 LTS >Reporter: Suleman Rai >Priority: Blocker > Fix For: 2.1.x, 2.2.x > > > CQLSH is not adding the timezone offset to the timestamp after it has been > inserted into a table. > create table test(id int PRIMARY KEY, time timestamp); > INSERT INTO test(id,time) values (1,dateof(now())); > select *from test; > id | time > +- > 1 | 2015-09-25 13:00:32 > It is just displaying the default UTC timestamp without adding the timezone > offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is > +0800. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10000) Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908294#comment-14908294
]
Paulo Motta commented on CASSANDRA-1:
-
[~aploetz] this is not a bug, since it's expected behavior. Unfortunately
python std lib does not offer decent multi-platform date localization support
so we opted to display dates in UTC for simplicity (and not adding new
dependencies). If you would like dates to be displayed in local time zone,
please file an improvement ticket with that request. Thanks!
> Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
>
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
> Issue Type: Bug
> Environment: windows
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh, windows
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
>
> The following test fails on Windows:
> {code:none}
> def test_past_and_future_dates(self):
> self.cluster.populate(1)
> self.cluster.start(wait_for_binary_proto=True)
> node1, = self.cluster.nodelist()
> node1.run_cqlsh(cmds="""
> CREATE KEYSPACE simple WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> use simple;
> create TABLE simpledate (id int PRIMARY KEY , value timestamp ) ;
> insert into simpledate (id, value) VALUES (1,
> '2143-04-19T11:21:01+');
> insert into simpledate (id, value) VALUES (2,
> '1943-04-19T11:21:01+')""")
> session = self.patient_cql_connection(node1)
> rows = session.execute("select id, value from simple.simpledate")
> output, err = self.run_cqlsh(node1, 'use simple; SELECT * FROM
> simpledate')
> self.assertIn("2143-04", output)
> self.assertIn("1943-04", output)
> {code}
> With the following message:
> {noformat}
> AssertionError: '1943-04' not found in "\r\n id |
> value\r\n+---\r\n 1 |
> 2143-04-19 08:21:01.-0300\r\n 2 | datetime.datetime(1943, 4, 19, 11,
> 21, 1)\r\n\r\n(2 rows)\r\nFailed to format value datetime.datetime(1943, 4,
> 19, 11, 21, 1) : (22, 'Invalid argument')\r\n"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10398) Allow dropping COMPACT STORAGE flag
Aleksey Yeschenko created CASSANDRA-10398:
-
Summary: Allow dropping COMPACT STORAGE flag
Key: CASSANDRA-10398
URL: https://issues.apache.org/jira/browse/CASSANDRA-10398
Project: Cassandra
Issue Type: Improvement
Reporter: Aleksey Yeschenko
Fix For: 3.x
To provide a migration path from Thrift to CQL for mixed static/dynamic column
families, we need to be able to switch off the {{COMPACT STORAGE}} flag.
Otherwise CQL would only recognize the static columns.
This should be relatively easy after CASSANDRA-8099, but needs extensive
testing first.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4967) config options have different bounds when set via different methods
[
https://issues.apache.org/jira/browse/CASSANDRA-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908373#comment-14908373
]
John Sumsion commented on CASSANDRA-4967:
-
I got part way through applying the validation checks before I left. Hopefully
I can wrap it up. I didn't get any feedback on the approach, so I'm just
continuing.
This branch is rebased on top of the latest trunk as of now:
- https://github.com/jdsumsion/cassandra/tree/4967-config-validation
> config options have different bounds when set via different methods
> ---
>
> Key: CASSANDRA-4967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4967
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.2.0 beta 2
>Reporter: Robert Coli
>Priority: Minor
> Labels: lhf
>
> (similar to some of the work done in
> https://issues.apache.org/jira/browse/CASSANDRA-4479
> )
> If one sets a value in cassandra.yaml, that value might be subject to bounds
> checking there. However if one sets that same value via JMX, it doesn't get
> set via a bounds-checking code path.
> "./src/java/org/apache/cassandra/config/DatabaseDescriptor.java" (JMX set)
> {noformat}
> public static void setPhiConvictThreshold(double phiConvictThreshold)
> {
> conf.phi_convict_threshold = phiConvictThreshold;
> }
> {noformat}
> Versus..
> ./src/java/org/apache/cassandra/config/DatabaseDescriptor.java
> (cassandra.yaml)
> {noformat}
> static void loadYaml()
> ...
> /* phi convict threshold for FailureDetector */
> if (conf.phi_convict_threshold < 5 || conf.phi_convict_threshold
> > 16)
> {
> throw new ConfigurationException("phi_convict_threshold must
> be between 5 and 16");
> }
> {noformat}
> This seems to create a confusing situation where the range of potential
> values for a given configuration option is different when set by different
> methods.
> It's difficult to imagine a circumstance where you want bounds checking to
> keep your node from starting if you set that value in cassandra.yaml, but
> also want to allow circumvention of that bounds checking if you set via JMX.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10000) Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908385#comment-14908385
]
Aaron Ploetz commented on CASSANDRA-1:
--
"this is not a bug, since it's expected behavior."
I'm going to have to disagree with you there. I've used cqlsh for 3 years, and
the last thing I "expected" to see in regards to timestamp querying, is having
my timestamps forced into UTC. That being said, I do understand that adding
Windows platform support will bring its own set of "growing pains" that we'll
all have to learn to deal with.
I will go ahead and open up another ticket, and probably code a patch for it
myself.
Thank you for explaining.
> Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
>
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
> Issue Type: Bug
> Environment: windows
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh, windows
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
>
> The following test fails on Windows:
> {code:none}
> def test_past_and_future_dates(self):
> self.cluster.populate(1)
> self.cluster.start(wait_for_binary_proto=True)
> node1, = self.cluster.nodelist()
> node1.run_cqlsh(cmds="""
> CREATE KEYSPACE simple WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> use simple;
> create TABLE simpledate (id int PRIMARY KEY , value timestamp ) ;
> insert into simpledate (id, value) VALUES (1,
> '2143-04-19T11:21:01+');
> insert into simpledate (id, value) VALUES (2,
> '1943-04-19T11:21:01+')""")
> session = self.patient_cql_connection(node1)
> rows = session.execute("select id, value from simple.simpledate")
> output, err = self.run_cqlsh(node1, 'use simple; SELECT * FROM
> simpledate')
> self.assertIn("2143-04", output)
> self.assertIn("1943-04", output)
> {code}
> With the following message:
> {noformat}
> AssertionError: '1943-04' not found in "\r\n id |
> value\r\n+---\r\n 1 |
> 2143-04-19 08:21:01.-0300\r\n 2 | datetime.datetime(1943, 4, 19, 11,
> 21, 1)\r\n\r\n(2 rows)\r\nFailed to format value datetime.datetime(1943, 4,
> 19, 11, 21, 1) : (22, 'Invalid argument')\r\n"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10397) CQLSH not displaying correct timezone
[ https://issues.apache.org/jira/browse/CASSANDRA-10397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-10397: Priority: Major (was: Blocker) > CQLSH not displaying correct timezone > - > > Key: CASSANDRA-10397 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10397 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Ubuntu 14.04 LTS >Reporter: Suleman Rai > Labels: cqlsh > Fix For: 2.1.x, 2.2.x > > > CQLSH is not adding the timezone offset to the timestamp after it has been > inserted into a table. > create table test(id int PRIMARY KEY, time timestamp); > INSERT INTO test(id,time) values (1,dateof(now())); > select *from test; > id | time > +- > 1 | 2015-09-25 13:00:32 > It is just displaying the default UTC timestamp without adding the timezone > offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is > +0800. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10397) CQLSH not displaying correct timezone
[ https://issues.apache.org/jira/browse/CASSANDRA-10397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908451#comment-14908451 ] Philip Thompson commented on CASSANDRA-10397: - Are these related to [~pauloricardomg]'s comments in CASSANDRA-1? > CQLSH not displaying correct timezone > - > > Key: CASSANDRA-10397 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10397 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Ubuntu 14.04 LTS >Reporter: Suleman Rai >Priority: Blocker > Labels: cqlsh > Fix For: 2.1.x, 2.2.x > > > CQLSH is not adding the timezone offset to the timestamp after it has been > inserted into a table. > create table test(id int PRIMARY KEY, time timestamp); > INSERT INTO test(id,time) values (1,dateof(now())); > select *from test; > id | time > +- > 1 | 2015-09-25 13:00:32 > It is just displaying the default UTC timestamp without adding the timezone > offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is > +0800. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10397) CQLSH not displaying correct timezone
[ https://issues.apache.org/jira/browse/CASSANDRA-10397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-10397: Labels: cqlsh (was: ) > CQLSH not displaying correct timezone > - > > Key: CASSANDRA-10397 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10397 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Ubuntu 14.04 LTS >Reporter: Suleman Rai >Priority: Blocker > Labels: cqlsh > Fix For: 2.1.x, 2.2.x > > > CQLSH is not adding the timezone offset to the timestamp after it has been > inserted into a table. > create table test(id int PRIMARY KEY, time timestamp); > INSERT INTO test(id,time) values (1,dateof(now())); > select *from test; > id | time > +- > 1 | 2015-09-25 13:00:32 > It is just displaying the default UTC timestamp without adding the timezone > offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is > +0800. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10381) NullPointerException in cqlsh paging through CF with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908467#comment-14908467
]
Michael Keeney commented on CASSANDRA-10381:
Was unable to reproduce issue in lab, consulting with Benjamin
> NullPointerException in cqlsh paging through CF with static columns
> ---
>
> Key: CASSANDRA-10381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10381
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Michael Keeney
>Assignee: Benjamin Lerer
> Labels: cqlsh, nullpointerexception, range
> Fix For: 2.1.x
>
>
> When running select count( * ) from cqlsh with limit, the following NPE
> occurs:
> select count( * ) from tbl1 limit 5 ;
> {code}
> ERROR [SharedPool-Worker-4] 2015-09-16 14:49:43,480 QueryMessage.java:132 -
> Unexpected error during query
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.pager.RangeSliceQueryPager.containsPreviousLast(RangeSliceQueryPager.java:99)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:119)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.pageCountQuery(SelectStatement.java:286)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:230)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$StatementExecution.execute(DseQueryHandler.java:291)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$Operation.executeWithTiming(DseQueryHandler.java:223)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$Operation.executeWithAuditLogging(DseQueryHandler.java:259)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler.process(DseQueryHandler.java:94)
> ~[dse-4.7.2.jar:4.7.2]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> 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:471)
> [na:1.7.0_75]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_75]
> {code}
> Table definition looks something like:
> {code}
> CREATE TABLE tbl1 (
> field1 bigint,
> field2 int,
> field3 timestamp,
> field4 map,
> field5 text static,
> field6 text static,
> field7 text static
> PRIMARY KEY (field1, field2, field3)
> ) WITH CLUSTERING ORDER BY (field2 ASC, field3 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>...
> {code}
> Following appears in debug log leading up to the error:
> {code}
> DEBUG [SharedPool-Worker-1] 2015-09-17 15:32:06,484
> AbstractQueryPager.java:95 - Fetched 101 live rows
> DEBUG [SharedPoo
[jira] [Commented] (CASSANDRA-10397) CQLSH not displaying correct timezone
[ https://issues.apache.org/jira/browse/CASSANDRA-10397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908488#comment-14908488 ] Paulo Motta commented on CASSANDRA-10397: - we decided to change the default behavior of displaying dates on the local timezone, since that was not working on Windows due to python limitations (an additional pytz library was needed to provide that functionality). we need to provide an option for users to change the default timezone from UTC to any other timezone, provided they have the pytz (or some similar library) installed. Have you created a ticket for that [~aploetz]? If not, we can use this ticket. > CQLSH not displaying correct timezone > - > > Key: CASSANDRA-10397 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10397 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Ubuntu 14.04 LTS >Reporter: Suleman Rai > Labels: cqlsh > Fix For: 2.1.x, 2.2.x > > > CQLSH is not adding the timezone offset to the timestamp after it has been > inserted into a table. > create table test(id int PRIMARY KEY, time timestamp); > INSERT INTO test(id,time) values (1,dateof(now())); > select *from test; > id | time > +- > 1 | 2015-09-25 13:00:32 > It is just displaying the default UTC timestamp without adding the timezone > offset. It should be 2015-09-25 21:00:32 in my case as my timezone offset is > +0800. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10000) Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908493#comment-14908493
]
Paulo Motta commented on CASSANDRA-1:
-
bq. I will go ahead and open up another ticket, and probably code a patch for
it myself.
sounds good, I'm happy to review it. you can reuse CASSANDRA-10397 if you
haven't created a new ticket yet, otherwise I will close that as a duplicate of
the new ticket.
> Dates before 1970-01-01 are not formatted correctly on cqlsh\Windows
>
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
> Issue Type: Bug
> Environment: windows
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh, windows
> Fix For: 2.1.9, 2.2.1, 3.0 beta 1
>
>
> The following test fails on Windows:
> {code:none}
> def test_past_and_future_dates(self):
> self.cluster.populate(1)
> self.cluster.start(wait_for_binary_proto=True)
> node1, = self.cluster.nodelist()
> node1.run_cqlsh(cmds="""
> CREATE KEYSPACE simple WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> use simple;
> create TABLE simpledate (id int PRIMARY KEY , value timestamp ) ;
> insert into simpledate (id, value) VALUES (1,
> '2143-04-19T11:21:01+');
> insert into simpledate (id, value) VALUES (2,
> '1943-04-19T11:21:01+')""")
> session = self.patient_cql_connection(node1)
> rows = session.execute("select id, value from simple.simpledate")
> output, err = self.run_cqlsh(node1, 'use simple; SELECT * FROM
> simpledate')
> self.assertIn("2143-04", output)
> self.assertIn("1943-04", output)
> {code}
> With the following message:
> {noformat}
> AssertionError: '1943-04' not found in "\r\n id |
> value\r\n+---\r\n 1 |
> 2143-04-19 08:21:01.-0300\r\n 2 | datetime.datetime(1943, 4, 19, 11,
> 21, 1)\r\n\r\n(2 rows)\r\nFailed to format value datetime.datetime(1943, 4,
> 19, 11, 21, 1) : (22, 'Invalid argument')\r\n"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10399) Create default Stress tables without compact storage
Sebastian Estevez created CASSANDRA-10399:
-
Summary: Create default Stress tables without compact storage
Key: CASSANDRA-10399
URL: https://issues.apache.org/jira/browse/CASSANDRA-10399
Project: Cassandra
Issue Type: Bug
Reporter: Sebastian Estevez
Priority: Minor
~$ cassandra-stress write
{code}
cqlsh> desc TABLE keyspace1.standard1
CREATE TABLE keyspace1.standard1 (
key blob PRIMARY KEY,
"C0" blob,
"C1" blob,
"C2" blob,
"C3" blob,
"C4" blob
) WITH COMPACT STORAGE
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
AND compression = {}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = 'NONE';
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10323) Add more MaterializedView metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908670#comment-14908670
]
Robert Coli commented on CASSANDRA-10323:
-
{quote}Robert Coli raised the good point that a very helpful metric for
operators would be to track MV lag, because mutations are applied to the view
from the base table asynchronously.{quote}
Probably this ends up being expressed as "queue depth" as opposed to actual
temporal lag, but "queue depth" provides useful visibility into "lag."
> Add more MaterializedView metrics
> -
>
> Key: CASSANDRA-10323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10323
> Project: Cassandra
> Issue Type: Improvement
>Reporter: T Jake Luciani
> Labels: lhf
> Fix For: 3.0.0 rc2
>
> Attachments: trunk-10323.txt
>
>
> We need to add more metrics to help understand where time is spent in
> materialized view writes. We currently track the ratio of async base -> view
> mutations that fail.
> We should also add
> * The amount of time spent waiting for the partition lock (contention)
> * The amount of time spent reading data
> Any others?
> [~carlyeks] [~jkni]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10400) Hadoop CF splits should be more polite to custom orderered partitioners
Chris Lockfort created CASSANDRA-10400: -- Summary: Hadoop CF splits should be more polite to custom orderered partitioners Key: CASSANDRA-10400 URL: https://issues.apache.org/jira/browse/CASSANDRA-10400 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Chris Lockfort Priority: Minor Fix For: 2.2.x Looks like Philip Thompson just didn't know about preservesOrder() on IPartitioner when he wrote this, no big deal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10400) Hadoop CF splits should be more polite to custom orderered partitioners
[ https://issues.apache.org/jira/browse/CASSANDRA-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lockfort updated CASSANDRA-10400: --- Attachment: cassandra-2.2-10400.patch > Hadoop CF splits should be more polite to custom orderered partitioners > --- > > Key: CASSANDRA-10400 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10400 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Chris Lockfort >Priority: Minor > Fix For: 2.2.x > > Attachments: cassandra-2.2-10400.patch > > > Looks like Philip Thompson just didn't know about preservesOrder() on > IPartitioner when he wrote this, no big deal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10390) inconsistent quoted identifier handling in UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-10390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908724#comment-14908724
]
Sam Tunnicliffe commented on CASSANDRA-10390:
-
This is a python driver bug, types like the one described are legal & can in
fact be accessed using the java driver. I've opened
[https://datastax-oss.atlassian.net/browse/PYTHON-413|PYTHON-413] and we'll
need to update the bundled driver once that's resolved.
> inconsistent quoted identifier handling in UDTs
> ---
>
> Key: CASSANDRA-10390
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10390
> Project: Cassandra
> Issue Type: Bug
> Environment: 2.2.1
>Reporter: Jonathan Halliday
>Assignee: Sam Tunnicliffe
> Fix For: 2.2.x
>
>
> > create keyspace test with replication = {'class': 'SimpleStrategy',
> > 'replication_factor': 1 } ;
> > create type if not exists mytype ("my.field" text);
> > desc keyspace; -- observe that mytype is listed
> > create table mytable (pk int primary key, myfield frozen);
> > desc keyspace; -- observe that mytype is listed, but mytable is not.
> > select * from mytable;
> ValueError: Type names and field names can only contain alphanumeric
> characters and underscores: 'my.field'
> create table myothertable (pk int primary key, "my.field" text);
> select * from myothertable; -- valid
> huh? It's valid to create a field of a table, or a field of a type, with a
> quoted name containing non-alpha chars, but it's not valid to use a such a
> type in a table? I can just about live with that though it seems
> unnecessarily restrictive, but allowing creation of such a table and then
> making it invisible/unusable definitely seems wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10390) inconsistent quoted identifier handling in UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-10390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908724#comment-14908724
]
Sam Tunnicliffe edited comment on CASSANDRA-10390 at 9/25/15 9:48 PM:
--
This is a python driver bug, types like the one described are legal & can in
fact be accessed using the java driver. I've opened
[PYTHON-413|https://datastax-oss.atlassian.net/browse/PYTHON-413] and we'll
need to update the bundled driver once that's resolved.
was (Author: beobal):
This is a python driver bug, types like the one described are legal & can in
fact be accessed using the java driver. I've opened
[https://datastax-oss.atlassian.net/browse/PYTHON-413|PYTHON-413] and we'll
need to update the bundled driver once that's resolved.
> inconsistent quoted identifier handling in UDTs
> ---
>
> Key: CASSANDRA-10390
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10390
> Project: Cassandra
> Issue Type: Bug
> Environment: 2.2.1
>Reporter: Jonathan Halliday
>Assignee: Sam Tunnicliffe
> Fix For: 2.2.x
>
>
> > create keyspace test with replication = {'class': 'SimpleStrategy',
> > 'replication_factor': 1 } ;
> > create type if not exists mytype ("my.field" text);
> > desc keyspace; -- observe that mytype is listed
> > create table mytable (pk int primary key, myfield frozen);
> > desc keyspace; -- observe that mytype is listed, but mytable is not.
> > select * from mytable;
> ValueError: Type names and field names can only contain alphanumeric
> characters and underscores: 'my.field'
> create table myothertable (pk int primary key, "my.field" text);
> select * from myothertable; -- valid
> huh? It's valid to create a field of a table, or a field of a type, with a
> quoted name containing non-alpha chars, but it's not valid to use a such a
> type in a table? I can just about live with that though it seems
> unnecessarily restrictive, but allowing creation of such a table and then
> making it invisible/unusable definitely seems wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10323) Add more MaterializedView metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908742#comment-14908742 ] Chris Lohfink commented on CASSANDRA-10323: --- Is taking the attempted replicas - successful replicas work for that? Can make a gauge to make it easier > Add more MaterializedView metrics > - > > Key: CASSANDRA-10323 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10323 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani > Labels: lhf > Fix For: 3.0.0 rc2 > > Attachments: trunk-10323.txt > > > We need to add more metrics to help understand where time is spent in > materialized view writes. We currently track the ratio of async base -> view > mutations that fail. > We should also add > * The amount of time spent waiting for the partition lock (contention) > * The amount of time spent reading data > Any others? > [~carlyeks] [~jkni] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9304) COPY TO improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908749#comment-14908749 ] Stefania commented on CASSANDRA-9304: - Resuming progress with this since the patch is almost complete and to avoid unnecessary conflicts I prefer to base CASSANDRA-9302 and CASSANDRA-9303 on this patch. Could we assign a new reviewer please? > COPY TO improvements > > > Key: CASSANDRA-9304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9304 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Stefania >Priority: Minor > Labels: cqlsh > Fix For: 2.1.x > > > COPY FROM has gotten a lot of love. COPY TO not so much. One obvious > improvement could be to parallelize reading and writing (write one page of > data while fetching the next). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out
[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908762#comment-14908762
]
Stefania commented on CASSANDRA-7392:
-
[~aweisberg]: as discussed offline, I moved the time-out checks to the working
threads therefore eliminating the need for any {{AtomicReference}} or
contention. I've added a bounded queue of operations for passing timed-out
operations to the monitoring thread, whose only job is now to log timed out
operations periodically. We check the queue every 500 milliseconds and transfer
the failed operations to a hash map indexed by name, just in case there are
multiple queries for the exact same SQL during the reporting time (5 seconds).
This could perhaps be skipped. I've also improved the overriding of the
properties from unit tests and added an approximate time server to avoid
calling {{System.currentTimeMillis()}} or {{System.nanoTime()}} every time we
check if an operation has timed out in the working threads.
This is ready for another round of review.
> Abort in-progress queries that time out
> ---
>
> Key: CASSANDRA-7392
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7392
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Jonathan Ellis
>Assignee: Stefania
>Priority: Critical
> Fix For: 3.x
>
>
> Currently we drop queries that time out before we get to them (because node
> is overloaded) but not queries that time out while being processed.
> (Particularly common for index queries on data that shouldn't be indexed.)
> Adding the latter and logging when we have to interrupt one gets us a poor
> man's "slow query log" for free.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10323) Add more MaterializedView metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908782#comment-14908782
]
Robert Coli commented on CASSANDRA-10323:
-
{quote}Is taking the attempted replicas - successful replicas work for that?
Can make a gauge to make it easier{quote}
That's a measure of how many retries you've ever had, not a measure of how many
retries are in the queue now, isn't it? To me the latter is more valuable than
the former.
> Add more MaterializedView metrics
> -
>
> Key: CASSANDRA-10323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10323
> Project: Cassandra
> Issue Type: Improvement
>Reporter: T Jake Luciani
> Labels: lhf
> Fix For: 3.0.0 rc2
>
> Attachments: trunk-10323.txt
>
>
> We need to add more metrics to help understand where time is spent in
> materialized view writes. We currently track the ratio of async base -> view
> mutations that fail.
> We should also add
> * The amount of time spent waiting for the partition lock (contention)
> * The amount of time spent reading data
> Any others?
> [~carlyeks] [~jkni]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-5780) nodetool status and ring report incorrect/stale information after decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-5780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908794#comment-14908794
]
Robert Coli commented on CASSANDRA-5780:
{quote}Also, if the data directory is not altered in anyway, I wonder if there
is a concern there, too? Hope that helps.{quote}
There are some cases to be concerned about, yes. As a general statement, "old
sstables" coming back to life can be very bad or fatal for consistency.
[~jdsumsion] can you think of a rationale for not also truncating the data
columnfamilies? The data will be retained in a snapshot unless the operator has
specifically requested not snapshotting on truncate...
> nodetool status and ring report incorrect/stale information after decommission
> --
>
> Key: CASSANDRA-5780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5780
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Peter Haggerty
>Priority: Trivial
> Labels: lhf, ponies, qa-resolved
> Fix For: 2.1.x
>
>
> Cassandra 1.2.6 ring of 12 instances, each with 256 tokens.
> Decommission 3 of the 12 nodes, one after another resulting a 9 instance ring.
> The 9 instances of cassandra that are in the ring all correctly report
> nodetool status information for the ring and have the same data.
> After the first node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> After the second node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> "nodetool status" on "decommissioned-2nd" reports 10 nodes
> After the second node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> "nodetool status" on "decommissioned-2nd" reports 10 nodes
> "nodetool status" on "decommissioned-3rd" reports 9 nodes
> The storage load information is similarly stale on the various decommissioned
> nodes. The nodetool status and ring commands continue to return information
> as if they were part of a cluster and they appear to return the last
> information that they saw.
> In contrast the nodetool info command fails with an exception, which isn't
> ideal but at least indicates that there was a failure rather than returning
> stale information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10323) Add more MaterializedView metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908951#comment-14908951 ] Chris Lohfink commented on CASSANDRA-10323: --- It's measure of how many mutations are outstanding to replicas of the MVs partitions after/during the base replicas mutation > Add more MaterializedView metrics > - > > Key: CASSANDRA-10323 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10323 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani > Labels: lhf > Fix For: 3.0.0 rc2 > > Attachments: trunk-10323.txt > > > We need to add more metrics to help understand where time is spent in > materialized view writes. We currently track the ratio of async base -> view > mutations that fail. > We should also add > * The amount of time spent waiting for the partition lock (contention) > * The amount of time spent reading data > Any others? > [~carlyeks] [~jkni] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10392) Allow Cassandra to trace to custom tracing implementations
[ https://issues.apache.org/jira/browse/CASSANDRA-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-10392: Description: It can be possible to use an external tracing solution in Cassandra by abstracting out the writing of tracing to system_traces tables in the tracing package to separate implementation classes and leaving abstract classes in place that define the interface and behaviour otherwise of C* tracing. Then via a system property "cassandra.custom_tracing_class" the Tracing class implementation could be swapped out with something third party. An example of this is adding Zipkin tracing into Cassandra in the Summit presentation. In addition this patch passes the custom payload through into the tracing session allowing a third party tracing solution like Zipkin to do full-stack tracing from clients through and into Cassandra. There's still a few todos and fixmes in the initial patch but i'm submitting early to get feedback. For example i haven't included in this patch the ability to prevent c*'s default tracing from happening (which would completely offload the current tracing overhead onto separate infrastructure) and am open to including it in this patch or leaving it to a follow-up issue. was: It can be possible to use an external tracing solution in Cassandra by abstracting out the writing of tracing to system_traces tables in the tracing package to separate implementation classes and leaving abstract classes in place that define the interface and behaviour otherwise of C* tracing. Then via a system property "cassandra.custom_tracing_class" the Tracing class implementation could be swapped out with something third party. An example of this is adding Zipkin tracing into Cassandra in the Summit presentation. In addition this patch passes the custom payload through into the tracing session allowing a third party tracing solution like Zipkin to do full-stack tracing from clients through and into Cassandra. There's still a few todos and fixmes in the initial patch but i'm submitting early to get feedback. > Allow Cassandra to trace to custom tracing implementations > --- > > Key: CASSANDRA-10392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10392 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: mck >Assignee: mck > Attachments: 10392-trunk.txt > > > It can be possible to use an external tracing solution in Cassandra by > abstracting out the writing of tracing to system_traces tables in the tracing > package to separate implementation classes and leaving abstract classes in > place that define the interface and behaviour otherwise of C* tracing. > Then via a system property "cassandra.custom_tracing_class" the Tracing class > implementation could be swapped out with something third party. > An example of this is adding Zipkin tracing into Cassandra in the Summit > presentation. > In addition this patch passes the custom payload through into the tracing > session allowing a third party tracing solution like Zipkin to do full-stack > tracing from clients through and into Cassandra. > There's still a few todos and fixmes in the initial patch but i'm submitting > early to get feedback. For example i haven't included in this patch the > ability to prevent c*'s default tracing from happening (which would > completely offload the current tracing overhead onto separate infrastructure) > and am open to including it in this patch or leaving it to a follow-up issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10256) document commitlog segment size's relationship to max write size
[ https://issues.apache.org/jira/browse/CASSANDRA-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tushar Agrawal updated CASSANDRA-10256: --- Attachment: CASSANDRA-10256.txt > document commitlog segment size's relationship to max write size > > > Key: CASSANDRA-10256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10256 > Project: Cassandra > Issue Type: Improvement > Components: Config >Reporter: Chris Burroughs >Priority: Trivial > Labels: lhf > Attachments: CASSANDRA-10256.txt > > > This is in the code: > https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L57 > But not part of the description in cassandra.yaml -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10256) document commitlog segment size's relationship to max write size
[ https://issues.apache.org/jira/browse/CASSANDRA-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909066#comment-14909066 ] Tushar Agrawal commented on CASSANDRA-10256: Submitted the patch. Please help / guide as this is my first contribution. > document commitlog segment size's relationship to max write size > > > Key: CASSANDRA-10256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10256 > Project: Cassandra > Issue Type: Improvement > Components: Config >Reporter: Chris Burroughs >Priority: Trivial > Labels: lhf > Attachments: CASSANDRA-10256.txt > > > This is in the code: > https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L57 > But not part of the description in cassandra.yaml -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CASSANDRA-10256) document commitlog segment size's relationship to max write size
[ https://issues.apache.org/jira/browse/CASSANDRA-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tushar Agrawal updated CASSANDRA-10256: --- Comment: was deleted (was: Submitted the patch. Please help / guide as this is my first contribution.) > document commitlog segment size's relationship to max write size > > > Key: CASSANDRA-10256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10256 > Project: Cassandra > Issue Type: Improvement > Components: Config >Reporter: Chris Burroughs >Priority: Trivial > Labels: lhf > Attachments: CASSANDRA-10256.txt > > > This is in the code: > https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L57 > But not part of the description in cassandra.yaml -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10298) Replaced dead node stayed in gossip forever
[
https://issues.apache.org/jira/browse/CASSANDRA-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dikang Gu updated CASSANDRA-10298:
--
Attachment: (was: CASSANDRA-10298.patch.1)
> Replaced dead node stayed in gossip forever
> ---
>
> Key: CASSANDRA-10298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10298
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> The dead node stayed in the nodetool status,
> DN 10.210.165.55379.76 GB 256 ? null
> And in the log, it throws NPE when trying to remove it.
> {code}
> 2015-09-10_06:41:22.92453 ERROR 06:41:22 Exception in thread
> Thread[GossipStage:1,5,main]
> 2015-09-10_06:41:22.92454 java.lang.NullPointerException: null
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:100)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.db.HintedHandOffManager.deleteHintsForEndpoint(HintedHandOffManager.java:201)
>
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1886)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1902)
> 2015-09-10_06:41:22.92456 at
> org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1805)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1473)
>
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2099)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1009)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1085)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> 2015-09-10_06:41:22.92459 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_45]
> 2015-09-10_06:41:22.92460 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_45]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10298) Replaced dead node stayed in gossip forever
[
https://issues.apache.org/jira/browse/CASSANDRA-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dikang Gu updated CASSANDRA-10298:
--
Attachment: CASSANDRA-10298.patch.1
> Replaced dead node stayed in gossip forever
> ---
>
> Key: CASSANDRA-10298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10298
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> The dead node stayed in the nodetool status,
> DN 10.210.165.55379.76 GB 256 ? null
> And in the log, it throws NPE when trying to remove it.
> {code}
> 2015-09-10_06:41:22.92453 ERROR 06:41:22 Exception in thread
> Thread[GossipStage:1,5,main]
> 2015-09-10_06:41:22.92454 java.lang.NullPointerException: null
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:100)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.db.HintedHandOffManager.deleteHintsForEndpoint(HintedHandOffManager.java:201)
>
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1886)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1902)
> 2015-09-10_06:41:22.92456 at
> org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1805)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1473)
>
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2099)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1009)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1085)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> 2015-09-10_06:41:22.92459 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_45]
> 2015-09-10_06:41:22.92460 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_45]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10298) Replaced dead node stayed in gossip forever
[
https://issues.apache.org/jira/browse/CASSANDRA-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dikang Gu updated CASSANDRA-10298:
--
Attachment: (was: CASSANDRA-10298.patch)
> Replaced dead node stayed in gossip forever
> ---
>
> Key: CASSANDRA-10298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10298
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>
> The dead node stayed in the nodetool status,
> DN 10.210.165.55379.76 GB 256 ? null
> And in the log, it throws NPE when trying to remove it.
> {code}
> 2015-09-10_06:41:22.92453 ERROR 06:41:22 Exception in thread
> Thread[GossipStage:1,5,main]
> 2015-09-10_06:41:22.92454 java.lang.NullPointerException: null
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:100)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.db.HintedHandOffManager.deleteHintsForEndpoint(HintedHandOffManager.java:201)
>
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1886)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1902)
> 2015-09-10_06:41:22.92456 at
> org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1805)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1473)
>
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2099)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1009)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1085)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> 2015-09-10_06:41:22.92459 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_45]
> 2015-09-10_06:41:22.92460 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_45]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10298) Replaced dead node stayed in gossip forever
[
https://issues.apache.org/jira/browse/CASSANDRA-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dikang Gu updated CASSANDRA-10298:
--
Attachment: CASSANDRA-10298.patch
> Replaced dead node stayed in gossip forever
> ---
>
> Key: CASSANDRA-10298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10298
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Attachments: CASSANDRA-10298.patch
>
>
> The dead node stayed in the nodetool status,
> DN 10.210.165.55379.76 GB 256 ? null
> And in the log, it throws NPE when trying to remove it.
> {code}
> 2015-09-10_06:41:22.92453 ERROR 06:41:22 Exception in thread
> Thread[GossipStage:1,5,main]
> 2015-09-10_06:41:22.92454 java.lang.NullPointerException: null
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:100)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.db.HintedHandOffManager.deleteHintsForEndpoint(HintedHandOffManager.java:201)
>
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1886)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1902)
> 2015-09-10_06:41:22.92456 at
> org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1805)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1473)
>
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2099)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1009)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1085)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> 2015-09-10_06:41:22.92459 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_45]
> 2015-09-10_06:41:22.92460 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_45]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10298) Replaced dead node stayed in gossip forever
[
https://issues.apache.org/jira/browse/CASSANDRA-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909092#comment-14909092
]
Dikang Gu edited comment on CASSANDRA-10298 at 9/26/15 5:15 AM:
tested on some of our production servers, the "DN 10.210.165.55" disappeared
from the nodetool status after deploying this patch.
was (Author: dikanggu):
tested on some of our production servers, the DN disappeared from the nodetool
status after deploying this patch.
> Replaced dead node stayed in gossip forever
> ---
>
> Key: CASSANDRA-10298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10298
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 2.1.x
>
> Attachments: CASSANDRA-10298.patch
>
>
> The dead node stayed in the nodetool status,
> DN 10.210.165.55379.76 GB 256 ? null
> And in the log, it throws NPE when trying to remove it.
> {code}
> 2015-09-10_06:41:22.92453 ERROR 06:41:22 Exception in thread
> Thread[GossipStage:1,5,main]
> 2015-09-10_06:41:22.92454 java.lang.NullPointerException: null
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:100)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.db.HintedHandOffManager.deleteHintsForEndpoint(HintedHandOffManager.java:201)
>
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1886)
> 2015-09-10_06:41:22.92455 at
> org.apache.cassandra.service.StorageService.excise(StorageService.java:1902)
> 2015-09-10_06:41:22.92456 at
> org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1805)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1473)
>
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2099)
> 2015-09-10_06:41:22.92457 at
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1009)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1085)
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
>
> 2015-09-10_06:41:22.92458 at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
> 2015-09-10_06:41:22.92459 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_45]
> 2015-09-10_06:41:22.92460 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_45]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
