[jira] [Commented] (CASSANDRA-8460) Make it possible to move non-compacting sstables to slow/big storage in DTCS
[ https://issues.apache.org/jira/browse/CASSANDRA-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335527#comment-16335527 ] Pavel Trukhanov commented on CASSANDRA-8460: Why can't we simply allow a CS instance to spread across two disks - SSD and corresponding archival HDD, so it will see all the data for any particular vnode at once and won't falsely ressurect something? > Make it possible to move non-compacting sstables to slow/big storage in DTCS > > > Key: CASSANDRA-8460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8460 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Priority: Major > Labels: doc-impacting, dtcs > Fix For: 4.x > > > It would be nice if we could configure DTCS to have a set of extra data > directories where we move the sstables once they are older than > max_sstable_age_days. > This would enable users to have a quick, small SSD for hot, new data, and big > spinning disks for data that is rarely read and never compacted. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8460) Make it possible to move non-compacting sstables to slow/big storage in DTCS
[ https://issues.apache.org/jira/browse/CASSANDRA-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853810#comment-15853810 ] Pavel Trukhanov commented on CASSANDRA-8460: Any plans on that one? And any thoughts with regards to TWCS? [~bdeggleston] ? > Make it possible to move non-compacting sstables to slow/big storage in DTCS > > > Key: CASSANDRA-8460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8460 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson > Labels: doc-impacting, dtcs > Fix For: 3.x > > > It would be nice if we could configure DTCS to have a set of extra data > directories where we move the sstables once they are older than > max_sstable_age_days. > This would enable users to have a quick, small SSD for hot, new data, and big > spinning disks for data that is rarely read and never compacted. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15851256#comment-15851256
]
Pavel Trukhanov commented on CASSANDRA-11871:
-
Thanks for clarification.
Isn't that ResultSet is built in memory anyways?
And it could be big in some cases like {{allow filtering}}?
I don't see why not allow building a lot of buckets simultaneously rather than
just one at a time.
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849985#comment-15849985
]
Pavel Trukhanov edited comment on CASSANDRA-11871 at 2/2/17 2:41 PM:
-
Do I understand correctly that {{SELECT minute(time), count() FROM Trades ..
GROUP BY minute(time)}} shouldn't be allowed because {{minute}} is not
monotonic, while {{floor(dt, 1m)}} is?
So is there any other functions other than {{floor}} and probably {{ceil}} that
qualify to be allowed in group by?
Could it be reconsidered to allow {{minute}} and {{parity}} and other fns, for
example with some warning for user a-la that {{ALLOW FILTERING}}?
So this {{floor}} fn is more like date_trunc from Postgres
{{date_trunc(text, timestamp)}} — Truncate to specified precision
{{date_trunc('hour', timestamp '2001-02-16 20:38:40') -> '2001-02-16
20:00:00'}}.
And I suggest that there should be plain {{trunc}} fn for integers etc.
Also I think the right way to get only full "buckets" (groups) and not weird
first and last ones for {{SELECT count() FROM foo WHERE time > now() - 10h
GROUP BY floor(time, 3h)}} would be {{SELECT count() FROM foo WHERE time >
floor(now() - 10h, 3h) GROUP BY floor(time, 3h)}} which looks ugly but right.
was (Author: pavel.trukhanov):
Do I understand correctly that {{SELECT minute(time), count() FROM Trades ..
GROUP BY minute(time)}} shouldn't be allowed because {{minute}} is not
monotonic, while {{floor(dt, 1m)}} is?
So is there any other functions other than {{floor}} and probably {{ceil}} that
qualify to be allowed in group by?
Also I think the right way to get only full "buckets" (groups) and not weird
first and last ones for {{SELECT count() FROM foo WHERE time > now() - 10h
GROUP BY floor(time, 3h)}} would be {{SELECT count() FROM foo WHERE time >
floor(now() - 10h, 3h) GROUP BY floor(time, 3h)}} which looks ugly but right.
So this {{floor}} fn is more like date_trunc from Postgres
{{date_trunc(text, timestamp)}} — Truncate to specified precision
{{date_trunc('hour', timestamp '2001-02-16 20:38:40') -> '2001-02-16
20:00:00'}}.
And I suggest that there should be plain {{trunc}} fn for integers etc.
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian JIRA
[jira] [Comment Edited] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849985#comment-15849985
]
Pavel Trukhanov edited comment on CASSANDRA-11871 at 2/2/17 2:38 PM:
-
Do I understand correctly that {{SELECT minute(time), count() FROM Trades ..
GROUP BY minute(time)}} shouldn't be allowed because {{minute}} is not
monotonic, while {{floor(dt, 1m)}} is?
So is there any other functions other than {{floor}} and probably {{ceil}} that
qualify to be allowed in group by?
Also I think the right way to get only full "buckets" (groups) and not weird
first and last ones for {{SELECT count() FROM foo WHERE time > now() - 10h
GROUP BY floor(time, 3h)}} would be {{SELECT count() FROM foo WHERE time >
floor(now() - 10h, 3h) GROUP BY floor(time, 3h)}} which looks ugly but right.
So this {{floor}} fn is more like date_trunc from Postgres
{{date_trunc(text, timestamp)}} — Truncate to specified precision
{{date_trunc('hour', timestamp '2001-02-16 20:38:40') -> '2001-02-16
20:00:00'}}.
And I suggest that there should be plain {{trunc}} fn for integers etc.
was (Author: pavel.trukhanov):
Do I understand correctly that `SELECT minute(time), count() FROM Trades ..
GROUP BY minute(time);` shouldn't be allowed because `minute` is not monotonic,
while `floor(dt, 1m)` is?
So is there any other functions other than `floor` and `ceil` that qualify to
be allowed in group by?
Also I think the right way to get only full "buckets" (groups) and not weird
first and last ones for `SELECT count() FROM foo WHERE time > now() - 10h GROUP
BY floor(time, 3h);` would be `SELECT count() FROM foo WHERE time > floor(now()
- 10h, 3h) GROUP BY floor(time, 3h);` which looks ugly but right;
So this `floor` thing is more like date_trunc from Postgres
`date_trunc(text, timestamp)` — Truncate to specified precision
`date_trunc('hour', timestamp '2001-02-16 20:38:40') -> '2001-02-16 20:00:00'`.
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-11871) Allow to aggregate by time intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-11871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849985#comment-15849985
]
Pavel Trukhanov commented on CASSANDRA-11871:
-
Do I understand correctly that `SELECT minute(time), count() FROM Trades ..
GROUP BY minute(time);` shouldn't be allowed because `minute` is not monotonic,
while `floor(dt, 1m)` is?
So is there any other functions other than `floor` and `ceil` that qualify to
be allowed in group by?
Also I think the right way to get only full "buckets" (groups) and not weird
first and last ones for `SELECT count() FROM foo WHERE time > now() - 10h GROUP
BY floor(time, 3h);` would be `SELECT count() FROM foo WHERE time > floor(now()
- 10h, 3h) GROUP BY floor(time, 3h);` which looks ugly but right;
So this `floor` thing is more like date_trunc from Postgres
`date_trunc(text, timestamp)` — Truncate to specified precision
`date_trunc('hour', timestamp '2001-02-16 20:38:40') -> '2001-02-16 20:00:00'`.
> Allow to aggregate by time intervals
>
>
> Key: CASSANDRA-11871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11871
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> For time series data it can be usefull to aggregate by time intervals.
> The idea would be to add support for one or several functions in the {{GROUP
> BY}} clause.
> Regarding the implementation, even if in general I also prefer to follow the
> SQL syntax, I do not believe it will be a good fit for Cassandra.
> If we have a table like:
> {code}
> CREATE TABLE trades
> {
> symbol text,
> date date,
> time time,
> priceMantissa int,
> priceExponent tinyint,
> volume int,
> PRIMARY KEY ((symbol, date), time)
> };
> {code}
> The trades will be inserted with an increasing time and sorted in the same
> order. As we can have to process a large amount of data, we want to try to
> limit ourself to the cases where we can build the groups on the flight (which
> is not a requirement in the SQL world).
> If we want to get the number of trades per minutes with the SQL syntax we
> will have to write:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY hour(time), minute(time);}}
> which is fine. The problem is that if the user invert by mistake the
> functions like that:
> {{SELECT hour(time), minute(time), count() FROM Trades WHERE symbol = 'AAPL'
> AND date = '2016-01-11' GROUP BY minute(time), hour(time);}}
> the query will return weird results.
> The only way to prevent that would be to check the function order and make
> sure that we do not allow to skip functions (e.g. {{GROUP BY hour(time),
> second(time)}}).
> In my opinion a function like {{floor(, )}} will be
> much better as it does not allow for this type of mistakes and is much more
> flexible (you can create 5 minutes buckets if you want to).
> {{SELECT floor(time, m), count() FROM Trades WHERE symbol = 'AAPL' AND date =
> '2016-01-11' GROUP BY floor(time, m);}}
> An important aspect to keep in mind with a function like {{floor}} is the
> starting point. For a query like: {{SELECT floor(time, m), count() FROM
> Trades WHERE symbol = 'AAPL' AND date = '2016-01-11' AND time >= '01:30:00'
> AND time =< '07:30:00' GROUP BY floor(time, 2h);}}, I think that ideally the
> result should return 3 groups: {{01:30:00}}, {{03:30:00}} and {{05:30:00}}.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-8826) Distributed aggregates
[ https://issues.apache.org/jira/browse/CASSANDRA-8826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849883#comment-15849883 ] Pavel Trukhanov commented on CASSANDRA-8826: So what should happen for this feature to get going? Can one just try to implement it or any more clarifications/discussion needed? > Distributed aggregates > -- > > Key: CASSANDRA-8826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8826 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Priority: Minor > > Aggregations have been implemented in CASSANDRA-4914. > All calculation is performed on the coordinator. This means, that all data is > pulled by the coordinator and processed there. > This ticket's about to distribute aggregates to make them more efficient. > Currently some related tickets (esp. CASSANDRA-8099) are currently in > progress - we should wait for them to land before talking about > implementation. > Another playgrounds (not covered by this ticket), that might be related is > about _distributed filtering_. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CASSANDRA-12614) Cassandra stops compacting
[
https://issues.apache.org/jira/browse/CASSANDRA-12614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Trukhanov resolved CASSANDRA-12614.
-
Resolution: Invalid
It was due to somehow corrupted .data file
As we found out that Maxtimestamp in that sstable was like year 14800+ or
something.
So we fixed that timestamp (by simply overwriting data — thanks to
sstable2json) and it fixed everything
> Cassandra stops compacting
> --
>
> Key: CASSANDRA-12614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12614
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: linux cas-2.1.15
>Reporter: Pavel Trukhanov
>
> After some issues 3 out of 9 our cassandra nodes stopped to compact one
> particular cf. So we see constantly increasing number of sstables for that cf.
> While other cfs on these nodes and other nodes keep compacting.
> This cf has DTCS.
> Here's desc:
> {quote}
> CREATE TABLE okmeter.bunches (
> bunch_key text,
> bunch_ts bigint,
> version uuid,
> value blob,
> PRIMARY KEY (bunch_key, bunch_ts, version)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (bunch_ts DESC, version ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '\{"keys":"ALL", "rows_per_partition":"NONE"\}'
> AND comment = ''
> AND compaction = \{'class':
> 'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy',
> 'max_window_size_seconds': '3686400', 'base_time_seconds': '14400',
> 'max_sstable_age_days': '90'\}
> 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 = '99.0PERCENTILE';
> {quote}
> I couldn't find anything interesting in logs.
> I've tried drain & restart - no luck.
> I've tried to disable/enable autocompation - nothing's changed.
> I've tried force major - it works but sstable count starts increasing after
> major is done.
> !https://dl.dropboxusercontent.com/u/8273787/Selection_630_.jpg!
> It seems that it just completely ignores autocompaction enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12614) Cassandra stops compacting
[
https://issues.apache.org/jira/browse/CASSANDRA-12614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Trukhanov updated CASSANDRA-12614:
Description:
After some issues 3 out of 9 our cassandra nodes stopped to compact one
particular cf. So we see constantly increasing number of sstables for that cf.
While other cfs on these nodes and other nodes keep compacting.
This cf has DTCS.
Here's desc:
{quote}
CREATE TABLE okmeter.bunches (
bunch_key text,
bunch_ts bigint,
version uuid,
value blob,
PRIMARY KEY (bunch_key, bunch_ts, version)
) WITH COMPACT STORAGE
AND CLUSTERING ORDER BY (bunch_ts DESC, version ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = '\{"keys":"ALL", "rows_per_partition":"NONE"\}'
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy',
'max_window_size_seconds': '3686400', 'base_time_seconds': '14400',
'max_sstable_age_days': '90'\}
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 = '99.0PERCENTILE';
{quote}
I couldn't find anything interesting in logs.
I've tried drain & restart - no luck.
I've tried to disable/enable autocompation - nothing's changed.
I've tried force major - it works but sstable count starts increasing after
major is done.
!https://dl.dropboxusercontent.com/u/8273787/Selection_630_.jpg!
It seems that it just completely ignores autocompaction enabled.
was:
After some issues 3 out of 9 our cassandra nodes stopped to compact one
particular cf. So we see constantly increasing number of sstables for that cf.
While other cfs on these nodes and other nodes keep compacting.
This cf has DTCS.
Here's desc:
{quote}
CREATE TABLE okmeter.bunches (
bunch_key text,
bunch_ts bigint,
version uuid,
value blob,
PRIMARY KEY (bunch_key, bunch_ts, version)
) WITH COMPACT STORAGE
AND CLUSTERING ORDER BY (bunch_ts DESC, version ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = '\{"keys":"ALL", "rows_per_partition":"NONE"\}'
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy',
'max_window_size_seconds': '3686400', 'base_time_seconds': '14400',
'max_sstable_age_days': '90'\}
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 = '99.0PERCENTILE';
{quote}
I couldn't find anything interesting in logs.
I've tried drain & restart - no luck.
I've tried to disable/enable autocompation - nothing's changed.
I've tried force major - it works but sstable count starts increasing after
major is done.
It seems that it just completely ignores autocompaction enabled.
> Cassandra stops compacting
> --
>
> Key: CASSANDRA-12614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12614
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: linux cas-2.1.15
>Reporter: Pavel Trukhanov
>
> After some issues 3 out of 9 our cassandra nodes stopped to compact one
> particular cf. So we see constantly increasing number of sstables for that cf.
> While other cfs on these nodes and other nodes keep compacting.
> This cf has DTCS.
> Here's desc:
> {quote}
> CREATE TABLE okmeter.bunches (
> bunch_key text,
> bunch_ts bigint,
> version uuid,
> value blob,
> PRIMARY KEY (bunch_key, bunch_ts, version)
> ) WITH COMPACT STORAGE
> AND CLUSTERING ORDER BY (bunch_ts DESC, version ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '\{"keys":"ALL", "rows_per_partition":"NONE"\}'
> AND comment = ''
> AND compaction = \{'class':
> 'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy',
> 'max_window_size_seconds': '3686400', 'base_time_seconds': '14400',
> 'max_sstable_age_days': '90'\}
> 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 = '99.0PERCENTILE';
> {quote}
> I couldn't find anything interesting in logs.
> I've tried drain & restart - no luck.
> I've tried to disable/enable autocompation - nothing's changed.
> I've tried force major - it works but sstable count starts increasing after
[jira] [Created] (CASSANDRA-12614) Cassandra stops compacting
Pavel Trukhanov created CASSANDRA-12614:
---
Summary: Cassandra stops compacting
Key: CASSANDRA-12614
URL: https://issues.apache.org/jira/browse/CASSANDRA-12614
Project: Cassandra
Issue Type: Bug
Components: Compaction
Environment: linux cas-2.1.15
Reporter: Pavel Trukhanov
After some issues 3 out of 9 our cassandra nodes stopped to compact one
particular cf. So we see constantly increasing number of sstables for that cf.
While other cfs on these nodes and other nodes keep compacting.
This cf has DTCS.
Here's desc:
{quote}
CREATE TABLE okmeter.bunches (
bunch_key text,
bunch_ts bigint,
version uuid,
value blob,
PRIMARY KEY (bunch_key, bunch_ts, version)
) WITH COMPACT STORAGE
AND CLUSTERING ORDER BY (bunch_ts DESC, version ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = '\{"keys":"ALL", "rows_per_partition":"NONE"\}'
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy',
'max_window_size_seconds': '3686400', 'base_time_seconds': '14400',
'max_sstable_age_days': '90'\}
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 = '99.0PERCENTILE';
{quote}
I couldn't find anything interesting in logs.
I've tried drain & restart - no luck.
I've tried to disable/enable autocompation - nothing's changed.
I've tried force major - it works but sstable count starts increasing after
major is done.
It seems that it just completely ignores autocompaction enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[
https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191520#comment-15191520
]
Pavel Trukhanov commented on CASSANDRA-6167:
{code}LIMIT UNTIL condition {code}?
> Add end-slice termination predicate
> ---
>
> Key: CASSANDRA-6167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6167
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Tupshin Harper
>Priority: Minor
> Labels: cql
>
> When doing performing storage-engine slices, it would sometimes be beneficial
> to have the slice terminate for other reasons other than number of columns or
> min/max cell name.
> Since we are able to look at the contents of each cell as we read it, this is
> potentially doable with very little overhead.
> Probably more challenging than the storage-engine implementation itself, is
> to come up with appropriate CQL syntax (Thrift, should we decide to support
> it, would be trivial).
> Two possibilities ar
> 1) special where function:
> SELECT pk,event from cf WHERE pk IN (1,5,10,11) AND
> partition_predicate({predicate})
> or a bigger language change, but i think one I prefer. more like:
> 2) SELECT pk,event from cf where pk IN (1,5,10,11) UNTIL PARTITION event
> {predicate}
> Neither feels perfect, but I do like the fact that the second one at least
> clearly states what it is intended to do.
> By using "UNTIL PARTITION", we could re-use the UNTIL keyword to handle other
> kinds of early-termination of selects that the coordinator might be able to
> do, such as stop retrieving additional rows from shards after a particular
> criterion was met.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[
https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191514#comment-15191514
]
Pavel Trukhanov commented on CASSANDRA-6167:
As I understand it, it's kind of limit like but controllable by user. How about
using LIMIT keyword but with condition rather than integer constant?
> Add end-slice termination predicate
> ---
>
> Key: CASSANDRA-6167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6167
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Tupshin Harper
>Priority: Minor
> Labels: cql
>
> When doing performing storage-engine slices, it would sometimes be beneficial
> to have the slice terminate for other reasons other than number of columns or
> min/max cell name.
> Since we are able to look at the contents of each cell as we read it, this is
> potentially doable with very little overhead.
> Probably more challenging than the storage-engine implementation itself, is
> to come up with appropriate CQL syntax (Thrift, should we decide to support
> it, would be trivial).
> Two possibilities ar
> 1) special where function:
> SELECT pk,event from cf WHERE pk IN (1,5,10,11) AND
> partition_predicate({predicate})
> or a bigger language change, but i think one I prefer. more like:
> 2) SELECT pk,event from cf where pk IN (1,5,10,11) UNTIL PARTITION event
> {predicate}
> Neither feels perfect, but I do like the fact that the second one at least
> clearly states what it is intended to do.
> By using "UNTIL PARTITION", we could re-use the UNTIL keyword to handle other
> kinds of early-termination of selects that the coordinator might be able to
> do, such as stop retrieving additional rows from shards after a particular
> criterion was met.
--
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=15187867#comment-15187867 ] Pavel Trukhanov commented on CASSANDRA-8844: bq. Which is starting to sound an awful lot like storing CDC-data in a Cassandra table. While that's technically feasible, the lessons we've learned with both hints and batchlog should make us think really long and really hard before going down that road w/another feature that's basically going to double write mutation overhead for an enabled CF. [~JoshuaMcKenzie] where can I read more about that? Is there anything like a write-up or something? Or should I just read a handful of tickets with comments? Can you help me to compile a list? I'm looking forward to having this feature, although I think there's a core problem with the current design. I'm trying to learn more around all that and to read thoroughly and comprehend current design doc before making my comment. > Change Data Capture (CDC) > - > > Key: CASSANDRA-8844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8844 > Project: Cassandra > Issue Type: New Feature > Components: Coordination, Local Write-Read Paths >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 named with a predictable naming schema, making it > triivial
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[
https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185556#comment-15185556
]
Pavel Trukhanov commented on CASSANDRA-6167:
I wanted to vote for the issue but was not sure about the whole idea, though.
So please consider this comment as a vote for this or something alike:
bq. filtering based on the value of a static column by comparison to a
non-static column
> Add end-slice termination predicate
> ---
>
> Key: CASSANDRA-6167
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6167
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Tupshin Harper
>Priority: Minor
> Labels: cql
>
> When doing performing storage-engine slices, it would sometimes be beneficial
> to have the slice terminate for other reasons other than number of columns or
> min/max cell name.
> Since we are able to look at the contents of each cell as we read it, this is
> potentially doable with very little overhead.
> Probably more challenging than the storage-engine implementation itself, is
> to come up with appropriate CQL syntax (Thrift, should we decide to support
> it, would be trivial).
> Two possibilities ar
> 1) special where function:
> SELECT pk,event from cf WHERE pk IN (1,5,10,11) AND
> partition_predicate({predicate})
> or a bigger language change, but i think one I prefer. more like:
> 2) SELECT pk,event from cf where pk IN (1,5,10,11) UNTIL PARTITION event
> {predicate}
> Neither feels perfect, but I do like the fact that the second one at least
> clearly states what it is intended to do.
> By using "UNTIL PARTITION", we could re-use the UNTIL keyword to handle other
> kinds of early-termination of selects that the coordinator might be able to
> do, such as stop retrieving additional rows from shards after a particular
> criterion was met.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8234) CTAS (CREATE TABLE AS SELECT)
[ https://issues.apache.org/jira/browse/CASSANDRA-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185063#comment-15185063 ] Pavel Trukhanov edited comment on CASSANDRA-8234 at 3/8/16 4:15 PM: bq. Aleksey Yeschenko > ... Once we start bundling it [spark] with Cassandra itself ... [~iamaleksey] I couldn't find anything on the topic, can you help me, please? Is there anything like a roadmap for that? was (Author: pavel.trukhanov): bq. Aleksey Yeschenko > ... Once we start bundling it with Cassandra itself ... [~iamaleksey] I couldn't find anything on the topic, can you help me, please? Is there anything like a roadmap for that? > CTAS (CREATE TABLE AS SELECT) > - > > Key: CASSANDRA-8234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8234 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Robin Schumacher > Fix For: 3.x > > > Continuous request from users is the ability to do CREATE TABLE AS SELECT. > The simplest form would be copying the entire table. More advanced would > allow specifying thes column and UDF to call as well as filtering rows out in > WHERE. > More advanced still would be to get all the way to allowing JOIN, for which > we probably want to integrate Spark. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8234) CTAS (CREATE TABLE AS SELECT)
[ https://issues.apache.org/jira/browse/CASSANDRA-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185063#comment-15185063 ] Pavel Trukhanov edited comment on CASSANDRA-8234 at 3/8/16 4:14 PM: bq. Aleksey Yeschenko > ... Once we start bundling it with Cassandra itself ... [~iamaleksey] I couldn't find anything on the topic, can you help me, please? Is there anything like a roadmap for that? was (Author: pavel.trukhanov): bq. Aleksey Yeschenko > ... Once we start bundling it with Cassandra itself ... [~iamaleksey] I couldn't find anything on the topic, can you help me, please? Is there anything like a roadmap for that? bq. Brian Hess > That is, it will return "success" to the client, but the operation will be a background operation. First, is that correct? If so, I think there will have to be a status like in MVs and 2Is, correct? [~brianmhess] Sorry for a probably stupid question by what's "MVs" and "2Is"? > CTAS (CREATE TABLE AS SELECT) > - > > Key: CASSANDRA-8234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8234 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Robin Schumacher > Fix For: 3.x > > > Continuous request from users is the ability to do CREATE TABLE AS SELECT. > The simplest form would be copying the entire table. More advanced would > allow specifying thes column and UDF to call as well as filtering rows out in > WHERE. > More advanced still would be to get all the way to allowing JOIN, for which > we probably want to integrate Spark. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8234) CTAS (CREATE TABLE AS SELECT)
[ https://issues.apache.org/jira/browse/CASSANDRA-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185063#comment-15185063 ] Pavel Trukhanov commented on CASSANDRA-8234: bq. Aleksey Yeschenko > ... Once we start bundling it with Cassandra itself ... [~iamaleksey] I couldn't find anything on the topic, can you help me, please? Is there anything like a roadmap for that? bq. Brian Hess > That is, it will return "success" to the client, but the operation will be a background operation. First, is that correct? If so, I think there will have to be a status like in MVs and 2Is, correct? [~brianmhess] Sorry for a probably stupid question by what's "MVs" and "2Is"? > CTAS (CREATE TABLE AS SELECT) > - > > Key: CASSANDRA-8234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8234 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Robin Schumacher > Fix For: 3.x > > > Continuous request from users is the ability to do CREATE TABLE AS SELECT. > The simplest form would be copying the entire table. More advanced would > allow specifying thes column and UDF to call as well as filtering rows out in > WHERE. > More advanced still would be to get all the way to allowing JOIN, for which > we probably want to integrate Spark. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11059) In cqlsh show static columns in a different color
[ https://issues.apache.org/jira/browse/CASSANDRA-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15179875#comment-15179875 ] Pavel Trukhanov commented on CASSANDRA-11059: - That's against the trunk. Please see here https://github.com/apache/cassandra/compare/trunk...okmeter:CASSANDRA-11059 But if it works for some previous versions too (need to check that) it still won't be backported — it's the policy, right? Or what? > In cqlsh show static columns in a different color > - > > Key: CASSANDRA-11059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11059 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: [cqlsh 5.0.1 | Cassandra 2.2.3 | CQL spec 3.3.1 | Native > protocol v4] >Reporter: Cédric Hernalsteens >Priority: Minor > Fix For: 3.x > > > The partition key columns are shown in red, the clustering columns in cyan, > it would be great to also distinguish between the static columns and the > other. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9430) Add startup options to cqlshrc
[
https://issues.apache.org/jira/browse/CASSANDRA-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15177751#comment-15177751
]
Pavel Trukhanov commented on CASSANDRA-9430:
Maybe it would be better (and solve all future requests for improvements like
this one) to add and "interactive mode" flag like there's in python etc.
Here're quotes from python and ipython usage help for this mode:
{quote}
If running code from the command line, become interactive afterwards.
{quote}
{quote}
inspect interactively after running script;
{quote}
So for example it'd work like this:
{code}
echo "paging off;" | cqlsh -i
{code}
and would be prefectly combinable with
{code}
-f FILE, --file=FILE Execute commands from FILE
{code}
but without exiting afterwards
> Add startup options to cqlshrc
> --
>
> Key: CASSANDRA-9430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9430
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Jeremy Hanna
>Priority: Minor
> Labels: cqlsh, lhf
>
> There are certain settings that would be nice to set defaults for in the
> cqlshrc file. For example, a user may want to set the paging to off by
> default for their environment. You can't simply do
> {code}
> echo "paging off;" | cqlsh
> {code}
> because this would disable paging and immediately exit cqlsh.
> So it would be nice to have a section of the cqlshrc to include default
> settings on startup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11059) In cqlsh show static columns in a different color
[ https://issues.apache.org/jira/browse/CASSANDRA-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15177725#comment-15177725 ] Pavel Trukhanov commented on CASSANDRA-11059: - Here's a very little patch https://github.com/okmeter/cassandra/commit/6f03489e4d869dccaf6f075e84a8ce6eb92ca6ce Should I do something else to make this happen? > In cqlsh show static columns in a different color > - > > Key: CASSANDRA-11059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11059 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: [cqlsh 5.0.1 | Cassandra 2.2.3 | CQL spec 3.3.1 | Native > protocol v4] >Reporter: Cédric Hernalsteens >Priority: Minor > Fix For: 2.2.3 > > > The partition key columns are shown in red, the clustering columns in cyan, > it would be great to also distinguish between the static columns and the > other. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-5296) NPE on /init.d/cassandra start
[
https://issues.apache.org/jira/browse/CASSANDRA-5296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613695#comment-13613695
]
Pavel Trukhanov commented on CASSANDRA-5296:
Right, i got it. No, i cant reproduce it, because i have only production
installation at the moment.
We really understood cause of problem: it was because we started one of nodes
from trunk build, while others was 1.2.1
We fixed all in prod by full restore from backup on newly installed servers.
I think one can close this as wont fix or something like that.
NPE on /init.d/cassandra start
--
Key: CASSANDRA-5296
URL: https://issues.apache.org/jira/browse/CASSANDRA-5296
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
{code}
== /var/log/cassandra/output.log ==
INFO 18:05:18,466 Logging initialized
INFO 18:05:18,477 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_32
INFO 18:05:18,478 Heap size: 6358564864/6358564864
INFO 18:05:18,478 Classpath:
/usr/share/java/mx4j-tools.jar:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.6.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-13.0.1.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jline-1.0.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/netty-3.5.9.Final.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.7.2.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.7.2.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.2.1.jar:/usr/share/cassandra/apache-cassandra-thrift-1.2.1.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/java/jna.jar:/etc/cassandra:/usr/share/java/commons-daemon.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 18:05:20,021 JNA mlockall successful
INFO 18:05:20,042 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 18:05:20,352 DiskAccessMode 'auto' determined to be mmap,
indexAccessMode is mmap
INFO 18:05:20,352 disk_failure_policy is stop
INFO 18:05:20,368 Global memtable threshold is enabled at 2048MB
INFO 18:05:21,401 Initializing key cache with capacity of 100 MBs.
INFO 18:05:21,417 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 18:05:21,417 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 18:05:21,420 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 18:05:21,640 Opening
/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-ib-3
(191 bytes)
INFO 18:05:22,185 Opening
/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ib-3
(2674 bytes)
INFO 18:05:22,214 Opening
/var/lib/cassandra/data/system/schema_columns/system-schema_columns-ib-3 (437
bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-3 (150 bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-2 (300 bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-1 (193 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-2 (120 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-7 (84 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-8 (535 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-4 (146 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-3 (90 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-6 (97 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-1 (351 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-5 (97 bytes)
[jira] [Commented] (CASSANDRA-5296) NPE on /init.d/cassandra start
[
https://issues.apache.org/jira/browse/CASSANDRA-5296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13611711#comment-13611711
]
Pavel Trukhanov commented on CASSANDRA-5296:
we had 3 nodes and 1 is down permanently right now.
it is still possible to reproduce CLI exceptions, but i didnt understand why i
marked CASSANDRA-5295 as duplicate?
NPE on /init.d/cassandra start
--
Key: CASSANDRA-5296
URL: https://issues.apache.org/jira/browse/CASSANDRA-5296
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
{code}
== /var/log/cassandra/output.log ==
INFO 18:05:18,466 Logging initialized
INFO 18:05:18,477 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_32
INFO 18:05:18,478 Heap size: 6358564864/6358564864
INFO 18:05:18,478 Classpath:
/usr/share/java/mx4j-tools.jar:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.6.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-13.0.1.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jline-1.0.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/netty-3.5.9.Final.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.7.2.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.7.2.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.2.1.jar:/usr/share/cassandra/apache-cassandra-thrift-1.2.1.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/java/jna.jar:/etc/cassandra:/usr/share/java/commons-daemon.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 18:05:20,021 JNA mlockall successful
INFO 18:05:20,042 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 18:05:20,352 DiskAccessMode 'auto' determined to be mmap,
indexAccessMode is mmap
INFO 18:05:20,352 disk_failure_policy is stop
INFO 18:05:20,368 Global memtable threshold is enabled at 2048MB
INFO 18:05:21,401 Initializing key cache with capacity of 100 MBs.
INFO 18:05:21,417 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 18:05:21,417 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 18:05:21,420 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 18:05:21,640 Opening
/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-ib-3
(191 bytes)
INFO 18:05:22,185 Opening
/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ib-3
(2674 bytes)
INFO 18:05:22,214 Opening
/var/lib/cassandra/data/system/schema_columns/system-schema_columns-ib-3 (437
bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-3 (150 bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-2 (300 bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-1 (193 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-2 (120 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-7 (84 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-8 (535 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-4 (146 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-3 (90 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-6 (97 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-1 (351 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-5 (97 bytes)
java.lang.NullPointerException
at
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at
[jira] [Created] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands
Pavel Trukhanov created CASSANDRA-5295:
--
Summary: cassandra-cli java.lang.NullPointerException for almost
any commands
Key: CASSANDRA-5295
URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
{code}
cassandra-cli -v -h srv1 -p 9160
Connected to: myspace on srv1/9160
Welcome to Cassandra CLI version 1.2.1
Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.
[default@unknown] use myspace;
java.lang.NullPointerException
[default@myspace] describe;
java.lang.NullPointerException
[default@myspace] list mycf1;
null
[default@myspace]
{code}
and nothing in system.log or output.log
which information can i provide to speed up cause determination?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5296) NPE on /init.d/cassandra start
Pavel Trukhanov created CASSANDRA-5296:
--
Summary: NPE on /init.d/cassandra start
Key: CASSANDRA-5296
URL: https://issues.apache.org/jira/browse/CASSANDRA-5296
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
{code}
== /var/log/cassandra/output.log ==
INFO 18:05:18,466 Logging initialized
INFO 18:05:18,477 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_32
INFO 18:05:18,478 Heap size: 6358564864/6358564864
INFO 18:05:18,478 Classpath:
/usr/share/java/mx4j-tools.jar:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.6.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-13.0.1.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jline-1.0.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/netty-3.5.9.Final.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.7.2.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.7.2.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.2.1.jar:/usr/share/cassandra/apache-cassandra-thrift-1.2.1.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/java/jna.jar:/etc/cassandra:/usr/share/java/commons-daemon.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 18:05:20,021 JNA mlockall successful
INFO 18:05:20,042 Loading settings from file:/etc/cassandra/cassandra.yaml
INFO 18:05:20,352 DiskAccessMode 'auto' determined to be mmap, indexAccessMode
is mmap
INFO 18:05:20,352 disk_failure_policy is stop
INFO 18:05:20,368 Global memtable threshold is enabled at 2048MB
INFO 18:05:21,401 Initializing key cache with capacity of 100 MBs.
INFO 18:05:21,417 Scheduling key cache save to each 14400 seconds (going to
save all keys).
INFO 18:05:21,417 Initializing row cache with capacity of 0 MBs and provider
org.apache.cassandra.cache.SerializingCacheProvider
INFO 18:05:21,420 Scheduling row cache save to each 0 seconds (going to save
all keys).
INFO 18:05:21,640 Opening
/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-ib-3
(191 bytes)
INFO 18:05:22,185 Opening
/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ib-3
(2674 bytes)
INFO 18:05:22,214 Opening
/var/lib/cassandra/data/system/schema_columns/system-schema_columns-ib-3 (437
bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-3 (150 bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-2 (300 bytes)
INFO 18:05:22,240 Opening
/var/lib/cassandra/data/system/peers/system-peers-ib-1 (193 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-2 (120 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-7 (84 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-8 (535 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-4 (146 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-3 (90 bytes)
INFO 18:05:22,395 Opening
/var/lib/cassandra/data/system/local/system-local-ib-6 (97 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-1 (351 bytes)
INFO 18:05:22,396 Opening
/var/lib/cassandra/data/system/local/system-local-ib-5 (97 bytes)
java.lang.NullPointerException
at
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:73)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:93)
at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:32)
at
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:96)
at
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1347)
at
[jira] [Commented] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands
[
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588411#comment-13588411
]
Pavel Trukhanov commented on CASSANDRA-5295:
{code}[default@unknown] use myspace;
java.lang.NullPointerException
java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.cassandra.cli.CliClient.loadCql3Defs(CliClient.java:339)
at org.apache.cassandra.cli.CliClient.getKSMetaData(CliClient.java:324)
at
org.apache.cassandra.cli.CliClient.executeUseKeySpace(CliClient.java:2025)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:263)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:210)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:337)
Caused by: java.lang.NullPointerException
at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
at
org.apache.cassandra.cli.CliClient.loadCql3DefsUnchecked(CliClient.java:361)
at org.apache.cassandra.cli.CliClient.loadCql3Defs(CliClient.java:335)
... 5 more
{code}
cassandra-cli java.lang.NullPointerException for almost any commands
Key: CASSANDRA-5295
URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
Labels: cassandra-cli
{code}
cassandra-cli -v -h srv1 -p 9160
Connected to: myspace on srv1/9160
Welcome to Cassandra CLI version 1.2.1
Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.
[default@unknown] use myspace;
java.lang.NullPointerException
[default@myspace] describe;
java.lang.NullPointerException
[default@myspace] list mycf1;
null
[default@myspace]
{code}
and nothing in system.log or output.log
which information can i provide to speed up cause determination?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands
[
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588443#comment-13588443
]
Pavel Trukhanov commented on CASSANDRA-5295:
{code}[default@myspace] list mycf1;
null
java.lang.NullPointerException
at org.apache.cassandra.cli.CliClient.currentCfDefs(CliClient.java:441)
at org.apache.cassandra.cli.CliClient.executeList(CliClient.java:1389)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:272)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:210)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:337)
[default@myspace] describe;
java.lang.NullPointerException
java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.cassandra.cli.CliClient.loadCql3Defs(CliClient.java:339)
at org.apache.cassandra.cli.CliClient.getKSMetaData(CliClient.java:324)
at
org.apache.cassandra.cli.CliClient.executeDescribe(CliClient.java:2229)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:257)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:210)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:337)
Caused by: java.lang.NullPointerException
at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
at
org.apache.cassandra.cli.CliClient.loadCql3DefsUnchecked(CliClient.java:361)
at org.apache.cassandra.cli.CliClient.loadCql3Defs(CliClient.java:335)
... 5 more
[default@myspace]
{code}
cassandra-cli java.lang.NullPointerException for almost any commands
Key: CASSANDRA-5295
URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
Labels: cassandra-cli
{code}
cassandra-cli -v -h srv1 -p 9160
Connected to: myspace on srv1/9160
Welcome to Cassandra CLI version 1.2.1
Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.
[default@unknown] use myspace;
java.lang.NullPointerException
[default@myspace] describe;
java.lang.NullPointerException
[default@myspace] list mycf1;
null
[default@myspace]
{code}
and nothing in system.log or output.log
which information can i provide to speed up cause determination?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands
[
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588706#comment-13588706
]
Pavel Trukhanov commented on CASSANDRA-5295:
checked:
{code}$ dpkg -l cassandra
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++---
ii cassandra1.2.1distributed
storage system for structured data
{code}
{code}
$ cassandra-cli -v -h srv2
Connected to: okmeter on srv2/9160
Welcome to Cassandra CLI version 1.2.1
{code}
cassandra-cli java.lang.NullPointerException for almost any commands
Key: CASSANDRA-5295
URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
Labels: cassandra-cli
{code}
cassandra-cli -v -h srv1 -p 9160
Connected to: myspace on srv1/9160
Welcome to Cassandra CLI version 1.2.1
Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.
[default@unknown] use myspace;
java.lang.NullPointerException
[default@myspace] describe;
java.lang.NullPointerException
[default@myspace] list mycf1;
null
[default@myspace]
{code}
and nothing in system.log or output.log
which information can i provide to speed up cause determination?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands
[
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588706#comment-13588706
]
Pavel Trukhanov edited comment on CASSANDRA-5295 at 2/27/13 8:11 PM:
-
checked:
{code}$ dpkg -l cassandra
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++---
ii cassandra1.2.1distributed
storage system for structured data
{code}
{code}
$ cassandra-cli -v -h srv2
Connected to: ccc on srv2/9160
Welcome to Cassandra CLI version 1.2.1
{code}
was (Author: pavel.trukhanov):
checked:
{code}$ dpkg -l cassandra
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++---
ii cassandra1.2.1distributed
storage system for structured data
{code}
{code}
$ cassandra-cli -v -h srv2
Connected to: okmeter on srv2/9160
Welcome to Cassandra CLI version 1.2.1
{code}
cassandra-cli java.lang.NullPointerException for almost any commands
Key: CASSANDRA-5295
URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
Labels: cassandra-cli
{code}
cassandra-cli -v -h srv1 -p 9160
Connected to: myspace on srv1/9160
Welcome to Cassandra CLI version 1.2.1
Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.
[default@unknown] use myspace;
java.lang.NullPointerException
[default@myspace] describe;
java.lang.NullPointerException
[default@myspace] list mycf1;
null
[default@myspace]
{code}
and nothing in system.log or output.log
which information can i provide to speed up cause determination?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
