[jira] [Updated] (CASSANDRA-12984) MVs are built unnecessarily again after bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-12984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12984: --- Resolution: Fixed Fix Version/s: (was: 3.0.x) (was: 3.x) 3.10 3.0.11 Status: Resolved (was: Patch Available) Thanks for the patch, [~brstgt]! Tests looked reasonable, so I committed the patch as [e9b7a0f|https://git1-us-west.apache.org/repos/asf/cassandra/?p=cassandra.git;a=commit;h=e9b7a0f2546579244ffc167c56122b0a47d4b4b0]. > MVs are built unnecessarily again after bootstrap > - > > Key: CASSANDRA-12984 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12984 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benjamin Roth >Assignee: Benjamin Roth > Fix For: 3.0.11, 3.10 > > > After bootstrap MVs are enqueued to be built but they have been already > created by the bootstrap. > Simply adding them to system.built_views after a successful bootstrap should > fix that issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12925) AssertionError executing authz stmt on UDF without keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-12925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15745437#comment-15745437
]
Carl Yeksigian commented on CASSANDRA-12925:
Code looks good, and I think I understand why we can't use the {{ClientState}},
but just to make sure: it's because of the way we share the permissions
statements between resources.
That is, if we had a {{GrantFunctionPermissionsStatement}}, we could add a new
interface {{KeyspacedStatement}} (or something) which would use the
{{ClientState}} as in {{CFStatement}}.
> AssertionError executing authz stmt on UDF without keyspace
> ---
>
> Key: CASSANDRA-12925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12925
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> Performing a {{GRANT}} or {{REVOKE}} on a user defined function requires the
> function name to be qualified by its keyspace. Unlike {{GRANT/REVOKE}} on a
> table, the keyspace cannot be inferred from the {{ClientState}} as it's
> needed by the parser to either lookup the function (in 2.2), or convert the
> function arguments from CQL types to their corresponding {{AbstractType}} (in
> 3.0+).
> Currently, performing such a statement results in an unhandled assert error
> and a {{ServerError}} response to the client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12984) MVs are built unnecessarily again after bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-12984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742670#comment-15742670 ] Carl Yeksigian commented on CASSANDRA-12984: Code looks good -- just running CI on these: ||3.0|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-review-12984-3.0-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-review-12984-3.0-dtest/]| ||3.11|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-review-12984-3.11-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-review-12984-3.11-dtest/]| ||3.X|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-review-12984-3.X-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-review-12984-3.X-dtest/]| ||trunk|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-review-12984-trunk-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-review-12984-trunk-dtest/]| > MVs are built unnecessarily again after bootstrap > - > > Key: CASSANDRA-12984 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12984 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benjamin Roth >Assignee: Benjamin Roth > Fix For: 3.0.x, 3.x > > > After bootstrap MVs are enqueued to be built but they have been already > created by the bootstrap. > Simply adding them to system.built_views after a successful bootstrap should > fix that issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12935) Use saved tokens when setting local tokens on StorageService.joinRing()
[
https://issues.apache.org/jira/browse/CASSANDRA-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12935:
---
Resolution: Fixed
Fix Version/s: 3.11
4.0
3.0.11
2.2.9
Status: Resolved (was: Patch Available)
+1
Committed as
[a449e8f|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=a449e8f70f047081b2fd5892219ad2659d0027bd]
and merged forward.
> Use saved tokens when setting local tokens on StorageService.joinRing()
> ---
>
> Key: CASSANDRA-12935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12935
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Minor
> Fix For: 2.2.9, 3.0.11, 4.0, 3.11
>
>
> The introduction of {{StorageService.finishJoiningRing()}} on CASSANDRA-8523:
> {code:java}
> @@ -885,17 +896,14 @@ public class StorageService extends
> NotificationBroadcasterSupport implements IE
> {
> if (dataAvailable)
> {
> -// start participating in the ring.
> -
> SystemKeyspace.setBootstrapState(SystemKeyspace.BootstrapState.COMPLETED);
> -setTokens(bootstrapTokens);
> +finishJoiningRing();
> +
> // remove the existing info about the replaced node.
> if (!current.isEmpty())
> {
> for (InetAddress existing : current)
> Gossiper.instance.replacedEndpoint(existing);
> }
> -assert tokenMetadata.sortedTokens().size() > 0;
> -doAuthSetup();
> }
> else
> {
> @@ -908,6 +916,11 @@ public class StorageService extends
> NotificationBroadcasterSupport implements IE
> else if (isSurveyMode)
> {
> -setTokens(SystemKeyspace.getSavedTokens());
> -
> SystemKeyspace.setBootstrapState(SystemKeyspace.BootstrapState.COMPLETED);
> isSurveyMode = false;
> logger.info("Leaving write survey mode and joining ring at
> operator request");
> -assert tokenMetadata.sortedTokens().size() > 0;
> -
> -doAuthSetup();
> +finishJoiningRing();
> }
> }
>
> +private void finishJoiningRing()
> +{
> +// start participating in the ring.
> +
> SystemKeyspace.setBootstrapState(SystemKeyspace.BootstrapState.COMPLETED);
> +setTokens(bootstrapTokens);
> +
> +assert tokenMetadata.sortedTokens().size() > 0;
> +doAuthSetup();
> +}
> +
> {code}
> slightly changed the way tokens are set on {{StorageService.joinRing()}} when
> {{cassandra.write_survey=true}} from
> {{setTokens(SystemKeyspace.getSavedTokens())}}
> to {{setTokens(bootstrapTokens)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12961) LCS needlessly checks for L0 STCS candidates multiple times
[
https://issues.apache.org/jira/browse/CASSANDRA-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702811#comment-15702811
]
Carl Yeksigian commented on CASSANDRA-12961:
I don't think we want to move this check outside of the loop, as we only want
to do STCS in L0 if we would otherwise do a compaction in a higher level - if
we have the space in L1, we would prefer to do a normal L0→L1 compaction
to bring sstables out of L0, not continue to compact them with each other in
L0. But, we should definitely short circuit this search after we've searched
for the STCS candidates once.
> LCS needlessly checks for L0 STCS candidates multiple times
> ---
>
> Key: CASSANDRA-12961
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12961
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Jeff Jirsa
>Priority: Trivial
> Labels: lhf
>
> It's very likely that the check for L0 STCS candidates (if L0 is falling
> behind) can be moved outside of the loop, or at very least made so that it's
> not called on each loop iteration:
> {code}
> for (int i = generations.length - 1; i > 0; i--)
> {
> List sstables = getLevel(i);
> if (sstables.isEmpty())
> continue; // mostly this just avoids polluting the debug log
> with zero scores
> // we want to calculate score excluding compacting ones
> Set sstablesInLevel = Sets.newHashSet(sstables);
> Set remaining = Sets.difference(sstablesInLevel,
> cfs.getTracker().getCompacting());
> double score = (double) SSTableReader.getTotalBytes(remaining) /
> (double)maxBytesForLevel(i, maxSSTableSizeInBytes);
> logger.trace("Compaction score for level {} is {}", i, score);
> if (score > 1.001)
> {
> // before proceeding with a higher level, let's see if L0 is
> far enough behind to warrant STCS
> CompactionCandidate l0Compaction =
> getSTCSInL0CompactionCandidate();
> if (l0Compaction != null)
> return l0Compaction;
> ..
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12443) Remove alter type support
[ https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702437#comment-15702437 ] Carl Yeksigian commented on CASSANDRA-12443: After talking offline, [~blerer]'s intended comment was that we just leave the 3.0 CQL version the same, but include this fix. Since there are knock-on bugs from leaving the alter support in place, it makes sense for this to go into a bug-fix only version. So, I've pushed up the 3.0 branch again, and rebased the 3.x and trunk branches: ||3.0|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/3.0]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.0-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.0-dtest/]| ||3.x|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/3.x-1]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.x-1-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.x-1-dtest/]| ||trunk|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/trunk-1]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-trunk-1-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-trunk-1-dtest/]| > Remove alter type support > - > > Key: CASSANDRA-12443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian > Fix For: 3.x > > > Currently, we allow altering of types. However, because we no longer store > the length for all types anymore, switching from a fixed-width to > variable-width type causes issues. commitlog playback breaking startup, > queries currently in flight getting back bad results, and special casing > required to handle the changes. In addition, this would solve > CASSANDRA-10309, as there is no possibility of the types changing while an > SSTableReader is open. > For fixed-length, compatible types, the alter also doesn't add much over a > cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12535) Occasionally seeing AccessControlException, CodecNotFoundException when executing a User Defined Aggregate
[
https://issues.apache.org/jira/browse/CASSANDRA-12535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645102#comment-15645102
]
Carl Yeksigian commented on CASSANDRA-12535:
Maybe if we retry the function if we get a {{SecurityException}} would be the
best course of action for this. It seems like this is a low enough occurrence
that if we haven't had any UDF failures, retrying won't add significant
overhead; if we have had recent failures (which might point to a bad UDF), then
we could fail right away.
If that doesn't seem feasible, I think we should commit this patch, as it will
suppress the biggest source of {{SecurityException}}s. I'm +1 on the code
changes here.
> Occasionally seeing AccessControlException, CodecNotFoundException when
> executing a User Defined Aggregate
> --
>
> Key: CASSANDRA-12535
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12535
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.7 (via brew install), Mac OS X 10.11.6
>Reporter: Pat Patterson
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> I have defined a UDA to implement standard deviation:
> {noformat}
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdState ( state
> tuple, val double ) CALLED ON NULL INPUT RETURNS
> tuple LANGUAGE java AS
> ... 'int n = state.getInt(0); double mean = state.getDouble(1); double m2 =
> state.getDouble(2); n++; double delta = val - mean; mean += delta / n; m2 +=
> delta * (val - mean); state.setInt(0, n); state.setDouble(1, mean);
> state.setDouble(2, m2); return state;';
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdFinal ( state
> tuple ) CALLED ON NULL INPUT RETURNS double LANGUAGE java
> AS
> ... 'int n = state.getInt(0); double m2 = state.getDouble(2); if (n < 1) {
> return null; } return Math.sqrt(m2 / (n - 1));';
> cqlsh:mykeyspace> CREATE AGGREGATE IF NOT EXISTS stdev ( double )
> ... SFUNC sdState STYPE tuple FINALFUNC sdFinal INITCOND
> (0,0,0);
> {noformat}
> My table:
> {noformat}
> CREATE TABLE readings (
> sensor_id int,
> time timestamp,
> temperature double,
> status text,
> PRIMARY KEY (sensor_id, time)
> ) WITH CLUSTERING ORDER BY (time ASC);
> {noformat}
> I'm inserting a row every 0.1 seconds. The data looks like this:
> {noformat}
> cqlsh:mykeyspace> select * from readings limit 10;
> sensor_id | time| status | temperature
> ---+-++-
> 5 | 2016-08-24 19:11:34.896000+ | OK |9.97
> 5 | 2016-08-24 19:11:43.933000+ | OK | 10.28
> 5 | 2016-08-24 19:11:49.958000+ | OK |7.65
> 5 | 2016-08-24 19:11:51.968000+ | OK | 10.11
> 5 | 2016-08-24 19:12:58.512000+ | Fault | 10.41
> 5 | 2016-08-24 19:13:04.542000+ | OK |9.66
> 5 | 2016-08-24 19:13:16.593000+ | OK |10.9
> 5 | 2016-08-24 19:13:37.692000+ | OK |11.2
> 5 | 2016-08-24 19:13:46.738000+ | OK | 10.34
> 5 | 2016-08-24 19:13:49.757000+ | OK |10.6
> {noformat}
> I'm running a query every few seconds with my UDA - like this (timestamps are
> different each time):
> {noformat}
> select avg(temperature), stdev(temperature) from readings where sensor_id = 1
> and time > 1472066523193;
> {noformat}
> Most of the time, this works just fine:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings
> where sensor_id = 1 and time > 1472066523193;
> system.avg(temperature) | mykeyspace.stdev(temperature)
> -+---
> 9.9291 | 0.94179
> (1 rows)
> {noformat}
> But, occasionally, it fails with one of two exceptions:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings
> where sensor_id = 1 and time > 1472066523193;
> Traceback (most recent call last):
> File "/usr/local/Cellar/cassandra/3.7/libexec/bin/cqlsh.py", line 1277, in
> perform_simple_statement
> result = future.result()
> File "cassandra/cluster.py", line 3629, in
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369)
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'mykeyspace.sdstate[frozen>,
> double]' failed: java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/usr/local/etc/cassandra/logback.xml" "read")"
> {noformat}
> or
> {noformat}
> cqlsh:mykeyspace> select
[jira] [Updated] (CASSANDRA-12443) Remove alter type support
[ https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12443: --- Fix Version/s: (was: 3.0.x) 3.x Status: Patch Available (was: Open) There was a failure from the UDT changes; the rest seem more related to the fact that this hasn't been rebased in awhile. In order to seperate that out, I've added the commit fixing the test onto the branches above, but pushed new branches which have been rebased to test: ||3.x|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/3.x-1]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.x-1-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.x-1-dtest/]| ||trunk|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/trunk-1]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-trunk-1-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-trunk-1-dtest/]| > Remove alter type support > - > > Key: CASSANDRA-12443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian > Fix For: 3.x > > > Currently, we allow altering of types. However, because we no longer store > the length for all types anymore, switching from a fixed-width to > variable-width type causes issues. commitlog playback breaking startup, > queries currently in flight getting back bad results, and special casing > required to handle the changes. In addition, this would solve > CASSANDRA-10309, as there is no possibility of the types changing while an > SSTableReader is open. > For fixed-length, compatible types, the alter also doesn't add much over a > cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11865) Improve compaction logging details
[
https://issues.apache.org/jira/browse/CASSANDRA-11865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644189#comment-15644189
]
Carl Yeksigian commented on CASSANDRA-11865:
[~weideng]: This ticket is focused on adding new content to the
{{compaction.log}}, not necessarily focused on the current debug logging.
Some of this data is already available, like the merge statistics, and most of
the other data can be obtained using the {{MergeListener}}. For example,
figuring out the number of merged CQL rows, as well as the merged tombstones.
The wide partition detection is done inside of {{BigTableWriter}}, so that will
be more difficult to pull out, but we could probably get the same thing from
going through {{CompactionAwareWriter}} instead of the {{BigTableWriter}}.
Metrics we already collect
* Partitions Processed: {{totalKeysWritten}} in {{CompactionTask}}
* Partition Merge Stats: {{mergedRowCounts}} in {{CompactionTask}}
* Partition Size: {{mean}} in {{StatsMetadata}} from the output SSTables
Metrics we need to collect
* Adding in {{MergeListener}} in {{CompactionIterator}}
** Rows Processed
** Rows Merged
** Row count min/max/avg per partition
** Cells Requiring Merge
** Number of Tombstones Encountered
* {{BigTableWriter}}/{{CompactionAwareWriter}}
** Wide row
> Improve compaction logging details
> --
>
> Key: CASSANDRA-11865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11865
> Project: Cassandra
> Issue Type: Sub-task
> Components: Compaction
>Reporter: T Jake Luciani
>Assignee: Carl Yeksigian
>
> I'd like to see per compaction entry:
> * Partitions processed
> * Rows processed
> * Partition merge stats
> * If a wide row was detected
> * The partition min/max/avg size
> * The min/max/avg row count across partitions
> Anything else [~krummas]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12443) Remove alter type support
[ https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12443: --- Status: Open (was: Patch Available) Going to cancel this patch since there are some errors after a cleaner test run, and I want to look to ensure they aren't related to this. > Remove alter type support > - > > Key: CASSANDRA-12443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian > Fix For: 3.0.x > > > Currently, we allow altering of types. However, because we no longer store > the length for all types anymore, switching from a fixed-width to > variable-width type causes issues. commitlog playback breaking startup, > queries currently in flight getting back bad results, and special casing > required to handle the changes. In addition, this would solve > CASSANDRA-10309, as there is no possibility of the types changing while an > SSTableReader is open. > For fixed-length, compatible types, the alter also doesn't add much over a > cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12184) incorrect compaction log information on totalSourceRows in C* pre-3.8 versions
[
https://issues.apache.org/jira/browse/CASSANDRA-12184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12184:
---
Status: Patch Available (was: Open)
Was down to an issue with a refactoring.
Just pushed a branch with a fix to capture that when merging the partition
counts. Based off of how {{CompactionTask}} looked before the commit in
[910170c|https://github.com/apache/cassandra/commit/910170c9d10bb6a71922a529b2f070cf27891a10#diff-1e6aa904a845e633b3a7d9693fc6bee5L264].
||3.0|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12184/3.0]|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12184-3.0-testall/]|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12184-3.0-dtest/]|
> incorrect compaction log information on totalSourceRows in C* pre-3.8 versions
> --
>
> Key: CASSANDRA-12184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12184
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction, Observability
>Reporter: Wei Deng
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 3.0.x
>
>
> I was looking at some confusing compaction log information on C* 3.0.7 and
> realized that we have a bug that was trivially fixed in C* 3.8.
> Basically here is the log entry in debug.log (as most of the compaction
> related log have been moved to debug.log due to adjustment in
> CASSANDRA-10241).
> {noformat}
> DEBUG [CompactionExecutor:6] 2016-07-12 15:38:28,471 CompactionTask.java:217
> - Compacted (96aa1ba6-4846-11e6-adb7-17866fa8ddfd) 4 sstables to
> [/var/lib/cassandra/data/keyspace1/standard1-713f7920484411e6adb717866fa8ddfd/mb-5-big,]
> to level=0. 267,974,735 bytes to 78,187,400 (~29% of original) in 39,067ms
> = 1.908652MB/s. 0 total partitions merged to 332,904. Partition merge
> counts were {1:9008, 2:34822, 3:74505, 4:214569, }
> DEBUG [CompactionExecutor:4] 2016-07-12 20:51:56,578 CompactionTask.java:217
> - Compacted (786cd9d0-4872-11e6-8755-79a37e6d8141) 4 sstables to
> [/var/lib/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/mb-25-big,]
> to level=0. 620 bytes to 498 (~80% of original) in 51ms = 0.009312MB/s. 0
> total partitions merged to 6. Partition merge counts were {1:4, 3:2, }
> DEBUG [CompactionExecutor:4] 2016-07-12 20:51:58,345 CompactionTask.java:217
> - Compacted (79771de0-4872-11e6-8755-79a37e6d8141) 4 sstables to
> [/var/lib/cassandra/data/system_schema/columns-24101c25a2ae3af787c1b40ee1aca33f/mb-65-big,]
> to level=0. 14,113 bytes to 9,553 (~67% of original) in 70ms =
> 0.130149MB/s. 0 total partitions merged to 16. Partition merge counts were
> {1:13, 2:2, 3:1, }
> DEBUG [CompactionExecutor:3] 2016-07-12 20:52:00,415 CompactionTask.java:217
> - Compacted (7ab6a2c0-4872-11e6-8755-79a37e6d8141) 4 sstables to
> [/var/lib/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/mb-85-big,]
> to level=0. 1,066 bytes to 611 (~57% of original) in 48ms = 0.012139MB/s.
> 0 total partitions merged to 16. Partition merge counts were {1:13, 2:2,
> 4:1, }
> DEBUG [CompactionExecutor:4] 2016-07-12 20:52:00,442 CompactionTask.java:217
> - Compacted (7abae880-4872-11e6-8755-79a37e6d8141) 4 sstables to
> [/var/lib/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-77-big,]
> to level=0. 6,910 bytes to 4,396 (~63% of original) in 48ms = 0.087341MB/s.
> 0 total partitions merged to 16. Partition merge counts were {1:13, 2:2,
> 3:1, }
> {noformat}
> Note no matter if it's system table or user table, it's always showing "0
> total partitions merged to xx", which is incorrect information due to this
> code segment
> https://github.com/apache/cassandra/blob/cassandra-3.0.7/src/java/org/apache/cassandra/db/compaction/CompactionTask.java#L215-217.
> Basically it only initialized the totalSourceRows value with 0 and never
> assigned a real calculated value to it. Looks like the latest
> [commit|https://github.com/tjake/cassandra/blob/dc2951d1684777cf70aab401515d755699af99bc/src/java/org/apache/cassandra/db/compaction/CompactionTask.java#L225-226]
> from CASSANDRA-12080 fixed this problem, but it only got checked into 3.8
> branch.
> Since this can make people doubt the accuracy of compaction related log
> entries, and the changes made in CASSANDRA-12080 are only log metrics
> related, low impact changes, I'd advocate we backport the change from
> CASSANDRA-12080 into C*-3.0 branch as many people's production C*-3.0 version
> can benefit from the bug fix, along with better compaction log information in
> general. I realize that CASSANDRA-12080 may be based on the C*-3.6 changes in
> CASSANDRA-10805, so this means we may have to bring
[jira] [Commented] (CASSANDRA-12443) Remove alter type support
[ https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622395#comment-15622395 ] Carl Yeksigian commented on CASSANDRA-12443: [~iamaleksey]: Yup, good catch; I've removed that as well. [~blerer]: I updated the 3.x/trunk branches and pushed again. Just kicked off new CI tests, will update once they are done. > Remove alter type support > - > > Key: CASSANDRA-12443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian > Fix For: 3.0.x > > > Currently, we allow altering of types. However, because we no longer store > the length for all types anymore, switching from a fixed-width to > variable-width type causes issues. commitlog playback breaking startup, > queries currently in flight getting back bad results, and special casing > required to handle the changes. In addition, this would solve > CASSANDRA-10309, as there is no possibility of the types changing while an > SSTableReader is open. > For fixed-length, compatible types, the alter also doesn't add much over a > cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6696) Partition sstables by token range
[ https://issues.apache.org/jira/browse/CASSANDRA-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-6696: -- Component/s: Compaction > Partition sstables by token range > - > > Key: CASSANDRA-6696 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6696 > Project: Cassandra > Issue Type: Improvement > Components: Compaction >Reporter: sankalp kohli >Assignee: Marcus Eriksson > Labels: compaction, correctness, dense-storage, doc-impacting, > jbod-aware-compaction, lcs, performance > Fix For: 3.2, 3.3 > > > In JBOD, when someone gets a bad drive, the bad drive is replaced with a new > empty one and repair is run. > This can cause deleted data to come back in some cases. Also this is true for > corrupt stables in which we delete the corrupt stable and run repair. > Here is an example: > Say we have 3 nodes A,B and C and RF=3 and GC grace=10days. > row=sankalp col=sankalp is written 20 days back and successfully went to all > three nodes. > Then a delete/tombstone was written successfully for the same row column 15 > days back. > Since this tombstone is more than gc grace, it got compacted in Nodes A and B > since it got compacted with the actual data. So there is no trace of this row > column in node A and B. > Now in node C, say the original data is in drive1 and tombstone is in drive2. > Compaction has not yet reclaimed the data and tombstone. > Drive2 becomes corrupt and was replaced with new empty drive. > Due to the replacement, the tombstone in now gone and row=sankalp col=sankalp > has come back to life. > Now after replacing the drive we run repair. This data will be propagated to > all nodes. > Note: This is still a problem even if we run repair every gc grace. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8805) runWithCompactionsDisabled only cancels compactions, which is not the only source of markCompacted
[ https://issues.apache.org/jira/browse/CASSANDRA-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-8805: -- Component/s: Compaction > runWithCompactionsDisabled only cancels compactions, which is not the only > source of markCompacted > -- > > Key: CASSANDRA-8805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8805 > Project: Cassandra > Issue Type: Bug > Components: Compaction >Reporter: Benedict >Assignee: Carl Yeksigian > Fix For: 2.1.13, 2.2.5, 3.0.3, 3.2 > > Attachments: 8805-2.1.txt > > > Operations like repair that may operate over all sstables cancel compactions > before beginning, and fail if there are any files marked compacting after > doing so. Redistribution of index summaries is not a compaction, so is not > cancelled by this action, but does mark sstables as compacting, so such an > action will fail to initiate if there is an index summary redistribution in > progress. It seems that IndexSummaryManager needs to register itself as > interruptible along with compactions (AFAICT no other actions that may > markCompacting are not themselves compactions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10863) HSHA test_closing_connections test still flaps on 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-10863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-10863: --- Component/s: Testing > HSHA test_closing_connections test still flaps on 3.0 > - > > Key: CASSANDRA-10863 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10863 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Jim Witschey >Assignee: Carl Yeksigian > Fix For: 3.0.3 > > > The problem reported in CASSANDRA-10570 still seems to be happening on > CassCI, as recently as a couple days ago: > http://cassci.datastax.com/job/cassandra-3.0_dtest/433/ > [~carlyeks] The fix in #10570 was to increase how long we'd sleep in the > tests. Should we just bump it up further, or does this make you suspect a > larger problem here? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10829) cleanup + repair generates a lot of logs
[ https://issues.apache.org/jira/browse/CASSANDRA-10829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-10829: --- Component/s: Streaming and Messaging > cleanup + repair generates a lot of logs > > > Key: CASSANDRA-10829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10829 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging > Environment: 5 nodes on Cassandra 2.1.11 (on Debian) >Reporter: Fabien Rousseau >Assignee: Marcus Eriksson > Fix For: 2.1.13, 2.2.5, 3.0.3, 3.3 > > > One of our node generates a lot of cassandra logs (int the 10 MB/s) and CPU > usage has increased (by a factor 2-3). > This was most probably triggered by a "nodetool snapshot" while a cleanup was > already running on this node. > An example of those logs: > 2015-12-08 09:15:17,794 INFO > [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to > capture released readers [...] > 2015-12-08 09:15:17,794 INFO > [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to > capture all readers [...] > 2015-12-08 09:15:17,795 INFO > [ValidationExecutor:689]ColumnFamilyStore.java:1923 Spinning trying to > capture released readers [...] > 2015-12-08 09:15:17,795 INFO > [ValidationExecutor:689]ColumnFamilyStore.java:1924 Spinning trying to > capture all readers [...] > (I removed SSTableReader information because it's rather long... I can share > it privately if needed) > Note that the date has not been changed (only 1ms between logs) > It should not generate that gigantic amount of logs :) > This is probably linked to: > https://issues.apache.org/jira/browse/CASSANDRA-9637 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10795) Improve Failure Detector Unknown EP message
[ https://issues.apache.org/jira/browse/CASSANDRA-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-10795: --- Component/s: Observability > Improve Failure Detector Unknown EP message > --- > > Key: CASSANDRA-10795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10795 > Project: Cassandra > Issue Type: Improvement > Components: Observability >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie >Priority: Minor > Fix For: 3.2 > > Attachments: trunk-10795-2.txt, trunk-10795.txt > > > When the failure detector is asked whether an unknown endpoint is alive, it > prints an uninformative error message. This patch adds a stack trace to the > print statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10652) Tracing prevents startup after upgrading
[
https://issues.apache.org/jira/browse/CASSANDRA-10652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-10652:
---
Component/s: Observability
> Tracing prevents startup after upgrading
>
>
> Key: CASSANDRA-10652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10652
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
>Reporter: Carl Yeksigian
>Assignee: Sylvain Lebresne
>Priority: Blocker
> Fix For: 2.2.4, 3.0.0
>
>
> After upgrading from 2.1 to 3.0, the {{system_traces.sessions}} table is not
> properly upgraded to include the {{client}} column added in CASSANDRA-8162.
> Just upgrading from a clean 2.2 install to 3.0 won't show this error because
> the column was included in 2.2, it just doesn't break the queries in that
> release.
> The errors I get when querying {{system_traces.sessions}}:
> {noformat}
> java.lang.RuntimeException: java.lang.IllegalStateException:
> [ColumnDefinition{name=client,
> type=org.apache.cassandra.db.marshal.InetAddressType, kind=REGULAR,
> position=-1}, ColumnDefinition{name=command,
> type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=coordinator,
> type=org.apache.cassandra.db.marshal.InetAddressType, kind=REGULAR,
> position=-1}, ColumnDefinition{name=duration,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=request, type=org.apache.cassandra.db.marshal.UTF8Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=started_at,
> type=org.apache.cassandra.db.marshal.TimestampType, kind=REGULAR,
> position=-1}, ColumnDefinition{name=parameters,
> type=org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type),
> kind=REGULAR, position=-1}] is not a subset of [coordinator duration request
> started_at parameters]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2350)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_45]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> Caused by: java.lang.IllegalStateException: [ColumnDefinition{name=client,
> type=org.apache.cassandra.db.marshal.InetAddressType, kind=REGULAR,
> position=-1}, ColumnDefinition{name=command,
> type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=coordinator,
> type=org.apache.cassandra.db.marshal.InetAddressType, kind=REGULAR,
> position=-1}, ColumnDefinition{name=duration,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=request, type=org.apache.cassandra.db.marshal.UTF8Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=started_at,
> type=org.apache.cassandra.db.marshal.TimestampType, kind=REGULAR,
> position=-1}, ColumnDefinition{name=parameters,
> type=org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type),
> kind=REGULAR, position=-1}] is not a subset of [coordinator duration request
> started_at parameters]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:531)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:465)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:178)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:96)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[main/:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:298)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataRe
[jira] [Updated] (CASSANDRA-10909) NPE in ActiveRepairService
[
https://issues.apache.org/jira/browse/CASSANDRA-10909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-10909:
---
Component/s: Streaming and Messaging
> NPE in ActiveRepairService
> ---
>
> Key: CASSANDRA-10909
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10909
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Environment: cassandra-3.0.1.777
>Reporter: Eduard Tudenhoefner
>Assignee: Marcus Eriksson
> Fix For: 2.1.13, 2.2.5, 3.0.3, 3.3
>
>
> NPE after one started multiple incremental repairs
> {code}
> INFO [Thread-62] 2015-12-21 11:40:53,742 RepairRunnable.java:125 - Starting
> repair command #1, repairing keyspace keyspace1 with repair options
> (parallelism: parallel, primary range: false, incremental: true, job threads:
> 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of ranges: 2)
> INFO [Thread-62] 2015-12-21 11:40:53,813 RepairSession.java:237 - [repair
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] new session: will sync /10.200.177.32,
> /10.200.177.33 on range [(10,-9223372036854775808]] for keyspace1.[counter1,
> standard1]
> INFO [Repair#1:1] 2015-12-21 11:40:53,853 RepairJob.java:100 - [repair
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] requesting merkle trees for counter1
> (to [/10.200.177.33, /10.200.177.32])
> INFO [Repair#1:1] 2015-12-21 11:40:53,853 RepairJob.java:174 - [repair
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] Requesting merkle trees for counter1
> (to [/10.200.177.33, /10.200.177.32])
> INFO [Thread-62] 2015-12-21 11:40:53,854 RepairSession.java:237 - [repair
> #b1449fe0-a7d7-11e5-b568-f565b837eb0d] new session: will sync /10.200.177.32,
> /10.200.177.31 on range [(0,10]] for keyspace1.[counter1, standard1]
> INFO [AntiEntropyStage:1] 2015-12-21 11:40:53,896 RepairSession.java:181 -
> [repair #b13e3740-a7d7-11e5-b568-f565b837eb0d] Received merkle tree for
> counter1 from /10.200.177.32
> INFO [AntiEntropyStage:1] 2015-12-21 11:40:53,906 RepairSession.java:181 -
> [repair #b13e3740-a7d7-11e5-b568-f565b837eb0d] Received merkle tree for
> counter1 from /10.200.177.33
> INFO [Repair#1:1] 2015-12-21 11:40:53,906 RepairJob.java:100 - [repair
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] requesting merkle trees for standard1
> (to [/10.200.177.33, /10.200.177.32])
> INFO [Repair#1:1] 2015-12-21 11:40:53,906 RepairJob.java:174 - [repair
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] Requesting merkle trees for standard1
> (to [/10.200.177.33, /10.200.177.32])
> INFO [RepairJobTask:2] 2015-12-21 11:40:53,910 SyncTask.java:66 - [repair
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] Endpoints /10.200.177.33 and
> /10.200.177.32 are consistent for counter1
> INFO [RepairJobTask:1] 2015-12-21 11:40:53,910 RepairJob.java:145 - [repair
> #b13e3740-a7d7-11e5-b568-f565b837eb0d] counter1 is fully synced
> INFO [AntiEntropyStage:1] 2015-12-21 11:40:54,823 Validator.java:272 -
> [repair #b17a2ed0-a7d7-11e5-ada8-8304f5629908] Sending completed merkle tree
> to /10.200.177.33 for keyspace1.counter1
> ERROR [ValidationExecutor:3] 2015-12-21 11:40:55,104
> CompactionManager.java:1065 - Cannot start multiple repair sessions over the
> same sstables
> ERROR [ValidationExecutor:3] 2015-12-21 11:40:55,105 Validator.java:259 -
> Failed creating a merkle tree for [repair
> #b17a2ed0-a7d7-11e5-ada8-8304f5629908 on keyspace1/standard1,
> [(10,-9223372036854775808]]], /10.200.177.33 (see log for details)
> ERROR [ValidationExecutor:3] 2015-12-21 11:40:55,110
> CassandraDaemon.java:195 - Exception in thread
> Thread[ValidationExecutor:3,1,main]
> java.lang.RuntimeException: Cannot start multiple repair sessions over the
> same sstables
> at
> org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1066)
> ~[cassandra-all-3.0.1.777.jar:3.0.1.777]
> at
> org.apache.cassandra.db.compaction.CompactionManager.access$700(CompactionManager.java:80)
> ~[cassandra-all-3.0.1.777.jar:3.0.1.777]
> at
> org.apache.cassandra.db.compaction.CompactionManager$10.call(CompactionManager.java:679)
> ~[cassandra-all-3.0.1.777.jar:3.0.1.777]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
> ERROR [AntiEntropyStage:1] 2015-12-21 11:40:55,174
> RepairMessageVerbHandler.java:161 - Got error, removing parent repair session
> INFO [CompactionExecutor:3] 2015-12-21 11:40:55,175
> CompactionManager.java:489 - Starting anticompaction for keyspac
[jira] [Updated] (CASSANDRA-10991) Cleanup OpsCenter keyspace fails - node thinks that didn't joined the ring yet
[
https://issues.apache.org/jira/browse/CASSANDRA-10991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-10991:
---
Component/s: Observability
> Cleanup OpsCenter keyspace fails - node thinks that didn't joined the ring yet
> --
>
> Key: CASSANDRA-10991
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10991
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
> Environment: C* 2.1.12, Debian Wheezy
>Reporter: mlowicki
>Assignee: Marcus Eriksson
> Fix For: 2.2.6, 3.0.4, 3.4
>
>
> I've C* cluster spread across 3 DCs. Running {{cleanup}} on all nodes in one
> DC always fails:
> {code}
> root@db1:~# nt cleanup system
> root@db1:~# nt cleanup sync
> root@db1:~# nt cleanup OpsCenter
> Aborted cleaning up atleast one column family in keyspace OpsCenter, check
> server logs for more information.
> error: nodetool failed, check server logs
> -- StackTrace --
> java.lang.RuntimeException: nodetool failed, check server logs
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:292)
> at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:204)
> root@db1:~#
> {code}
> Checked two other DCs and running cleanup there works fine (it didn't fail
> immediately).
> Output from {{nodetool status}} from one node in problematic DC:
> {code}
> root@db1:~# nt status
> Datacenter: Amsterdam
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens OwnsHost ID
> Rack
> UN 10.210.3.162 518.54 GB 256 ?
> 50e606f5-e893-4a3b-86d3-1e5986dceea9 RAC1
> UN 10.210.3.230 532.63 GB 256 ?
> 7b8fc988-8a6a-4d94-ae84-ab9da9ab01e8 RAC1
> UN 10.210.3.161 538.82 GB 256 ?
> d44b0f6d-7933-4a7c-ba7b-f8648e038f85 RAC1
> UN 10.210.3.160 497.6 GB 256 ?
> e7332179-a47e-471d-bcd4-08c638ab9ea4 RAC1
> UN 10.210.3.224 334.25 GB 256 ?
> 92b0bd8c-0a5a-446a-83ea-2feea4988fe3 RAC1
> UN 10.210.3.118 518.34 GB 256 ?
> ebddeaf3-1433-4372-a4ca-9c7ba3d4a26b RAC1
> UN 10.210.3.221 516.57 GB 256 ?
> 44d67a49-5310-4ab5-b448-a44be350abf5 RAC1
> UN 10.210.3.117 493.83 GB 256 ?
> aae92956-82d6-421e-8f3f-22393ac7e5f7 RAC1
> Datacenter: Analytics
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens OwnsHost ID
> Rack
> UN 10.210.59.124 392.83 GB 320 ?
> f770a8cc-b7bf-44ac-8cc0-214d9228dfcd RAC1
> UN 10.210.59.151 411.9 GB 320 ?
> 3cc87422-0e43-4cd1-91bf-484f121be072 RAC1
> UN 10.210.58.132 309.8 GB 256 ?
> 84d94d13-28d3-4b49-a3d9-557ab47e79b9 RAC1
> UN 10.210.58.133 281.82 GB 256 ?
> 02bd2d02-41c5-4193-81b0-dee434adb0da RAC1
> UN 10.210.59.86 285.84 GB 256 ?
> bc6422ea-22e9-431a-ac16-c4c040f0c4e5 RAC1
> UN 10.210.59.84 331.06 GB 256 ?
> a798e6b0-3a84-4ec2-82bb-8474086cb315 RAC1
> UN 10.210.59.85 366.26 GB 256 ?
> 52699077-56cf-4c1e-b308-bf79a1644b7e RAC1
> Datacenter: Ashburn
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens OwnsHost ID
> Rack
> UN 10.195.15.176 534.51 GB 256 ?
> c6ac22df-c43a-4b25-b3b5-5e12ce9c69da RAC1
> UN 10.195.15.177 313.73 GB 256 ?
> eafa2a72-84a2-4cdc-a634-3c660acc6af8 RAC1
> UN 10.195.15.163 470.92 GB 256 ?
> bcd2a534-94c4-4406-8d16-c1fc26b41844 RAC1
> UN 10.195.15.162 539.82 GB 256 ?
> bb649cef-21de-4077-a35f-994319011a06 RAC1
> UN 10.195.15.182 499.64 GB 256 ?
> 6ce2d14d-9fb8-4494-8e97-3add05bd35de RAC1
> UN 10.195.15.167 508.48 GB 256 ?
> 6f359675-852a-4842-9ff2-bdc69e6b04a2 RAC1
> UN 10.195.15.166 490.28 GB 256 ?
> 1ec5d0c5-e8bd-4973-96d9-523de91d08c5 RAC1
> UN 10.195.15.183 447.78 GB 256 ?
> 824165b0-1f1b-40e8-9695-e2f596cb8611 RAC1
> Note: Non-system keyspaces don't have the same replication settings,
> effective ownership information is meaningless
> {code}
> Logs from one of the nodes where {{cleanup}} fails:
> {code}
> INFO [RMI TCP Connection(158004)-10.210.59.86] 2016-01-09 15:58:33,942
> CompactionManager.java:388 - Cleanup cannot run before a node has joined the
> ring
> INFO [RMI TCP Connection(158004)-10.210.59.86] 2016-01-09 15:58:33,970
> CompactionManager.java:388 - Cleanup cannot run before a node has joined the
> ring
> INFO [RMI TCP Connection(158004)-10.210.59.86] 2016-01-09 15:58:34,000
> CompactionManager.java:388 - Cleanup
[jira] [Updated] (CASSANDRA-10910) Materialized view remained rows
[
https://issues.apache.org/jira/browse/CASSANDRA-10910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-10910:
---
Component/s: Coordination
> Materialized view remained rows
> ---
>
> Key: CASSANDRA-10910
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10910
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
> Environment: Cassandra 3.0.0
>Reporter: Gábor Auth
>Assignee: Carl Yeksigian
> Fix For: 3.0.3, 3.3
>
>
> I've created a table and a materialized view.
> {code}
> > CREATE TABLE test (id text PRIMARY KEY, key text, value int);
> > CREATE MATERIALIZED VIEW test_view AS SELECT * FROM test WHERE key IS NOT
> > NULL PRIMARY KEY(key, id);
> {code}
> I've put a value into the table:
> {code}
> > update test set key='key', value=1 where id='id';
> > select * from test; select * from test_view ;
> id | key | value
> +-+---
> id | key | 1
> (1 rows)
> key | id | value
> -++---
> key | id | 1
> (1 rows)
> {code}
> I've updated the value without specified the key of the materialized view:
> {code}
> > update test set value=2 where id='id';
> > select * from test; select * from test_view ;
> id | key | value
> +-+---
> id | key | 2
> (1 rows)
> key | id | value
> -++---
> key | id | 2
> (1 rows)
> {code}
> It works as I think...
> ...but I've updated the key of the materialized view:
> {code}
> > update test set key='newKey' where id='id';
> > select * from test; select * from test_view ;
> id | key| value
> ++---
> id | newKey | 2
> (1 rows)
> key| id | value
> ++---
> key | id | 2
> newKey | id | 2
> (2 rows)
> {code}
> ...I've updated the value of the row:
> {code}
> > update test set key='newKey', value=3 where id='id';
> > select * from test; select * from test_view ;
> id | key| value
> ++---
> id | newKey | 3
> (1 rows)
> key| id | value
> ++---
> key | id | 2
> newKey | id | 3
> (2 rows)
> {code}
> ...I've deleted the row by the id key:
> {code}
> > delete from test where id='id';
> > select * from test; select * from test_view ;
> id | key | value
> +-+---
> (0 rows)
> key | id | value
> -++---
> key | id | 2
> (1 rows)
> {code}
> Is it a bug?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11151) Remove unused method introduced in CASSANDRA-6696
[
https://issues.apache.org/jira/browse/CASSANDRA-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11151:
---
Component/s: Compaction
> Remove unused method introduced in CASSANDRA-6696
> -
>
> Key: CASSANDRA-11151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11151
> Project: Cassandra
> Issue Type: Improvement
> Components: Compaction
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Minor
> Fix For: 3.4
>
>
> We introduced an abstract method {{finish(long repairedAt)}} in
> CompactionAwareWriter in CASSANDRA-6696 which we don't use, remove it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11602) Materialized View Does Not Have Static Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-11602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11602:
---
Component/s: Coordination
Summary: Materialized View Does Not Have Static Columns (was:
Materialized View Doest Not Have Static Columns)
> Materialized View Does Not Have Static Columns
> --
>
> Key: CASSANDRA-11602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11602
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
>Reporter: Ravishankar Rajendran
>Assignee: Carl Yeksigian
> Fix For: 3.0.6, 3.6
>
>
> {quote}
> CREATE TABLE "team" (teamname text, manager text, location text static,
> PRIMARY KEY ((teamname), manager));
> INSERT INTO team (teamname, manager, location) VALUES ('Red Bull1',
> 'Ricciardo11', 'Australian');
> INSERT INTO team (teamname, manager, location) VALUES ('Red Bull2',
> 'Ricciardo12', 'Australian');
> INSERT INTO team (teamname, manager, location) VALUES ('Red Bull2',
> 'Ricciardo13', 'Australian');
> select * From team;
> CREATE MATERIALIZED VIEW IF NOT EXISTS "teamMV" AS SELECT "teamname",
> "manager", "location" FROM "team" WHERE "teamname" IS NOT NULL AND "manager"
> is NOT NULL AND "location" is NOT NULL PRIMARY KEY("manager", "teamname");
> select * from "teamMV";
> {quote}
> The teamMV does not have "location" column. Static columns are not getting
> created in MV.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11069) Materialised views require all collections to be selected.
[
https://issues.apache.org/jira/browse/CASSANDRA-11069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11069:
---
Component/s: Coordination
> Materialised views require all collections to be selected.
> --
>
> Key: CASSANDRA-11069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11069
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
>Reporter: Vassil Lunchev
>Assignee: Carl Yeksigian
> Labels: materializedviews
> Fix For: 3.0.4, 3.4
>
>
> Running Cassandra 3.0.2
> Using the official example from:
> http://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views
> The only difference is that I have added a map column to the base table.
> {code}
> CREATE TABLE scores
> (
> user TEXT,
> game TEXT,
> year INT,
> month INT,
> day INT,
> score INT,
> a_map map,
> PRIMARY KEY (user, game, year, month, day)
> );
> CREATE MATERIALIZED VIEW alltimehigh AS
>SELECT user FROM scores
>WHERE game IS NOT NULL AND score IS NOT NULL AND user IS NOT NULL AND
> year IS NOT NULL AND month IS NOT NULL AND day IS NOT NULL
>PRIMARY KEY (game, score, user, year, month, day)
>WITH CLUSTERING ORDER BY (score desc);
> INSERT INTO scores (user, game, year, month, day, score) VALUES ('pcmanus',
> 'Coup', 2015, 06, 02, 2000);
> SELECT * FROM scores;
> SELECT * FROM alltimehigh;
> {code}
> All of the above works perfectly fine. Until you insert a row where the
> 'a_map' column is not null.
> {code}
> INSERT INTO scores (user, game, year, month, day, score, a_map) VALUES
> ('pcmanus_2', 'Coup', 2015, 06, 02, 2000, {1: 'text'});
> {code}
> This results in:
> {code}
> Traceback (most recent call last):
> File "/Users/vassil/apache-cassandra-3.0.2/bin/cqlsh.py", line 1258, in
> perform_simple_statement
> result = future.result()
> File
> "/Users/vassil/apache-cassandra-3.0.2/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
> line 3122, in result
> raise self._final_exception
> WriteFailure: code=1500 [Replica(s) failed to execute write]
> message="Operation failed - received 0 responses and 1 failures"
> info={'failures': 1, 'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}
> {code}
> Selecting the base table and the materialised view is also interesting:
> {code}
> SELECT * FROM scores;
> SELECT * FROM alltimehigh;
> {code}
> The result is:
> {code}
> cqlsh:tests> SELECT * FROM scores;
> user| game | year | month | day | a_map | score
> -+--+--+---+-+---+---
> pcmanus | Coup | 2015 | 6 | 2 | null | 2000
> (1 rows)
> cqlsh:tests> SELECT * FROM alltimehigh;
> game | score | user | year | month | day
> --+---+---+--+---+-
> Coup | 2000 | pcmanus | 2015 | 6 | 2
> Coup | 2000 | pcmanus_2 | 2015 | 6 | 2
> (2 rows)
> {code}
> In the logs you can see:
> {code:java}
> ERROR [SharedPool-Worker-2] 2016-01-26 03:25:27,456 Keyspace.java:484 -
> Unknown exception caught while attempting to update MaterializedView!
> tests.scores
> java.lang.IllegalStateException: [ColumnDefinition{name=a_map,
> type=org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.UTF8Type),
> kind=REGULAR, position=-1}] is not a subset of []
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:531)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
> at
> org.apache.cassandra.db.Columns$Serializer.serializedSubsetSize(Columns.java:483)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedRowBodySize(UnfilteredSerializer.java:275)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:247)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:234)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializedSize(UnfilteredSerializer.java:227)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serializedSize(UnfilteredRowIteratorSerializer.java:169)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
> at
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serializedSize(PartitionUpdate.java:683)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.serializedSize(Mutation.java:354)
> ~[apache-cassandra-3.0.2.jar:3.0.2]
>
[jira] [Updated] (CASSANDRA-11475) MV code refactor
[
https://issues.apache.org/jira/browse/CASSANDRA-11475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11475:
---
Component/s: Coordination
> MV code refactor
>
>
> Key: CASSANDRA-11475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11475
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.7, 3.7
>
>
> While working on CASSANDRA-5546 I run into a problem with TTLs on MVs, which
> looking more closely is a bug of the MV code. But one thing leading to
> another I reviewed a good portion of the MV code and found the following
> correction problems:
> * If a base row is TTLed then even if an update remove that TTL the view
> entry remained TTLed and expires, leading to an inconsistency.
> * Due to calling the wrong ctor for {{LivenessInfo}}, when a TTL was set on
> the base table, the view entry was living twice as long as the TTL. Again
> leading to a temporary inconsistency.
> * When reading existing data to compute view updates, all deletion
> informations are completely ignored (the code uses a {{PartitionIterator}}
> instead of an {{UnfilteredPartitionIterator}}). This is a serious issue since
> it means some deletions could be totally ignored as far as views are
> concerned especially when messages are delivered to a replica out of order.
> I'll note that while the 2 previous points are relatively easy to fix, I
> didn't find an easy and clean way to fix this one on the current code.
> Further, I think the MV code in general has inefficiencies/code complexities
> that should be avoidable:
> * {{TemporalRow.Set}} is buffering both everything read and a pretty much
> complete copy of the updates. That's a potentially high memory requirement.
> We shouldn't have to copy the updates and we shouldn't buffer all reads but
> rather work incrementally.
> * {{TemporalRow}}/{{TemporalRow.Set}}/{{TemporalCell}} classes are somewhat
> re-inventing the wheel. They are really just storing both an update we're
> doing and the corresponding existing data, but we already have
> {{Row}}/{{Partition}}/{{Cell}} for that. In practice, those {{Temporal*}}
> class generates a lot of allocations that we could avoid.
> * The code from CASSANDRA-10060 to avoid multiple reads of the base table
> with multiple views doesn't work when the update has partition/range
> tombstones because the code uses {{TemporalRow.Set.setTombstonedExisting()}}
> to trigger reuse, but the {{TemporalRow.Set.withNewViewPrimaryKey()}} method
> is used between view and it does not preseve the {{hasTombstonedExisting}}
> flag. But that oversight, which is trivial to fix, is kind of a good thing
> since if you fix it, you're left with a correction problem.
> The read done when there is a partition deletion depends on the view itself
> (if there is clustering filters in particular) and so reusing that read for
> other views is wrong. Which makes that whole reuse code really dodgy imo: the
> read for existing data is in {{View.java}}, suggesting that it depends on the
> view (which again, it does at least for partition deletion), but it shouldn't
> if we're going to reuse the result across multiple views.
> * Even ignoring the previous point, we still potentially read the base table
> twice if the update mix both row updates and partition/range deletions,
> potentially re-reading the same values.
> * It's probably more minor but the reading code is using {{QueryPager}},
> which is probably an artifact of the initial version of the code being
> pre-8099, but it's not necessary anymore (the reads are local and locally
> we're completely iterator based), adding, especially when we do page. I'll
> note that despite using paging, the current code still buffers everything in
> {{TemporalRow.Set}} anyway .
> Overall, I suspect trying to fix the problems above (particularly the fact
> that existing deletion infos are ignored) is only going to add complexity
> with the current code and we'd still have to fix the inefficiencies. So I
> propose a refactor of that code which does 2 main things:
> # it removes all of {{TemporalRow}} and related classes. Instead, it directly
> uses the existing {{Row}} (with all its deletion infos) and the update being
> applied to it and compute the updates for the view from that. I submit that
> this is more clear/simple, but this also avoid copying every cell of both the
> existing and update data as a {{TemporalCell}}. We can also reuse codes like
> {{Rows.merge}} and {{Rows.diff}} to make the handling of deletions relatively
> painless.
> # instead of dealing with each view one at a time, re-iterating over all
> updates each time, it iterates over each individual updates once an
[jira] [Updated] (CASSANDRA-11034) consistent_reads_after_move_test is failing on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11034:
---
Component/s: Testing
> consistent_reads_after_move_test is failing on trunk
>
>
> Key: CASSANDRA-11034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11034
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Philip Thompson
>Assignee: Marcus Eriksson
>Priority: Blocker
> Labels: dtest
> Fix For: 3.3
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log,
> node3.log, node3_debug.log
>
>
> The novnode dtest
> {{consistent_bootstrap_test.TestBootstrapConsistency.consistent_reads_after_move_test}}
> is failing on trunk. See an example failure
> [here|http://cassci.datastax.com/job/trunk_novnode_dtest/274/testReport/consistent_bootstrap_test/TestBootstrapConsistency/consistent_reads_after_move_test/].
> On trunk I am getting an OOM of one of my C* nodes [node3], which is what
> causes the nodetool move to fail. Logs are attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11988) NullPointerException when reading/compacting table
[
https://issues.apache.org/jira/browse/CASSANDRA-11988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11988:
---
Component/s: Compaction
Summary: NullPointerException when reading/compacting table (was:
NullPointerExpception when reading/compacting table)
> NullPointerException when reading/compacting table
> --
>
> Key: CASSANDRA-11988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11988
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Nimi Wariboko Jr.
>Assignee: Sylvain Lebresne
> Fix For: 3.0.9, 3.8
>
>
> I have a table that suddenly refuses to be read or compacted. Issuing a read
> on the table causes a NPE.
> On compaction, it returns the error
> {code}
> ERROR [CompactionExecutor:6] 2016-06-09 17:10:15,724 CassandraDaemon.java:213
> - Exception in thread Thread[CompactionExecutor:6,1,main]
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:64)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:24)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:76)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:264)
> ~[apache-cassandra-3.6.jar:3.6]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {code}
> Schema:
> {code}
> CREATE TABLE cmpayments.report_payments (
> reportid timeuuid,
> userid timeuuid,
> adjustedearnings decimal,
> deleted set static,
> earnings map,
> gross map,
> organizationid text,
> payall timestamp static,
> status text,
> PRIMARY KEY (reportid, userid)
> ) WITH CLUSTERING ORDER BY (userid 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.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> 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 = '99PERCENTILE';
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12413) CompactionsCQLTest.testTriggerMinorCompactionDTCS fails
[
https://issues.apache.org/jira/browse/CASSANDRA-12413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12413:
---
Component/s: Testing
> CompactionsCQLTest.testTriggerMinorCompactionDTCS fails
> ---
>
> Key: CASSANDRA-12413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12413
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Joshua McKenzie
>Assignee: Marcus Eriksson
> Labels: unittest
> Fix For: 3.10
>
>
> [Link|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testTriggerMinorCompactionDTCS/]
> Error Message
> No minor compaction triggered in 5000ms
> Stacktrace
> {noformat}
> junit.framework.AssertionFailedError: No minor compaction triggered in 5000ms
> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.waitForMinor(CompactionsCQLTest.java:247)
> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testTriggerMinorCompactionDTCS(CompactionsCQLTest.java:72)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11698) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11698:
---
Component/s: Testing
> dtest failure in
> materialized_views_test.TestMaterializedViews.clustering_column_test
> -
>
> Key: CASSANDRA-11698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11698
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Russ Hatch
>Assignee: Carl Yeksigian
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log,
> node3.log, node3_debug.log
>
>
> recent failure, test has flapped before a while back.
> {noformat}
> Expecting 2 users, got 1
> {noformat}
> http://cassci.datastax.com/job/cassandra-3.0_dtest/688/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test
> Failed on CassCI build cassandra-3.0_dtest #688
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12044) Materialized view definition regression in clustering key
[
https://issues.apache.org/jira/browse/CASSANDRA-12044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12044:
---
Component/s: CQL
> Materialized view definition regression in clustering key
> -
>
> Key: CASSANDRA-12044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12044
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Michael Mior
>Assignee: Carl Yeksigian
> Fix For: 3.0.9, 3.8
>
>
> This bug was reported on the
> [users|https://mail-archives.apache.org/mod_mbox/cassandra-user/201606.mbox/%3CCAG0vsSJRtRjLJqKsd3M8X-8nXpPwRj7Q80mNkuy8sy%2B%2B%3D%2BocHA%40mail.gmail.com%3E]
> mailing list. The following definitions work in 3.0.3 but fail in 3.0.7.
> {code}
> CREATE TABLE ks.pa (
> id bigint,
> sub_id text,
> name text,
> class text,
> r_id bigint,
> k_id bigint,
> created timestamp,
> priority int,
> updated timestamp,
> value text,
> PRIMARY KEY (id, sub_id, name)
> );
> CREATE ks.mv_pa AS
> SELECT k_id, name, value, sub_id, id, class, r_id
> FROM ks.pa
> WHERE k_id IS NOT NULL AND name IS NOT NULL AND value IS NOT NULL AND
> sub_id IS NOT NULL AND id IS NOT NULL
> PRIMARY KEY ((k_id, name), value, sub_id, id);
> {code}
> After running bisect, I've narrowed it down to commit
> [86ba227|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=86ba227477b9f8595eb610ecaf950cfbc29dd36b]
> from [CASSANDRA-11475|https://issues.apache.org/jira/browse/CASSANDRA-11475].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12247) AssertionError with MVs on updating a row that isn't indexed due to a null value
[ https://issues.apache.org/jira/browse/CASSANDRA-12247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12247: --- Component/s: Local Write-Read Paths > AssertionError with MVs on updating a row that isn't indexed due to a null > value > > > Key: CASSANDRA-12247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12247 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths > Environment: Linux, Ubuntu Xenial > openjdk-8-jre-headless:amd64 8u91-b14-0ubuntu4~16.04.1 >Reporter: Benjamin Roth >Assignee: Sylvain Lebresne >Priority: Critical > Fix For: 3.0.9, 3.8 > > > Complete steps to reproduce: > https://gist.github.com/brstgt/4c3269eaec50a7d4abac5690157b238c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12198) Deadlock in CDC during segment flush
[
https://issues.apache.org/jira/browse/CASSANDRA-12198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12198:
---
Component/s: Local Write-Read Paths
> Deadlock in CDC during segment flush
>
>
> Key: CASSANDRA-12198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12198
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Joshua McKenzie
>Assignee: Joshua McKenzie
>Priority: Blocker
> Fix For: 3.8
>
>
> In the patch for CASSANDRA-8844, we added a {{synchronized(this)}} block
> inside CommitLogSegment.setCDCState. This introduces the possibility of
> deadlock in the following scenario:
> # A {{CommitLogSegment.sync()}} call is made (synchronized method)
> # A {{CommitLogSegment.allocate}} call from a cdc-enabled write is in flight
> and acquires a reference to the Group on appendOrder (the OpOrder in the
> Segment)
> # {{CommmitLogSegment.sync}} hits {{waitForModifications}} which calls
> {{appendOrder.awaitNewBarrier}}
> # The in-flight write, if changing the state of the segment from
> CDCState.PERMITTED to CDCState.CONTAINS, enters {{setCDCState}} and blocks on
> synchronized(this)
> And neither of them ever come back. This came up while doing some further
> work on CASSANDRA-12148.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12287) offline_tools_test.TestOfflineTools.sstablelevelreset_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12287: --- Component/s: Testing > offline_tools_test.TestOfflineTools.sstablelevelreset_test > -- > > Key: CASSANDRA-12287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12287 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Craig Kodman >Assignee: Eduard Tudenhoefner > Attachments: node1.log, node1_debug.log, node1_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstablelevelreset_test/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12180) Should be able to override compaction space check
[ https://issues.apache.org/jira/browse/CASSANDRA-12180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12180: --- Component/s: Compaction > Should be able to override compaction space check > - > > Key: CASSANDRA-12180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12180 > Project: Cassandra > Issue Type: Improvement > Components: Compaction >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Fix For: 3.0.9, 3.8 > > Attachments: CASSANDRA-12180_3.0.txt > > > If there's not enough space for a compaction it won't do it and print the > exception below. Sometimes we know compaction will free up lot of space since > an ETL job could have inserted a lot of deletes. This override helps in this > case. > ERROR [CompactionExecutor:17] CassandraDaemon.java (line 258) Exception in > thread Thread > [CompactionExecutor:17,1,main] > java.lang.RuntimeException: Not enough space for compaction, estimated > sstables = 1552, expected > write size = 260540558535 > at org.apache.cassandra.db.compaction.CompactionTask.checkAvailableDiskSpace > (CompactionTask.java:306) > at > org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask. > java:106) > at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask. > java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask. > java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run > (CompactionManager.java:198) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12225:
---
Component/s: Testing
> dtest failure in
> materialized_views_test.TestMaterializedViews.clustering_column_test
> -
>
> Key: CASSANDRA-12225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12225
> Project: Cassandra
> Issue Type: Test
> Components: Testing
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
> Labels: dtest
> Fix For: 3.0.10, 3.10
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test
> Failed on CassCI build trunk_offheap_dtest #336
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 321, in clustering_column_test
> self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2,
> len(result)))
> File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> "Expecting 2 users, got 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12443) Remove alter type support
[ https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15600454#comment-15600454 ] Carl Yeksigian commented on CASSANDRA-12443: I went back and forth on removing the parsing logic from 3.x, but thought that since it wasn't a major version, it would be better to leave it in and provide a better error message, and since we have the 4.0 branch, we won't have it hanging around. ||3.0|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/3.0]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.0-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.0-dtest/]| ||3.x|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/3.x]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.x-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.x-dtest/]| ||trunk|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/trunk]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-trunk-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-trunk-dtest/]| Also, it seems like we should bump the CQL version on this, but the next version for 3.0 is 3.4.1, which is already defined in 3.x, and reusing it would cause an inconsistent versioning. Thoughts, [~blerer]? > Remove alter type support > - > > Key: CASSANDRA-12443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian > Fix For: 3.0.x > > > Currently, we allow altering of types. However, because we no longer store > the length for all types anymore, switching from a fixed-width to > variable-width type causes issues. commitlog playback breaking startup, > queries currently in flight getting back bad results, and special casing > required to handle the changes. In addition, this would solve > CASSANDRA-10309, as there is no possibility of the types changing while an > SSTableReader is open. > For fixed-length, compatible types, the alter also doesn't add much over a > cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11803) Creating a materialized view on a table with "token" column breaks the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian resolved CASSANDRA-11803.
Resolution: Fixed
Thanks, [~Stefania] and [~ifesdjeen].
Looked good -- committed as
[5f2367e|https://git-wip-us.apache.org/repos/asf/cassandra/repo?p=cassandra.git;a=commit;h=5f2367ef92517ac0bf7b7315de248021da2de4a6].
> Creating a materialized view on a table with "token" column breaks the cluster
> --
>
> Key: CASSANDRA-11803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11803
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kernel:
> Linux 4.4.8-20.46.amzn1.x86_64
> Java:
> Java OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassandra:
> datastax-ddc-3.3.0-1.noarch
> datastax-ddc-tools-3.3.0-1.noarch
>Reporter: Victor Trac
>Assignee: Carl Yeksigian
> Fix For: 3.0.10, 3.10, 4.0
>
>
> On a new Cassandra cluster, if we create a table with a field called "token"
> (with quotes) and then create a materialized view that uses "token", the
> cluster breaks. A ServerError is returned, and no further nodetool operations
> on the sstables work. Restarting the Cassandra server will also fail. It
> seems like the entire cluster is hosed.
> We tried this on Cassandra 3.3 and 3.5.
> Here's how to produce (on an new, empty cassandra 3.5 docker container):
> {code}
> [cqlsh 5.0.1 | Cassandra 3.5 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE account WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> CREATE TABLE account.session (
>... "token" blob,
>... account_id uuid,
>... PRIMARY KEY("token")
>... )WITH compaction={'class': 'LeveledCompactionStrategy'} AND
>... compression={'sstable_compression': 'LZ4Compressor'};
> cqlsh> CREATE MATERIALIZED VIEW account.account_session AS
>...SELECT account_id,"token" FROM account.session
>...WHERE "token" IS NOT NULL and account_id IS NOT NULL
>...PRIMARY KEY (account_id, "token");
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> cqlsh> drop table account.session;
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> {code}
> When any sstable*, nodetool, or when the Cassandra process is restarted, this
> is emitted on startup and Cassandra exits (copied from a server w/ data):
> {code}
> INFO [main] 2016-05-12 23:25:30,074 ColumnFamilyStore.java:395 -
> Initializing system_schema.indexes
> DEBUG [SSTableBatchOpen:1] 2016-05-12 23:25:30,075 SSTableReader.java:480 -
> Opening
> /mnt/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/ma-4-big
> (91 bytes)
> ERROR [main] 2016-05-12 23:25:30,143 CassandraDaemon.java:697 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.SyntaxException: line 1:59 no viable
> alternative at input 'FROM' (..., expire_at, last_used, token [FROM]...)
> at
> org.apache.cassandra.cql3.ErrorCollector.throwFirstSyntaxError(ErrorCollector.java:101)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:80)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:512)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchView(SchemaKeyspace.java:1128)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchViews(SchemaKeyspace.java:1092)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:903)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:879)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:124)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cas
[jira] [Updated] (CASSANDRA-11803) Creating a materialized view on a table with "token" column breaks the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11803:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks for the quick review, [~ifesdjeen].
Removed the bad keywords and added a test to ensure all words in the
ReservedKeywords list do not parse in
[bc9a079|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=bc9a0793944f7dd481646c4014d13b844439906c].
> Creating a materialized view on a table with "token" column breaks the cluster
> --
>
> Key: CASSANDRA-11803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11803
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kernel:
> Linux 4.4.8-20.46.amzn1.x86_64
> Java:
> Java OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassandra:
> datastax-ddc-3.3.0-1.noarch
> datastax-ddc-tools-3.3.0-1.noarch
>Reporter: Victor Trac
>Assignee: Carl Yeksigian
> Fix For: 3.0.10, 3.10, 4.0
>
>
> On a new Cassandra cluster, if we create a table with a field called "token"
> (with quotes) and then create a materialized view that uses "token", the
> cluster breaks. A ServerError is returned, and no further nodetool operations
> on the sstables work. Restarting the Cassandra server will also fail. It
> seems like the entire cluster is hosed.
> We tried this on Cassandra 3.3 and 3.5.
> Here's how to produce (on an new, empty cassandra 3.5 docker container):
> {code}
> [cqlsh 5.0.1 | Cassandra 3.5 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE account WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> CREATE TABLE account.session (
>... "token" blob,
>... account_id uuid,
>... PRIMARY KEY("token")
>... )WITH compaction={'class': 'LeveledCompactionStrategy'} AND
>... compression={'sstable_compression': 'LZ4Compressor'};
> cqlsh> CREATE MATERIALIZED VIEW account.account_session AS
>...SELECT account_id,"token" FROM account.session
>...WHERE "token" IS NOT NULL and account_id IS NOT NULL
>...PRIMARY KEY (account_id, "token");
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> cqlsh> drop table account.session;
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> {code}
> When any sstable*, nodetool, or when the Cassandra process is restarted, this
> is emitted on startup and Cassandra exits (copied from a server w/ data):
> {code}
> INFO [main] 2016-05-12 23:25:30,074 ColumnFamilyStore.java:395 -
> Initializing system_schema.indexes
> DEBUG [SSTableBatchOpen:1] 2016-05-12 23:25:30,075 SSTableReader.java:480 -
> Opening
> /mnt/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/ma-4-big
> (91 bytes)
> ERROR [main] 2016-05-12 23:25:30,143 CassandraDaemon.java:697 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.SyntaxException: line 1:59 no viable
> alternative at input 'FROM' (..., expire_at, last_used, token [FROM]...)
> at
> org.apache.cassandra.cql3.ErrorCollector.throwFirstSyntaxError(ErrorCollector.java:101)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:80)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:512)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchView(SchemaKeyspace.java:1128)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchViews(SchemaKeyspace.java:1092)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:903)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:879)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassan
[jira] [Updated] (CASSANDRA-11803) Creating a materialized view on a table with "token" column breaks the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11803:
---
Status: Patch Available (was: Reopened)
It looks like {{COUNT}}, {{WRITETIME}}, {{TTL}}, and {{KEY}}, and the CQL
types, should not be in the reserved keyword list:
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/cql3/Cql.g#L1578:L1633
I initially just used the {{basic_unreserved_keywords}} to determine the
keywords, so I've removed others which should not have been included:
https://github.com/carlyeks/cassandra/commit/ee76a10c75cc859ba178a7ec321b98aee2c0939a
> Creating a materialized view on a table with "token" column breaks the cluster
> --
>
> Key: CASSANDRA-11803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11803
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kernel:
> Linux 4.4.8-20.46.amzn1.x86_64
> Java:
> Java OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassandra:
> datastax-ddc-3.3.0-1.noarch
> datastax-ddc-tools-3.3.0-1.noarch
>Reporter: Victor Trac
>Assignee: Carl Yeksigian
> Fix For: 3.0.10, 3.10, 4.0
>
>
> On a new Cassandra cluster, if we create a table with a field called "token"
> (with quotes) and then create a materialized view that uses "token", the
> cluster breaks. A ServerError is returned, and no further nodetool operations
> on the sstables work. Restarting the Cassandra server will also fail. It
> seems like the entire cluster is hosed.
> We tried this on Cassandra 3.3 and 3.5.
> Here's how to produce (on an new, empty cassandra 3.5 docker container):
> {code}
> [cqlsh 5.0.1 | Cassandra 3.5 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE account WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> CREATE TABLE account.session (
>... "token" blob,
>... account_id uuid,
>... PRIMARY KEY("token")
>... )WITH compaction={'class': 'LeveledCompactionStrategy'} AND
>... compression={'sstable_compression': 'LZ4Compressor'};
> cqlsh> CREATE MATERIALIZED VIEW account.account_session AS
>...SELECT account_id,"token" FROM account.session
>...WHERE "token" IS NOT NULL and account_id IS NOT NULL
>...PRIMARY KEY (account_id, "token");
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> cqlsh> drop table account.session;
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> {code}
> When any sstable*, nodetool, or when the Cassandra process is restarted, this
> is emitted on startup and Cassandra exits (copied from a server w/ data):
> {code}
> INFO [main] 2016-05-12 23:25:30,074 ColumnFamilyStore.java:395 -
> Initializing system_schema.indexes
> DEBUG [SSTableBatchOpen:1] 2016-05-12 23:25:30,075 SSTableReader.java:480 -
> Opening
> /mnt/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/ma-4-big
> (91 bytes)
> ERROR [main] 2016-05-12 23:25:30,143 CassandraDaemon.java:697 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.SyntaxException: line 1:59 no viable
> alternative at input 'FROM' (..., expire_at, last_used, token [FROM]...)
> at
> org.apache.cassandra.cql3.ErrorCollector.throwFirstSyntaxError(ErrorCollector.java:101)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:80)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:512)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchView(SchemaKeyspace.java:1128)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchViews(SchemaKeyspace.java:1092)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:903)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:879)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
> ~[apache-cassa
[jira] [Commented] (CASSANDRA-12252) Support RR and Speculative Retry for EACH_QUORUM reads
[ https://issues.apache.org/jira/browse/CASSANDRA-12252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582666#comment-15582666 ] Carl Yeksigian commented on CASSANDRA-12252: I've pushed [a branch|https://github.com/carlyeks/cassandra/tree/ticket/12252] which changes the callback to properly handle multiple DCs when there is a read repair. Still need to update speculative retry to use the DC responses to choose the appropriate DC to retry, and add tests for correctness. > Support RR and Speculative Retry for EACH_QUORUM reads > -- > > Key: CASSANDRA-12252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12252 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian >Priority: Minor > > We should properly support read repair and speculative retry for EACH_QUORUM > reads. > To support these, we need to make sure that we count responses for each DC > separately, so that we can properly monitor the number of responses from > each. For speculative retry, we should try to replace each host that we are > retrying with one in the same DC; that will make sure that we actually have > the correct responses at the end if the speculative retries are successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12535) Occasionally seeing AccessControlException, CodecNotFoundException when executing a User Defined Aggregate
[
https://issues.apache.org/jira/browse/CASSANDRA-12535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12535:
---
Status: Open (was: Patch Available)
> Occasionally seeing AccessControlException, CodecNotFoundException when
> executing a User Defined Aggregate
> --
>
> Key: CASSANDRA-12535
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12535
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.7 (via brew install), Mac OS X 10.11.6
>Reporter: Pat Patterson
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> I have defined a UDA to implement standard deviation:
> {noformat}
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdState ( state
> tuple, val double ) CALLED ON NULL INPUT RETURNS
> tuple LANGUAGE java AS
> ... 'int n = state.getInt(0); double mean = state.getDouble(1); double m2 =
> state.getDouble(2); n++; double delta = val - mean; mean += delta / n; m2 +=
> delta * (val - mean); state.setInt(0, n); state.setDouble(1, mean);
> state.setDouble(2, m2); return state;';
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdFinal ( state
> tuple ) CALLED ON NULL INPUT RETURNS double LANGUAGE java
> AS
> ... 'int n = state.getInt(0); double m2 = state.getDouble(2); if (n < 1) {
> return null; } return Math.sqrt(m2 / (n - 1));';
> cqlsh:mykeyspace> CREATE AGGREGATE IF NOT EXISTS stdev ( double )
> ... SFUNC sdState STYPE tuple FINALFUNC sdFinal INITCOND
> (0,0,0);
> {noformat}
> My table:
> {noformat}
> CREATE TABLE readings (
> sensor_id int,
> time timestamp,
> temperature double,
> status text,
> PRIMARY KEY (sensor_id, time)
> ) WITH CLUSTERING ORDER BY (time ASC);
> {noformat}
> I'm inserting a row every 0.1 seconds. The data looks like this:
> {noformat}
> cqlsh:mykeyspace> select * from readings limit 10;
> sensor_id | time| status | temperature
> ---+-++-
> 5 | 2016-08-24 19:11:34.896000+ | OK |9.97
> 5 | 2016-08-24 19:11:43.933000+ | OK | 10.28
> 5 | 2016-08-24 19:11:49.958000+ | OK |7.65
> 5 | 2016-08-24 19:11:51.968000+ | OK | 10.11
> 5 | 2016-08-24 19:12:58.512000+ | Fault | 10.41
> 5 | 2016-08-24 19:13:04.542000+ | OK |9.66
> 5 | 2016-08-24 19:13:16.593000+ | OK |10.9
> 5 | 2016-08-24 19:13:37.692000+ | OK |11.2
> 5 | 2016-08-24 19:13:46.738000+ | OK | 10.34
> 5 | 2016-08-24 19:13:49.757000+ | OK |10.6
> {noformat}
> I'm running a query every few seconds with my UDA - like this (timestamps are
> different each time):
> {noformat}
> select avg(temperature), stdev(temperature) from readings where sensor_id = 1
> and time > 1472066523193;
> {noformat}
> Most of the time, this works just fine:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings
> where sensor_id = 1 and time > 1472066523193;
> system.avg(temperature) | mykeyspace.stdev(temperature)
> -+---
> 9.9291 | 0.94179
> (1 rows)
> {noformat}
> But, occasionally, it fails with one of two exceptions:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings
> where sensor_id = 1 and time > 1472066523193;
> Traceback (most recent call last):
> File "/usr/local/Cellar/cassandra/3.7/libexec/bin/cqlsh.py", line 1277, in
> perform_simple_statement
> result = future.result()
> File "cassandra/cluster.py", line 3629, in
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369)
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'mykeyspace.sdstate[frozen>,
> double]' failed: java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/usr/local/etc/cassandra/logback.xml" "read")"
> {noformat}
> or
> {noformat}
> cqlsh:mykeyspace> select count(*), avg(temperature), stdev(temperature) from
> readings where sensor_id = 1 and time > '2016-08-24 15:00:00.000+';
> Traceback (most recent call last):
> File "/usr/local/Cellar/cassandra/3.7/libexec/bin/cqlsh.py", line 1277, in
> perform_simple_statement
> result = future.result()
> File "cassandra/cluster.py", line 3629, in
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369)
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function
[jira] [Commented] (CASSANDRA-12535) Occasionally seeing AccessControlException, CodecNotFoundException when executing a User Defined Aggregate
[
https://issues.apache.org/jira/browse/CASSANDRA-12535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575963#comment-15575963
]
Carl Yeksigian commented on CASSANDRA-12535:
Looks like the logback reload tests failed in CI.
Is there a way for us to suppress the logging attempts made from a secured
thread? While this seems like it will fix the issue at hand, just worried that
future updates to logback or the logger that we use will cause other subtle
issues with our sandboxing.
> Occasionally seeing AccessControlException, CodecNotFoundException when
> executing a User Defined Aggregate
> --
>
> Key: CASSANDRA-12535
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12535
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.7 (via brew install), Mac OS X 10.11.6
>Reporter: Pat Patterson
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> I have defined a UDA to implement standard deviation:
> {noformat}
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdState ( state
> tuple, val double ) CALLED ON NULL INPUT RETURNS
> tuple LANGUAGE java AS
> ... 'int n = state.getInt(0); double mean = state.getDouble(1); double m2 =
> state.getDouble(2); n++; double delta = val - mean; mean += delta / n; m2 +=
> delta * (val - mean); state.setInt(0, n); state.setDouble(1, mean);
> state.setDouble(2, m2); return state;';
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdFinal ( state
> tuple ) CALLED ON NULL INPUT RETURNS double LANGUAGE java
> AS
> ... 'int n = state.getInt(0); double m2 = state.getDouble(2); if (n < 1) {
> return null; } return Math.sqrt(m2 / (n - 1));';
> cqlsh:mykeyspace> CREATE AGGREGATE IF NOT EXISTS stdev ( double )
> ... SFUNC sdState STYPE tuple FINALFUNC sdFinal INITCOND
> (0,0,0);
> {noformat}
> My table:
> {noformat}
> CREATE TABLE readings (
> sensor_id int,
> time timestamp,
> temperature double,
> status text,
> PRIMARY KEY (sensor_id, time)
> ) WITH CLUSTERING ORDER BY (time ASC);
> {noformat}
> I'm inserting a row every 0.1 seconds. The data looks like this:
> {noformat}
> cqlsh:mykeyspace> select * from readings limit 10;
> sensor_id | time| status | temperature
> ---+-++-
> 5 | 2016-08-24 19:11:34.896000+ | OK |9.97
> 5 | 2016-08-24 19:11:43.933000+ | OK | 10.28
> 5 | 2016-08-24 19:11:49.958000+ | OK |7.65
> 5 | 2016-08-24 19:11:51.968000+ | OK | 10.11
> 5 | 2016-08-24 19:12:58.512000+ | Fault | 10.41
> 5 | 2016-08-24 19:13:04.542000+ | OK |9.66
> 5 | 2016-08-24 19:13:16.593000+ | OK |10.9
> 5 | 2016-08-24 19:13:37.692000+ | OK |11.2
> 5 | 2016-08-24 19:13:46.738000+ | OK | 10.34
> 5 | 2016-08-24 19:13:49.757000+ | OK |10.6
> {noformat}
> I'm running a query every few seconds with my UDA - like this (timestamps are
> different each time):
> {noformat}
> select avg(temperature), stdev(temperature) from readings where sensor_id = 1
> and time > 1472066523193;
> {noformat}
> Most of the time, this works just fine:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings
> where sensor_id = 1 and time > 1472066523193;
> system.avg(temperature) | mykeyspace.stdev(temperature)
> -+---
> 9.9291 | 0.94179
> (1 rows)
> {noformat}
> But, occasionally, it fails with one of two exceptions:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings
> where sensor_id = 1 and time > 1472066523193;
> Traceback (most recent call last):
> File "/usr/local/Cellar/cassandra/3.7/libexec/bin/cqlsh.py", line 1277, in
> perform_simple_statement
> result = future.result()
> File "cassandra/cluster.py", line 3629, in
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369)
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'mykeyspace.sdstate[frozen>,
> double]' failed: java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/usr/local/etc/cassandra/logback.xml" "read")"
> {noformat}
> or
> {noformat}
> cqlsh:mykeyspace> select count(*), avg(temperature), stdev(temperature) from
> readings where sensor_id = 1 and time > '2016-08-24 15:00:00.000+';
> Traceback (most recent call last):
> File "/usr/local/Cellar/cass
[jira] [Assigned] (CASSANDRA-12252) Support RR and Speculative Retry for EACH_QUORUM reads
[ https://issues.apache.org/jira/browse/CASSANDRA-12252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian reassigned CASSANDRA-12252: -- Assignee: Carl Yeksigian > Support RR and Speculative Retry for EACH_QUORUM reads > -- > > Key: CASSANDRA-12252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12252 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian >Priority: Minor > > We should properly support read repair and speculative retry for EACH_QUORUM > reads. > To support these, we need to make sure that we count responses for each DC > separately, so that we can properly monitor the number of responses from > each. For speculative retry, we should try to replace each host that we are > retrying with one in the same DC; that will make sure that we actually have > the correct responses at the end if the speculative retries are successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12790) Support InfluxDb metrics reporter config
[
https://issues.apache.org/jira/browse/CASSANDRA-12790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian resolved CASSANDRA-12790.
Resolution: Duplicate
Assignee: (was: Benjamin Lerer)
Fix Version/s: 3.10
Reproduced In: (was: 3.0.9)
The update to metrics-reporter 3.0.3 has already been committed to 3.10.
> Support InfluxDb metrics reporter config
>
>
> Key: CASSANDRA-12790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12790
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration, Packaging
> Environment: Ubuntu 14.04
> Oracle Java 1.8.0_65
> Cassandra 3.0.9
>Reporter: Achmad Nasirudin Sandi
>Priority: Minor
> Labels: easyfix, easytest, newbie
> Fix For: 3.10
>
> Attachments: metrics-reporter-config-influx.yaml
>
>
> InfluxDb is a great tool for storing metrics. The main advantage over
> graphite protocol is its tag mechanism that allows host info to be excluded
> from metric name.
> I managed to send metrics into InfluxDb by putting
> {{metrics-influxdb-1.1.7.jar}} into {{lib}} folder and replacing these
> dependencies jar:
>
> {code}
> commons-codec-1.2.jar -> commons-codec-1.9.jar
> reporter-config3-3.0.0.jar -> reporter-config3-3.0.3.jar
> reporter-config-base-3.0.0.jar -> reporter-config-base-3.0.3.jar
> {code}
> Although it seems that dropwizard team is working on official [package for
> InfluxDb|https://github.com/dropwizard/metrics/tree/4.0-development], it
> would be great it those libs are available in default distribution by
> upgrading {{commons-codec}} and {{metrics}} dependencies. I was wondering
> what effect are there to Cassandra functionality. Where can I help?
> Attached file is my configuration example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12790) Support InfluxDb metrics reporter config
[
https://issues.apache.org/jira/browse/CASSANDRA-12790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12790:
---
Fix Version/s: (was: 3.10)
> Support InfluxDb metrics reporter config
>
>
> Key: CASSANDRA-12790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12790
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration, Packaging
> Environment: Ubuntu 14.04
> Oracle Java 1.8.0_65
> Cassandra 3.0.9
>Reporter: Achmad Nasirudin Sandi
>Priority: Minor
> Labels: easyfix, easytest, newbie
> Attachments: metrics-reporter-config-influx.yaml
>
>
> InfluxDb is a great tool for storing metrics. The main advantage over
> graphite protocol is its tag mechanism that allows host info to be excluded
> from metric name.
> I managed to send metrics into InfluxDb by putting
> {{metrics-influxdb-1.1.7.jar}} into {{lib}} folder and replacing these
> dependencies jar:
>
> {code}
> commons-codec-1.2.jar -> commons-codec-1.9.jar
> reporter-config3-3.0.0.jar -> reporter-config3-3.0.3.jar
> reporter-config-base-3.0.0.jar -> reporter-config-base-3.0.3.jar
> {code}
> Although it seems that dropwizard team is working on official [package for
> InfluxDb|https://github.com/dropwizard/metrics/tree/4.0-development], it
> would be great it those libs are available in default distribution by
> upgrading {{commons-codec}} and {{metrics}} dependencies. I was wondering
> what effect are there to Cassandra functionality. Where can I help?
> Attached file is my configuration example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12268: --- Fix Version/s: (was: 3.0.x) (was: 3.x) 4.0 3.10 3.0.10 > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.10, 3.10, 4.0 > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11803) Creating a materialized view on a table with "token" column breaks the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11803:
---
Fix Version/s: (was: 3.0.x)
4.0
3.10
3.0.10
> Creating a materialized view on a table with "token" column breaks the cluster
> --
>
> Key: CASSANDRA-11803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11803
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kernel:
> Linux 4.4.8-20.46.amzn1.x86_64
> Java:
> Java OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassandra:
> datastax-ddc-3.3.0-1.noarch
> datastax-ddc-tools-3.3.0-1.noarch
>Reporter: Victor Trac
>Assignee: Carl Yeksigian
> Fix For: 3.0.10, 3.10, 4.0
>
>
> On a new Cassandra cluster, if we create a table with a field called "token"
> (with quotes) and then create a materialized view that uses "token", the
> cluster breaks. A ServerError is returned, and no further nodetool operations
> on the sstables work. Restarting the Cassandra server will also fail. It
> seems like the entire cluster is hosed.
> We tried this on Cassandra 3.3 and 3.5.
> Here's how to produce (on an new, empty cassandra 3.5 docker container):
> {code}
> [cqlsh 5.0.1 | Cassandra 3.5 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE account WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> CREATE TABLE account.session (
>... "token" blob,
>... account_id uuid,
>... PRIMARY KEY("token")
>... )WITH compaction={'class': 'LeveledCompactionStrategy'} AND
>... compression={'sstable_compression': 'LZ4Compressor'};
> cqlsh> CREATE MATERIALIZED VIEW account.account_session AS
>...SELECT account_id,"token" FROM account.session
>...WHERE "token" IS NOT NULL and account_id IS NOT NULL
>...PRIMARY KEY (account_id, "token");
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> cqlsh> drop table account.session;
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> {code}
> When any sstable*, nodetool, or when the Cassandra process is restarted, this
> is emitted on startup and Cassandra exits (copied from a server w/ data):
> {code}
> INFO [main] 2016-05-12 23:25:30,074 ColumnFamilyStore.java:395 -
> Initializing system_schema.indexes
> DEBUG [SSTableBatchOpen:1] 2016-05-12 23:25:30,075 SSTableReader.java:480 -
> Opening
> /mnt/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/ma-4-big
> (91 bytes)
> ERROR [main] 2016-05-12 23:25:30,143 CassandraDaemon.java:697 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.SyntaxException: line 1:59 no viable
> alternative at input 'FROM' (..., expire_at, last_used, token [FROM]...)
> at
> org.apache.cassandra.cql3.ErrorCollector.throwFirstSyntaxError(ErrorCollector.java:101)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:80)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:512)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchView(SchemaKeyspace.java:1128)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchViews(SchemaKeyspace.java:1092)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:903)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:879)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:124)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:229)
> [apache-cassandra-3.5.0.jar:3.5.0]
> at
> o
[jira] [Updated] (CASSANDRA-11803) Creating a materialized view on a table with "token" column breaks the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11803:
---
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks for the review [~ifesdjeen].
Committed as
[153583b|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=153583be55e2a0bba74102bf1d5fc7a79d314b1f].
> Creating a materialized view on a table with "token" column breaks the cluster
> --
>
> Key: CASSANDRA-11803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11803
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kernel:
> Linux 4.4.8-20.46.amzn1.x86_64
> Java:
> Java OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassandra:
> datastax-ddc-3.3.0-1.noarch
> datastax-ddc-tools-3.3.0-1.noarch
>Reporter: Victor Trac
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> On a new Cassandra cluster, if we create a table with a field called "token"
> (with quotes) and then create a materialized view that uses "token", the
> cluster breaks. A ServerError is returned, and no further nodetool operations
> on the sstables work. Restarting the Cassandra server will also fail. It
> seems like the entire cluster is hosed.
> We tried this on Cassandra 3.3 and 3.5.
> Here's how to produce (on an new, empty cassandra 3.5 docker container):
> {code}
> [cqlsh 5.0.1 | Cassandra 3.5 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE account WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> CREATE TABLE account.session (
>... "token" blob,
>... account_id uuid,
>... PRIMARY KEY("token")
>... )WITH compaction={'class': 'LeveledCompactionStrategy'} AND
>... compression={'sstable_compression': 'LZ4Compressor'};
> cqlsh> CREATE MATERIALIZED VIEW account.account_session AS
>...SELECT account_id,"token" FROM account.session
>...WHERE "token" IS NOT NULL and account_id IS NOT NULL
>...PRIMARY KEY (account_id, "token");
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> cqlsh> drop table account.session;
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> {code}
> When any sstable*, nodetool, or when the Cassandra process is restarted, this
> is emitted on startup and Cassandra exits (copied from a server w/ data):
> {code}
> INFO [main] 2016-05-12 23:25:30,074 ColumnFamilyStore.java:395 -
> Initializing system_schema.indexes
> DEBUG [SSTableBatchOpen:1] 2016-05-12 23:25:30,075 SSTableReader.java:480 -
> Opening
> /mnt/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/ma-4-big
> (91 bytes)
> ERROR [main] 2016-05-12 23:25:30,143 CassandraDaemon.java:697 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.SyntaxException: line 1:59 no viable
> alternative at input 'FROM' (..., expire_at, last_used, token [FROM]...)
> at
> org.apache.cassandra.cql3.ErrorCollector.throwFirstSyntaxError(ErrorCollector.java:101)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:80)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:512)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchView(SchemaKeyspace.java:1128)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchViews(SchemaKeyspace.java:1092)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:903)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:879)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:124)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.
[jira] [Commented] (CASSANDRA-12252) Support RR and Speculative Retry for EACH_QUORUM reads
[ https://issues.apache.org/jira/browse/CASSANDRA-12252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575432#comment-15575432 ] Carl Yeksigian commented on CASSANDRA-12252: Since EACH_QUORUM is not a typical consistency level for users, I think it makes sense to try to continue to use the simple ReadCallback that we currently have which does not need to track each DC independently, only the number of responses, for all other consistency levels, and only add the complexity of a DC aware counter if we are using a DC-aware consistency level (possibly adding this support for LOCAL_* consistency levels as well). For speculative retry, we can't select a single node to retry before we send the first set of requests - we need to know which DCs have failed to responded before we can properly choose the next node to try. In this case, we will need the information from the read callback to determine which DC hasn't responded yet, and then can choose the next replica to which to send an additional request. This can be done with a new SpeculativeRetry type since this will not be the usual case. > Support RR and Speculative Retry for EACH_QUORUM reads > -- > > Key: CASSANDRA-12252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12252 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Priority: Minor > > We should properly support read repair and speculative retry for EACH_QUORUM > reads. > To support these, we need to make sure that we count responses for each DC > separately, so that we can properly monitor the number of responses from > each. For speculative retry, we should try to replace each host that we are > retrying with one in the same DC; that will make sure that we actually have > the correct responses at the end if the speculative retries are successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11803) Creating a materialized view on a table with "token" column breaks the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15572655#comment-15572655
]
Carl Yeksigian commented on CASSANDRA-11803:
I just pushed a couple of updates to address your nits, and rebased and pushed
up two new branches for 3.x and trunk:
||3.x|[branch|https://github.com/carlyeks/cassandra/tree/ticket/11803/3.x]|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-11803-3.x-testall/]|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-11803-3.x-dtest/]|
||trunk|[branch|https://github.com/carlyeks/cassandra/tree/ticket/11803/trunk]|[utest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-11803-trunk-testall/]|[dtest|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-11803-trunk-dtest/]|
> Creating a materialized view on a table with "token" column breaks the cluster
> --
>
> Key: CASSANDRA-11803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11803
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kernel:
> Linux 4.4.8-20.46.amzn1.x86_64
> Java:
> Java OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassandra:
> datastax-ddc-3.3.0-1.noarch
> datastax-ddc-tools-3.3.0-1.noarch
>Reporter: Victor Trac
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> On a new Cassandra cluster, if we create a table with a field called "token"
> (with quotes) and then create a materialized view that uses "token", the
> cluster breaks. A ServerError is returned, and no further nodetool operations
> on the sstables work. Restarting the Cassandra server will also fail. It
> seems like the entire cluster is hosed.
> We tried this on Cassandra 3.3 and 3.5.
> Here's how to produce (on an new, empty cassandra 3.5 docker container):
> {code}
> [cqlsh 5.0.1 | Cassandra 3.5 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE account WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> CREATE TABLE account.session (
>... "token" blob,
>... account_id uuid,
>... PRIMARY KEY("token")
>... )WITH compaction={'class': 'LeveledCompactionStrategy'} AND
>... compression={'sstable_compression': 'LZ4Compressor'};
> cqlsh> CREATE MATERIALIZED VIEW account.account_session AS
>...SELECT account_id,"token" FROM account.session
>...WHERE "token" IS NOT NULL and account_id IS NOT NULL
>...PRIMARY KEY (account_id, "token");
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> cqlsh> drop table account.session;
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> {code}
> When any sstable*, nodetool, or when the Cassandra process is restarted, this
> is emitted on startup and Cassandra exits (copied from a server w/ data):
> {code}
> INFO [main] 2016-05-12 23:25:30,074 ColumnFamilyStore.java:395 -
> Initializing system_schema.indexes
> DEBUG [SSTableBatchOpen:1] 2016-05-12 23:25:30,075 SSTableReader.java:480 -
> Opening
> /mnt/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/ma-4-big
> (91 bytes)
> ERROR [main] 2016-05-12 23:25:30,143 CassandraDaemon.java:697 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.SyntaxException: line 1:59 no viable
> alternative at input 'FROM' (..., expire_at, last_used, token [FROM]...)
> at
> org.apache.cassandra.cql3.ErrorCollector.throwFirstSyntaxError(ErrorCollector.java:101)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:80)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:512)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchView(SchemaKeyspace.java:1128)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchViews(SchemaKeyspace.java:1092)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:903)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspaces
[jira] [Updated] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12268: --- Resolution: Fixed Status: Resolved (was: Patch Available) The tests looked like they were unrelated (all passed locally). Committed as [76f1750|https://git1-us-west.apache.org/repos/asf/cassandra/?p=cassandra.git;a=commit;h=76f175028544fe20f30ae873f23cba559097cef1]. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12783) Break up large MV mutations to prevent OOMs
Carl Yeksigian created CASSANDRA-12783: -- Summary: Break up large MV mutations to prevent OOMs Key: CASSANDRA-12783 URL: https://issues.apache.org/jira/browse/CASSANDRA-12783 Project: Cassandra Issue Type: Bug Reporter: Carl Yeksigian We only use the code path added in CASSANDRA-12268 for the view builder because otherwise we would break the contract of the batchlog, where some mutations may be written and pushed out before the whole batch log has been saved. We would need to ensure that all of the updates make it to the batchlog before allowing the batchlog manager to try to replay them, but also before we start pushing out updates to the paired replicas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10309) Avoid always looking up column type
[ https://issues.apache.org/jira/browse/CASSANDRA-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566003#comment-15566003 ] Carl Yeksigian commented on CASSANDRA-10309: CASSANDRA-12443 removes the need to reload the sstables after they have been loaded - since there is no way for the types to change after the sstable has been loaded, we don't need to have a way to refresh the metadata which simplifies this ticket.4 > Avoid always looking up column type > --- > > Key: CASSANDRA-10309 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10309 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Assignee: Carl Yeksigian >Priority: Minor > Labels: perfomance > Fix For: 3.x > > > Doing some read profiling I noticed we always seem to look up the type of a > column from the schema metadata when we have the type already in the column > class. > This one simple change to SerializationHeader improves read performance > non-trivially. > https://github.com/tjake/cassandra/commit/69b94c389b3f36aa035ac4619fd22d1f62ea80b2 > http://cstar.datastax.com/graph?stats=3fb1ced4-58c7-11e5-9faf-42010af0688f&metric=op_rate&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=357.94&ymin=0&ymax=157416.6 > I assume we are looking this up to deal with schema changes. But I'm sure > there is a more performant way of doing this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10309) Avoid always looking up column type
[ https://issues.apache.org/jira/browse/CASSANDRA-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566003#comment-15566003 ] Carl Yeksigian edited comment on CASSANDRA-10309 at 10/11/16 5:12 PM: -- CASSANDRA-12443 removes the need to reload the sstables after they have been loaded - since there is no way for the types to change after the sstable has been loaded, we don't need to have a way to refresh the metadata which simplifies this ticket. was (Author: carlyeks): CASSANDRA-12443 removes the need to reload the sstables after they have been loaded - since there is no way for the types to change after the sstable has been loaded, we don't need to have a way to refresh the metadata which simplifies this ticket.4 > Avoid always looking up column type > --- > > Key: CASSANDRA-10309 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10309 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Assignee: Carl Yeksigian >Priority: Minor > Labels: perfomance > Fix For: 3.x > > > Doing some read profiling I noticed we always seem to look up the type of a > column from the schema metadata when we have the type already in the column > class. > This one simple change to SerializationHeader improves read performance > non-trivially. > https://github.com/tjake/cassandra/commit/69b94c389b3f36aa035ac4619fd22d1f62ea80b2 > http://cstar.datastax.com/graph?stats=3fb1ced4-58c7-11e5-9faf-42010af0688f&metric=op_rate&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=357.94&ymin=0&ymax=157416.6 > I assume we are looking this up to deal with schema changes. But I'm sure > there is a more performant way of doing this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12705) Add column definition kind to system schema dropped columns
[
https://issues.apache.org/jira/browse/CASSANDRA-12705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1456#comment-1456
]
Carl Yeksigian commented on CASSANDRA-12705:
This looks good, but we use the string of the kind enum when we are persisting
the column definition; probably makes sense to keep that here as well.
Also, the CI was so dirty, it's hard to tell if there is anything wrong.
> Add column definition kind to system schema dropped columns
> ---
>
> Key: CASSANDRA-12705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12705
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 4.0
>
>
> Both regular and static columns can currently be dropped by users, but this
> information is currently not stored in {{SchemaKeyspace.DroppedColumns}}. As
> a consequence, {{CFMetadata.getDroppedColumnDefinition}} returns a regular
> column and this has caused problems such as CASSANDRA-12582.
> We should add the column kind to {{SchemaKeyspace.DroppedColumns}} so that
> {{CFMetadata.getDroppedColumnDefinition}} can create the correct column
> definition. However, altering schema tables would cause inter-node
> communication failures during a rolling upgrade, see CASSANDRA-12236.
> Therefore we should wait for a full schema migration when upgrading to the
> next major version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12582) Removing static column results in ReadFailure due to CorruptSSTableException
[
https://issues.apache.org/jira/browse/CASSANDRA-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12582:
---
Status: Ready to Commit (was: Patch Available)
> Removing static column results in ReadFailure due to CorruptSSTableException
>
>
> Key: CASSANDRA-12582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12582
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: Cassandra 3.0.8
>Reporter: Evan Prothro
>Assignee: Stefania
>Priority: Critical
> Labels: compaction, corruption, drop, read, static
> Fix For: 3.0.x, 3.x
>
> Attachments: 12582.cdl, 12582_reproduce.sh
>
>
> We ran into an issue on production where reads began to fail for certain
> queries, depending on the range within the relation for those queries.
> Cassandra system log showed an unhandled {{CorruptSSTableException}}
> exception.
> CQL read failure:
> {code}
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation
> failed - received 0 responses and 1 failures" info={'failures': 1,
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> Cassandra exception:
> {code}
> WARN [SharedPool-Worker-2] 2016-08-31 12:49:27,979
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.RuntimeException:
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /usr/local/apache-cassandra-3.0.8/data/data/issue309/apples_by_tree-006748a06fa311e6a7f8ef8b642e977b/mb-1-big-Data.db
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2453)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_72]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [apache-cassandra-3.0.8.jar:3.0.8]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.0.8.jar:3.0.8]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /usr/local/apache-cassandra-3.0.8/data/data/issue309/apples_by_tree-006748a06fa311e6a7f8ef8b642e977b/mb-1-big-Data.db
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:343)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:66)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:62)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:24)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:295)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java
[jira] [Commented] (CASSANDRA-12582) Removing static column results in ReadFailure due to CorruptSSTableException
[
https://issues.apache.org/jira/browse/CASSANDRA-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1431#comment-1431
]
Carl Yeksigian commented on CASSANDRA-12582:
+1
> Removing static column results in ReadFailure due to CorruptSSTableException
>
>
> Key: CASSANDRA-12582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12582
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: Cassandra 3.0.8
>Reporter: Evan Prothro
>Assignee: Stefania
>Priority: Critical
> Labels: compaction, corruption, drop, read, static
> Fix For: 3.0.x, 3.x
>
> Attachments: 12582.cdl, 12582_reproduce.sh
>
>
> We ran into an issue on production where reads began to fail for certain
> queries, depending on the range within the relation for those queries.
> Cassandra system log showed an unhandled {{CorruptSSTableException}}
> exception.
> CQL read failure:
> {code}
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation
> failed - received 0 responses and 1 failures" info={'failures': 1,
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> Cassandra exception:
> {code}
> WARN [SharedPool-Worker-2] 2016-08-31 12:49:27,979
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.RuntimeException:
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /usr/local/apache-cassandra-3.0.8/data/data/issue309/apples_by_tree-006748a06fa311e6a7f8ef8b642e977b/mb-1-big-Data.db
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2453)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_72]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [apache-cassandra-3.0.8.jar:3.0.8]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.0.8.jar:3.0.8]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /usr/local/apache-cassandra-3.0.8/data/data/issue309/apples_by_tree-006748a06fa311e6a7f8ef8b642e977b/mb-1-big-Data.db
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:343)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:66)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:62)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:24)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:295)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
> ~[apache-cassandra-3.0.8.jar:3.0.8]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageP
[jira] [Updated] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12268: --- Status: Patch Available (was: Open) Those test failures were most likely due to the sizing of the nodes running this test. I've also rebased in order to clean up the runs. ||3.0|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12268-3.0]|[utest|http://cassci.datastax.com/job/carlyeks-ticket-12268-3.0-testall/]|[dtest|http://cassci.datastax.com/job/carlyeks-ticket-12268-3.0-dtest/]| ||3.x|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12268-3.x]|[utest|http://cassci.datastax.com/job/carlyeks-ticket-12268-3.x-testall/]|[dtest|http://cassci.datastax.com/job/carlyeks-ticket-12268-3.x-dtest/]| ||trunk|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12268]|[utest|http://cassci.datastax.com/job/carlyeks-ticket-12268-testall/]|[dtest|http://cassci.datastax.com/job/carlyeks-ticket-12268-dtest/]| > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12753) Create MV can corrupt C*, blocking all further table actions and startup
[
https://issues.apache.org/jira/browse/CASSANDRA-12753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian resolved CASSANDRA-12753.
Resolution: Duplicate
This is the same issue as in CASSANDRA-11803, with a different reserved word.
If you have a chance, can you try applying that patch and seeing if it fixes
the issue?
> Create MV can corrupt C*, blocking all further table actions and startup
>
>
> Key: CASSANDRA-12753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12753
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: RHEL6.5
> Cas 3.0.9
>Reporter: Hazel Bobrins
>Priority: Critical
> Attachments: Cass_start.txt, MV_Create.txt, table_drop.txt
>
>
> Creating a MV with a protected field name e.g. 'set' results in an error.
> Post this failed MV create all further actions in the keyspace fail and node
> startup fails until the keyspace is dropped.
> Tested on a fresh 3.0.9 install single node cluster.
> How to reproduce
> cassandra@cqlsh:test1> CREATE KEYSPACE test1 WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1 } AND durable_writes = 'true';
> cassandra@cqlsh:test1> use test1 ;
> cassandra@cqlsh:test1> CREATE TABLE main_table ( field1 text, field2 text,
> "set" text, PRIMARY KEY ( field1, field2 ) );
> cassandra@cqlsh:test1> CREATE MATERIALIZED VIEW mv1 AS SELECT field2, field1,
> "set" FROM main_table WHERE field1 IS NOT NULL AND field2 IS NOT NULL PRIMARY
> KEY ( field2, field1 ) ;
> ServerError: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable
> alternative at input 'set' (SELECT field1, field2, [set]...)
> ## Attached stack traces - 'MV_Create' thrown at this point
> cassandra@cqlsh:test1> drop TABLE main_table ;
> ServerError: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable
> alternative at input 'set' (SELECT field1, field2, [set]...)
> ## Attached stacke traces - 'Table_drop' thrown at this point
> Finally restart Cassandra. Attached stack 'Cass_start' thrown at this point
> and C* does not start.
> Dropping the keyspace does work, however, this must obviously be done before
> stopping the node.
> We have also tested this on a 4 node cluster, post the MV create all nodes
> report the same issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12751) pip install cassandra-driver
[
https://issues.apache.org/jira/browse/CASSANDRA-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian resolved CASSANDRA-12751.
Resolution: Invalid
This Jira is for core Cassandra development.
You should ask your question to the python driver group instead:
https://github.com/datastax/python-driver#getting-help
> pip install cassandra-driver
>
>
> Key: CASSANDRA-12751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12751
> Project: Cassandra
> Issue Type: Task
> Components: Configuration
> Environment: DSE 3.0
> RHEL 6.0
>Reporter: Eric Pedregosa
>Priority: Critical
>
> Hi,
> Just want to understand what this error mean. I just installed Python 2.7
> from 2.6. Also, installed DSE 5.0 from 4.9.
> Also, DSE 5.0 requires Python 2.7 but upon installing Python 2.7 the 2.6
> remains. I learned that we cannot remove 2.6 from the system otherwise it may
> cause problem. Python 2.6 shell will be remain to be executed as 'python'.
> How will DSE 5.0 associate with Python 2.7 instead of 2.6?
> [root@ushapls00056la ~]# pip install cassandra-driver
> Collecting cassandra-driver
> Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=3, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=2, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=1, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=3, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=2, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=1, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No
> address associated with hostname'))': /simple/cassandra-driver/
> Could not find a version that satisfies the requirement cassandra-driver
> (from versions: )
> No matching distribution found for cassandra-driver
> [root@ushapls00056la ~]# cqlsh 100.114.116.104
> No appropriate python interpreter found.
> Thanks.
> Eric
--
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=15548984#comment-15548984 ] Carl Yeksigian commented on CASSANDRA-8844: --- [~sridhar.nem...@whamtech.com]: No, this is still a low-level, mutation-based output. I would suggest asking on the [user mailing list|http://cassandra.apache.org/community/] instead, as this Jira ticket is only about the feature as it has been implemented. > 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.8 > > > "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 to process them in order. > - Daemons should be able to checkpoint their work, and resume from where they > left off. This means they would have to leave some file artifact in the CDC > log's directory. > - A sophisticated daemon should be able to be written that could > -- Catch up, in written-order, even when it is multiple logfiles behind in > processing > -- Be able to continuously "tail" the most recent logfile and get > low-latency(ms?) access to the data as it is written. > h2. Alternate approa
[jira] [Updated] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12268: --- Status: Open (was: Patch Available) Looks like there are some failures related to MV in the dtests; I'm cancelling the patch will I take a look at them. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9830) Option to disable bloom filter in highest level of LCS sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545808#comment-15545808 ] Carl Yeksigian commented on CASSANDRA-9830: --- I'm +1 on the code changes to the compaction strategy, but the perf testing never ran, so we haven't yet shown a reduction in memory usage - [~pauloricardomg]: can you take a look and ensure it runs (or post the results if they have run properly). Also, I'd like to see some additional tests that make sure that we are getting the same set of results whether or not the bloom filter is loaded for the top level. Should be both point queries and range queries. > Option to disable bloom filter in highest level of LCS sstables > --- > > Key: CASSANDRA-9830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9830 > Project: Cassandra > Issue Type: New Feature > Components: Compaction >Reporter: Jonathan Ellis >Assignee: Paulo Motta >Priority: Minor > Labels: lcs, performance > Fix For: 3.x > > > We expect about 90% of data to be in the highest level of LCS in a fully > populated series. (See also CASSANDRA-9829.) > Thus if the user is primarily asking for data (partitions) that has actually > been inserted, the bloom filter on the highest level only helps reject > sstables about 10% of the time. > We should add an option that suppresses bloom filter creation on top-level > sstables. This will dramatically reduce memory usage for LCS and may even > improve performance as we no longer check a low-value filter. > (This is also an idea from RocksDB.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9830) Option to disable bloom filter in highest level of LCS sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-9830: -- Status: Open (was: Patch Available) > Option to disable bloom filter in highest level of LCS sstables > --- > > Key: CASSANDRA-9830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9830 > Project: Cassandra > Issue Type: New Feature > Components: Compaction >Reporter: Jonathan Ellis >Assignee: Paulo Motta >Priority: Minor > Labels: lcs, performance > Fix For: 3.x > > > We expect about 90% of data to be in the highest level of LCS in a fully > populated series. (See also CASSANDRA-9829.) > Thus if the user is primarily asking for data (partitions) that has actually > been inserted, the bloom filter on the highest level only helps reject > sstables about 10% of the time. > We should add an option that suppresses bloom filter creation on top-level > sstables. This will dramatically reduce memory usage for LCS and may even > improve performance as we no longer check a low-value filter. > (This is also an idea from RocksDB.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11803) Creating a materialized view on a table with "token" column breaks the cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11803:
---
Fix Version/s: (was: 3.x)
3.0.x
Reproduced In: 3.0.0 (was: 3.3, 3.5)
Status: Patch Available (was: Open)
I've posted a branch which adds a list of reserved words and will also quote if
it is a reserved word. If this approach looks OK, I'll add a test for it.
||3.0|[branch|https://github.com/carlyeks/cassandra/tree/ticket/11803/3.0]|[utest|http://cassci.datastax.com/job/carlyeks-ticket-11803-3.0-testall/]|[dtest|http://cassci.datastax.com/job/carlyeks-ticket-11803-3.0-dtest/]|
> Creating a materialized view on a table with "token" column breaks the cluster
> --
>
> Key: CASSANDRA-11803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11803
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kernel:
> Linux 4.4.8-20.46.amzn1.x86_64
> Java:
> Java OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassandra:
> datastax-ddc-3.3.0-1.noarch
> datastax-ddc-tools-3.3.0-1.noarch
>Reporter: Victor Trac
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> On a new Cassandra cluster, if we create a table with a field called "token"
> (with quotes) and then create a materialized view that uses "token", the
> cluster breaks. A ServerError is returned, and no further nodetool operations
> on the sstables work. Restarting the Cassandra server will also fail. It
> seems like the entire cluster is hosed.
> We tried this on Cassandra 3.3 and 3.5.
> Here's how to produce (on an new, empty cassandra 3.5 docker container):
> {code}
> [cqlsh 5.0.1 | Cassandra 3.5 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE account WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> CREATE TABLE account.session (
>... "token" blob,
>... account_id uuid,
>... PRIMARY KEY("token")
>... )WITH compaction={'class': 'LeveledCompactionStrategy'} AND
>... compression={'sstable_compression': 'LZ4Compressor'};
> cqlsh> CREATE MATERIALIZED VIEW account.account_session AS
>...SELECT account_id,"token" FROM account.session
>...WHERE "token" IS NOT NULL and account_id IS NOT NULL
>...PRIMARY KEY (account_id, "token");
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> cqlsh> drop table account.session;
> ServerError: message="java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> {code}
> When any sstable*, nodetool, or when the Cassandra process is restarted, this
> is emitted on startup and Cassandra exits (copied from a server w/ data):
> {code}
> INFO [main] 2016-05-12 23:25:30,074 ColumnFamilyStore.java:395 -
> Initializing system_schema.indexes
> DEBUG [SSTableBatchOpen:1] 2016-05-12 23:25:30,075 SSTableReader.java:480 -
> Opening
> /mnt/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/ma-4-big
> (91 bytes)
> ERROR [main] 2016-05-12 23:25:30,143 CassandraDaemon.java:697 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.SyntaxException: line 1:59 no viable
> alternative at input 'FROM' (..., expire_at, last_used, token [FROM]...)
> at
> org.apache.cassandra.cql3.ErrorCollector.throwFirstSyntaxError(ErrorCollector.java:101)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:80)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:512)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchView(SchemaKeyspace.java:1128)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchViews(SchemaKeyspace.java:1092)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:903)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:879)
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
> ~[apache-ca
[jira] [Commented] (CASSANDRA-12199) Config class uses boxed types but DD exposes primitive types
[
https://issues.apache.org/jira/browse/CASSANDRA-12199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545568#comment-15545568
]
Carl Yeksigian commented on CASSANDRA-12199:
+1
> Config class uses boxed types but DD exposes primitive types
>
>
> Key: CASSANDRA-12199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12199
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
>
> {{Config}} class contains a lot of properties that are defined using boxed
> types - ({{Config.dynamic_snitch_update_interval_in_ms}}) but the
> corresponding get-methods in {{DatabaseDescriptor}} require them to be not
> null. Means, setting such properties to {{null}} will lead to NPEs anyway.
> Proposal:
> * Identify all properties that use boxed values and have a default value
> (e.g. {{public Integer rpc_port = 9160;}})
> * Refactor those to use primitive types
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12199) Config class uses boxed types but DD exposes primitive types
[
https://issues.apache.org/jira/browse/CASSANDRA-12199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12199:
---
Status: Ready to Commit (was: Patch Available)
> Config class uses boxed types but DD exposes primitive types
>
>
> Key: CASSANDRA-12199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12199
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
>
> {{Config}} class contains a lot of properties that are defined using boxed
> types - ({{Config.dynamic_snitch_update_interval_in_ms}}) but the
> corresponding get-methods in {{DatabaseDescriptor}} require them to be not
> null. Means, setting such properties to {{null}} will lead to NPEs anyway.
> Proposal:
> * Identify all properties that use boxed values and have a default value
> (e.g. {{public Integer rpc_port = 9160;}})
> * Refactor those to use primitive types
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15543085#comment-15543085 ] Carl Yeksigian commented on CASSANDRA-12268: Just realized that there is an issue with using the same path for the regular update and during build, in that we can break apart batches and not provide the same semantics as we currently do. I've just added a boolean to determine whether or not to return more than one mutation. I'll kick off new CI runs. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12741) Optimize Materialied view update when base table and view table have the same partition key
[ https://issues.apache.org/jira/browse/CASSANDRA-12741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian resolved CASSANDRA-12741. Resolution: Not A Problem This is already the case, as long as there are no nodes joining the ring in that token range. > Optimize Materialied view update when base table and view table have the same > partition key > --- > > Key: CASSANDRA-12741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12741 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Mickaël Delanoë >Priority: Minor > > When the base table and the view table share the same partition key, both > tables will use the same node. > I guess performance optimization can be done in that SPECIAL case. > And in that case could it also be conceivable to have a synchronous update of > the view table (to enforce consistency) at the cost of a increased latency ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12443) Remove alter type support
[ https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12443: --- Fix Version/s: (was: 4.x) 3.0.x Status: Patch Available (was: Open) The errors in the tests don't reproduce locally, but I've rebased and pushed a new version and kicked off CI. Also pushed a new [dtest branch|https://github.com/carlyeks/cassandra-dtest/tree/fix-12443] which removes the alter type statements in those tests as well. > Remove alter type support > - > > Key: CASSANDRA-12443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian > Fix For: 3.0.x > > > Currently, we allow altering of types. However, because we no longer store > the length for all types anymore, switching from a fixed-width to > variable-width type causes issues. commitlog playback breaking startup, > queries currently in flight getting back bad results, and special casing > required to handle the changes. In addition, this would solve > CASSANDRA-10309, as there is no possibility of the types changing while an > SSTableReader is open. > For fixed-length, compatible types, the alter also doesn't add much over a > cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536270#comment-15536270 ] Carl Yeksigian commented on CASSANDRA-12268: All of the current failures look down to known issues, but I'm rerunning trunk just to make sure. ping [~tjake] for review > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12397) Altering a column's type breaks commitlog replay
[
https://issues.apache.org/jira/browse/CASSANDRA-12397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530155#comment-15530155
]
Carl Yeksigian commented on CASSANDRA-12397:
The longer term fix is removing support for altering types (CASSANDRA-12443) -
if that ticket does end up in 3.0, we won't need to handle the CL replay
separately as it should no longer be a problem.
> Altering a column's type breaks commitlog replay
>
>
> Key: CASSANDRA-12397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12397
> Project: Cassandra
> Issue Type: Bug
>Reporter: Carl Yeksigian
>Assignee: Stefania
>
> When switching from a fixed-length column to a variable-length column,
> replaying the commitlog on restart will have the same issue as
> CASSANDRA-11820. Seems like it is related to the schema being flushed and
> used when restarted, but commitlogs having been written in the old format.
> {noformat}
> org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /tmp/mutation4816372620457789996dat. This may be caused by replaying a
> mutation against a table with the same name but incompatible schema.
> Exception follows: java.io.IOError: java.io.EOFException: EOF after 259 bytes
> out of 3336
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:409)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:342)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:201)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:84)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:139)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:177)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:158)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:316)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:591)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:720)
> [main/:na]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12225:
---
Resolution: Fixed
Reviewer: Philip Thompson
Fix Version/s: (was: 3.0.x)
(was: 3.x)
3.0.10
3.10
Status: Resolved (was: Patch Available)
Committed to dtest.
> dtest failure in
> materialized_views_test.TestMaterializedViews.clustering_column_test
> -
>
> Key: CASSANDRA-12225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12225
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
> Labels: dtest
> Fix For: 3.10, 3.0.10
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test
> Failed on CassCI build trunk_offheap_dtest #336
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 321, in clustering_column_test
> self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2,
> len(result)))
> File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> "Expecting 2 users, got 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12443) Remove alter type support
[ https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526479#comment-15526479 ] Carl Yeksigian commented on CASSANDRA-12443: I've pushed a branch for 3.0 (not sure where this should go, but it is a simple enough patch to roll it forward to trunk). This disallows the changing of types; I've changed the things that will help CASSANDRA-10309. Only worry with this solution is that someone could execute an alter statement on a lower-version cluster machine and change the schema in the table and on some cluster machines. However, since we say not to touch the schema while operating in a mixed-version cluster, this shouldn't happen. [branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/3.0] [utest|http://cassci.datastax.com/job/carlyeks-ticket-12443-3.0-testall/] [dtest|http://cassci.datastax.com/job/carlyeks-ticket-12443-3.0-dtest/] > Remove alter type support > - > > Key: CASSANDRA-12443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian > Fix For: 4.x > > > Currently, we allow altering of types. However, because we no longer store > the length for all types anymore, switching from a fixed-width to > variable-width type causes issues. commitlog playback breaking startup, > queries currently in flight getting back bad results, and special casing > required to handle the changes. In addition, this would solve > CASSANDRA-10309, as there is no possibility of the types changing while an > SSTableReader is open. > For fixed-length, compatible types, the alter also doesn't add much over a > cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12443) Remove alter type support
[ https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian reassigned CASSANDRA-12443: -- Assignee: Carl Yeksigian > Remove alter type support > - > > Key: CASSANDRA-12443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Assignee: Carl Yeksigian > Fix For: 4.x > > > Currently, we allow altering of types. However, because we no longer store > the length for all types anymore, switching from a fixed-width to > variable-width type causes issues. commitlog playback breaking startup, > queries currently in flight getting back bad results, and special casing > required to handle the changes. In addition, this would solve > CASSANDRA-10309, as there is no possibility of the types changing while an > SSTableReader is open. > For fixed-length, compatible types, the alter also doesn't add much over a > cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10540) RangeAwareCompaction
[ https://issues.apache.org/jira/browse/CASSANDRA-10540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526390#comment-15526390 ] Carl Yeksigian commented on CASSANDRA-10540: I'm +1 on the code here, I'm just waiting on some more testing from [~philipthompson]. Thanks for the ping [~jjirsa]. > RangeAwareCompaction > > > Key: CASSANDRA-10540 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10540 > Project: Cassandra > Issue Type: New Feature >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Labels: compaction, lcs, vnodes > Fix For: 3.x > > > Broken out from CASSANDRA-6696, we should split sstables based on ranges > during compaction. > Requirements; > * dont create tiny sstables - keep them bunched together until a single vnode > is big enough (configurable how big that is) > * make it possible to run existing compaction strategies on the per-range > sstables > We should probably add a global compaction strategy parameter that states > whether this should be enabled or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12225:
---
Fix Version/s: 3.x
3.0.x
Status: Patch Available (was: Open)
The latest run through looks good, opened [dtest
PR|https://github.com/riptano/cassandra-dtest/pull/1337].
> dtest failure in
> materialized_views_test.TestMaterializedViews.clustering_column_test
> -
>
> Key: CASSANDRA-12225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12225
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
> Labels: dtest
> Fix For: 3.0.x, 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test
> Failed on CassCI build trunk_offheap_dtest #336
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 321, in clustering_column_test
> self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2,
> len(result)))
> File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> "Expecting 2 users, got 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15507733#comment-15507733
]
Carl Yeksigian commented on CASSANDRA-12225:
I've fixed the test, which was failing because capture_output wasn't defined,
and am
[rerunning|http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/325/]
- I must have been using an old version of ccm locally.
> dtest failure in
> materialized_views_test.TestMaterializedViews.clustering_column_test
> -
>
> Key: CASSANDRA-12225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12225
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test
> Failed on CassCI build trunk_offheap_dtest #336
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 321, in clustering_column_test
> self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2,
> len(result)))
> File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> "Expecting 2 users, got 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12268: --- Status: Patch Available (was: Awaiting Feedback) I've pushed an update - it was due to the initial collection of mutations being empty. I'm rerunning CI for 3.0 and trunk now. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490924#comment-15490924
]
Carl Yeksigian commented on CASSANDRA-12225:
I ran a [multiplexed
dtest|http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/253/]
and it failed once with the same error.
I've pushed a new commit to wait for all of the stages to settle before
continuing; I'm rerunning the [multiplexed
test|http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/313/]
to see if there are any new failures.
> dtest failure in
> materialized_views_test.TestMaterializedViews.clustering_column_test
> -
>
> Key: CASSANDRA-12225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12225
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test
> Failed on CassCI build trunk_offheap_dtest #336
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 321, in clustering_column_test
> self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2,
> len(result)))
> File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> "Expecting 2 users, got 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12617) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15487949#comment-15487949
]
Carl Yeksigian commented on CASSANDRA-12617:
Any ideas why this would affect the offheap dtest while not affecting the
normal dtest?
Seems really odd that this test would need a different amount of data generated
considering it has been passing on trunk.
> dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-12617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12617
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/391/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test/
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/offline_tools_test.py", line 212, in
> sstableofflinerelevel_test
> self.assertGreater(max(final_levels), 1)
> File "/usr/lib/python2.7/unittest/case.py", line 942, in assertGreater
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "1 not greater than 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11332) nodes connect to themselves when NTS is used
[
https://issues.apache.org/jira/browse/CASSANDRA-11332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-11332:
---
Resolution: Fixed
Fix Version/s: (was: 2.1.x)
3.10
3.0.9
2.2.8
Status: Resolved (was: Patch Available)
+1
Committed as
[ad4a91da7|http://git-wip-us.apache.org/repos/asf/cassandra/commit/ad4a91da7].
I didn't put this into 2.1 as it doesn't seem like a critical fix, but did put
it into 2.2+.
> nodes connect to themselves when NTS is used
>
>
> Key: CASSANDRA-11332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11332
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Brandon Williams
>Assignee: Branimir Lambov
> Fix For: 2.2.8, 3.0.9, 3.10
>
>
> I tested this with both the simple snitch and PFS. It's quite easy to repro,
> setup a cluster, start it. Mine looks like this:
> {noformat}
> tcp0 0 10.208.8.123:48003 10.208.8.63:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.8.63:40215
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:9 10.208.35.225:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:33498 10.208.8.63:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.35.225:52530
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.35.225:53674
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:40846 10.208.35.225:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.8.63:48880
> ESTABLISHED 26254/java
> {noformat}
> No problems so far. Now create a keyspace using NTS with an rf of 3, and
> perform some writes. Now it looks like this:
> {noformat}
> tcp0 0 10.208.8.123:48003 10.208.8.63:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.8.123:35024
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:35024 10.208.8.123:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:47212 10.208.8.123:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.8.63:40215
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:9 10.208.35.225:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:33498 10.208.8.63:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.35.225:52530
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.35.225:53674
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.8.123:47212
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:40846 10.208.35.225:7000
> ESTABLISHED 26254/java
> tcp0 0 10.208.8.123:7000 10.208.8.63:48880
> ESTABLISHED 26254/java
> {noformat}
> I can't think of any reason for a node to connect to itself, and this can
> cause problems with PFS where you might only define the broadcast addresses,
> but now you need the internal addresses too because the node will need to
> look itself up when connecting to itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12413) CompactionsCQLTest.testTriggerMinorCompactionDTCS fails
[
https://issues.apache.org/jira/browse/CASSANDRA-12413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455833#comment-15455833
]
Carl Yeksigian commented on CASSANDRA-12413:
+1
> CompactionsCQLTest.testTriggerMinorCompactionDTCS fails
> ---
>
> Key: CASSANDRA-12413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12413
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joshua McKenzie
>Assignee: Marcus Eriksson
> Labels: unittest
> Fix For: 3.9
>
>
> [Link|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testTriggerMinorCompactionDTCS/]
> Error Message
> No minor compaction triggered in 5000ms
> Stacktrace
> {noformat}
> junit.framework.AssertionFailedError: No minor compaction triggered in 5000ms
> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.waitForMinor(CompactionsCQLTest.java:247)
> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testTriggerMinorCompactionDTCS(CompactionsCQLTest.java:72)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12413) CompactionsCQLTest.testTriggerMinorCompactionDTCS fails
[
https://issues.apache.org/jira/browse/CASSANDRA-12413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12413:
---
Status: Ready to Commit (was: Patch Available)
> CompactionsCQLTest.testTriggerMinorCompactionDTCS fails
> ---
>
> Key: CASSANDRA-12413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12413
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joshua McKenzie
>Assignee: Marcus Eriksson
> Labels: unittest
> Fix For: 3.9
>
>
> [Link|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testTriggerMinorCompactionDTCS/]
> Error Message
> No minor compaction triggered in 5000ms
> Stacktrace
> {noformat}
> junit.framework.AssertionFailedError: No minor compaction triggered in 5000ms
> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.waitForMinor(CompactionsCQLTest.java:247)
> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testTriggerMinorCompactionDTCS(CompactionsCQLTest.java:72)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12424) Assertion failure in ViewUpdateGenerator
[
https://issues.apache.org/jira/browse/CASSANDRA-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian resolved CASSANDRA-12424.
Resolution: Duplicate
Assignee: (was: Carl Yeksigian)
I think you are right; if this is not fixed by 3.8, then please reopen.
> Assertion failure in ViewUpdateGenerator
>
>
> Key: CASSANDRA-12424
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12424
> Project: Cassandra
> Issue Type: Bug
>Reporter: Keith Wansbrough
> Attachments: cassandra.log
>
>
> Using released apache-cassandra-3.7.0, we have managed to get a node into a
> state where it won't start up. The exception is {{java.lang.AssertionError:
> We shouldn't have got there is the base row had no associated entry}} and it
> appears in
> ViewUpdateGenerator.computeLivenessInfoForEntry(ViewUpdateGenerator.java:455).
> I still have the offending node; what diags/data would be useful for
> diagnosis? I've attached the full cassandra.log. In summary, cassandra.log
> contains multiple instances of the following when replaying the commit log on
> startup, leading ultimately to failure to start up.
> {code}
> ERROR 15:24:17 Unknown exception caught while attempting to update
> MaterializedView! edison.scs_subscriber
> java.lang.AssertionError: We shouldn't have got there is the base row had no
> associated entry
> at
> org.apache.cassandra.db.view.ViewUpdateGenerator.computeLivenessInfoForEntry(ViewUpdateGenerator.java:455)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.ViewUpdateGenerator.updateEntry(ViewUpdateGenerator.java:273)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.ViewUpdateGenerator.addBaseTableUpdate(ViewUpdateGenerator.java:127)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.TableViews.addToViewUpdateGenerators(TableViews.java:403)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.TableViews.generateViewUpdates(TableViews.java:236)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.TableViews.pushViewReplicaUpdates(TableViews.java:140)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:514)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.Keyspace.applyFromCommitLog(Keyspace.java:409)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer$MutationInitiator$1.runMayThrow(CommitLogReplayer.java:152)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_91]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> WARN 15:24:17 Uncaught exception on thread
> Thread[SharedPool-Worker-4,5,main]: {}
> {code}
> and ultimately
> {code}
> ERROR 15:24:18 Exception encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.AssertionError: We shouldn't have got there is the base row had no
> associated entry
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455243#comment-15455243 ] Carl Yeksigian commented on CASSANDRA-12268: After rebasing and rerunning, these failures are legitimate and are caused by batchlog replay of the newly created mutations. We are trying to replay a batch which includes no entries, and are failing because of it. I've added an assertion that we are generating non-empty mutations, but it isn't being tripped, so I haven't yet found where this is occurring. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12443) Remove alter type support
Carl Yeksigian created CASSANDRA-12443: -- Summary: Remove alter type support Key: CASSANDRA-12443 URL: https://issues.apache.org/jira/browse/CASSANDRA-12443 Project: Cassandra Issue Type: Improvement Reporter: Carl Yeksigian Fix For: 4.x Currently, we allow altering of types. However, because we no longer store the length for all types anymore, switching from a fixed-width to variable-width type causes issues. commitlog playback breaking startup, queries currently in flight getting back bad results, and special casing required to handle the changes. In addition, this would solve CASSANDRA-10309, as there is no possibility of the types changing while an SSTableReader is open. For fixed-length, compatible types, the alter also doesn't add much over a cast, so users could use that in order to retrieve the altered type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15415818#comment-15415818
]
Carl Yeksigian commented on CASSANDRA-12225:
I was finally able to reproduce this locally.
Since it is so uncommon, I am hoping this is down to a timing issue between the
base and the view updates. We return from the base mutation being applied
before the view is applied. In the case where it failed for me, node3 was
marked down by the other nodes, so it is possible there was an inconsistent
read here.
I've pushed [a dtest
branch|https://github.com/carlyeks/cassandra-dtest/tree/fix-12225] which
replays the batchlogs after inserting data; hopefully that will help this test.
I'm currently running this locally to see whether it can still be reproduced.
> dtest failure in
> materialized_views_test.TestMaterializedViews.clustering_column_test
> -
>
> Key: CASSANDRA-12225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12225
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Philip Thompson
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test
> Failed on CassCI build trunk_offheap_dtest #336
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 321, in clustering_column_test
> self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2,
> len(result)))
> File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> "Expecting 2 users, got 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12424) Assertion failure in ViewUpdateGenerator
[
https://issues.apache.org/jira/browse/CASSANDRA-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian reassigned CASSANDRA-12424:
--
Assignee: Carl Yeksigian
> Assertion failure in ViewUpdateGenerator
>
>
> Key: CASSANDRA-12424
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12424
> Project: Cassandra
> Issue Type: Bug
>Reporter: Keith Wansbrough
>Assignee: Carl Yeksigian
> Attachments: cassandra.log
>
>
> Using released apache-cassandra-3.7.0, we have managed to get a node into a
> state where it won't start up. The exception is {{java.lang.AssertionError:
> We shouldn't have got there is the base row had no associated entry}} and it
> appears in
> ViewUpdateGenerator.computeLivenessInfoForEntry(ViewUpdateGenerator.java:455).
> I still have the offending node; what diags/data would be useful for
> diagnosis? I've attached the full cassandra.log. In summary, cassandra.log
> contains multiple instances of the following when replacing the commit log on
> startup, leading ultimately to failure to start up.
> {code}
> ERROR 15:24:17 Unknown exception caught while attempting to update
> MaterializedView! edison.scs_subscriber
> java.lang.AssertionError: We shouldn't have got there is the base row had no
> associated entry
> at
> org.apache.cassandra.db.view.ViewUpdateGenerator.computeLivenessInfoForEntry(ViewUpdateGenerator.java:455)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.ViewUpdateGenerator.updateEntry(ViewUpdateGenerator.java:273)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.ViewUpdateGenerator.addBaseTableUpdate(ViewUpdateGenerator.java:127)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.TableViews.addToViewUpdateGenerators(TableViews.java:403)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.TableViews.generateViewUpdates(TableViews.java:236)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.view.TableViews.pushViewReplicaUpdates(TableViews.java:140)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:514)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.Keyspace.applyFromCommitLog(Keyspace.java:409)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer$MutationInitiator$1.runMayThrow(CommitLogReplayer.java:152)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_91]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> WARN 15:24:17 Uncaught exception on thread
> Thread[SharedPool-Worker-4,5,main]: {}
> {code}
> and ultimately
> {code}
> ERROR 15:24:18 Exception encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.AssertionError: We shouldn't have got there is the base row had no
> associated entry
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12176) dtest failure in materialized_views_test.TestMaterializedViews.complex_repair_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian resolved CASSANDRA-12176.
Resolution: Fixed
Assignee: Jim Witschey (was: Carl Yeksigian)
Reviewer: Philip Thompson
Lets set it as done for now; if it comes up again, we'll need to investigate if
there is some real deadlock in the system. I don't think we'll be covering it
up with these changes - it should still timeout.
> dtest failure in
> materialized_views_test.TestMaterializedViews.complex_repair_test
> --
>
> Key: CASSANDRA-12176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12176
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Jim Witschey
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log,
> node4.log, node4_debug.log, node4_gc.log, node5.log, node5_debug.log,
> node5_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/8/testReport/materialized_views_test/TestMaterializedViews/complex_repair_test
> Failed on CassCI build cassandra-3.9_novnode_dtest #8
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/materialized_views_test.py", line
> 956, in complex_repair_test
> session.execute("CREATE TABLE ks.t (id int PRIMARY KEY, v int, v2 text,
> v3 decimal)"
> File "cassandra/cluster.py", line 1941, in
> cassandra.cluster.Session.execute (cassandra/cluster.c:33642)
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile).result()
> File "cassandra/cluster.py", line 3629, in
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369)
> raise self._final_exception
> ' message="Keyspace ks doesn\'t exist">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12397) Altering a column's type breaks commitlog replay
Carl Yeksigian created CASSANDRA-12397:
--
Summary: Altering a column's type breaks commitlog replay
Key: CASSANDRA-12397
URL: https://issues.apache.org/jira/browse/CASSANDRA-12397
Project: Cassandra
Issue Type: Bug
Reporter: Carl Yeksigian
When switching from a fixed-length column to a variable-length column,
replaying the commitlog on restart will have the same issue as CASSANDRA-11820.
Seems like it is related to the schema being flushed and used when restarted,
but commitlogs having been written in the old format.
{noformat}
org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
Unexpected error deserializing mutation; saved to
/tmp/mutation4816372620457789996dat. This may be caused by replaying a
mutation against a table with the same name but incompatible schema. Exception
follows: java.io.IOError: java.io.EOFException: EOF after 259 bytes out of 3336
at
org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:409)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:342)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:201)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:84)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:139)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:177)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:158)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:316)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:591)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:720)
[main/:na]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12268: --- Fix Version/s: 3.x 3.0.x Status: Patch Available (was: In Progress) > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-12268: --- Attachment: 12268.py I've added just the basics, and it does work for this. I think we should probably add this fix as is; it will have inefficiencies for internode communications, but it can handle a large partition. The other enhancements can come after this. I'm running CI on the branch now. |[3.0|https://github.com/carlyeks/cassandra/tree/ticket/12268-3.0]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12268-3.0-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12268-3.0-dtest/]| |[3.9|https://github.com/carlyeks/cassandra/tree/ticket/12268-3.9]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12268-3.9-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12268-3.9-dtest/]| |[trunk|https://github.com/carlyeks/cassandra/tree/ticket/12268]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12268-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12268-dtest/]| I'm also attaching the script that I used to test whether this worked or not - the number of iterations might be able to brought down with a really small heap size to reproduce the issue, but with a small-ish heap, this crashed without the fix and ran with it. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.x, 3.x > > Attachments: 12268.py > > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12336) NullPointerException during compaction on table with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-12336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407836#comment-15407836
]
Carl Yeksigian commented on CASSANDRA-12336:
Sorry about that; didn't see it was patch available.
+1, assuming a clean CI rerun
> NullPointerException during compaction on table with static columns
> ---
>
> Key: CASSANDRA-12336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12336
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: cqlsh 5.0.1
> Cassandra 3.0.8-SNAPSHOT (3.0.x dev - a5cbb0)
>Reporter: Evan Prothro
>Assignee: Sylvain Lebresne
> Fix For: 3.0.9
>
>
> After being affected by
> https://issues.apache.org/jira/browse/CASSANDRA-11988, we built a5cbb0.
> Compaction still fails with the following trace:
> {code}
> WARN [SharedPool-Worker-2] 2016-07-28 10:51:56,111
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.RuntimeException: java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2453)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_72]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[main/:na]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.applyToRow(ReadCommand.java:466)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.applyToStatic(ReadCommand.java:460)
> ~[main/:na]
> at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:105)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:41)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.Transformation.add(Transformation.java:156)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:122)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.applyToPartition(ReadCommand.java:454)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadCommand$1MetricRecording.applyToPartition(ReadCommand.java:438)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
> ~[main/:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:295)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:145)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:138)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:134)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:320)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2449)
> ~[main/:na]
> ... 5 common frames omitted
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404719#comment-15404719 ] Carl Yeksigian commented on CASSANDRA-12268: I've pushed the progress I've made so far on this ticket to a [branch|https://github.com/carlyeks/cassandra/tree/ticket/12268]. For the mutations which require merging with the previous values, we return a single collection of Mutations; for updates only (there are no base values to compare with, such as during building), we return each update as a mutation which gets written and pushed. I am working on verifying that this provides a solution to the problem; if it does, I'll move onto working on the batching of mutations. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11670) Error while waiting on bootstrap to complete. Bootstrap will have to be restarted. Stream failed
[
https://issues.apache.org/jira/browse/CASSANDRA-11670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395602#comment-15395602
]
Carl Yeksigian commented on CASSANDRA-11670:
This looks good to me, but I'd also like to get [~blambov]'s opinion as he did
the work on CASSANDRA-7237 to make improvements to batchlog.
> Error while waiting on bootstrap to complete. Bootstrap will have to be
> restarted. Stream failed
>
>
> Key: CASSANDRA-11670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11670
> Project: Cassandra
> Issue Type: Bug
> Components: Configuration, Streaming and Messaging
>Reporter: Anastasia Osintseva
>Assignee: Paulo Motta
> Fix For: 3.0.x
>
>
> I have in cluster 2 DC, in each DC - 2 Nodes. I wanted to add 1 node to each
> DC. One node has been added successfully after I had made scrubing.
> Now I'm trying to add node to another DC, but get error:
> org.apache.cassandra.streaming.StreamException: Stream failed.
> After scrubing and repair I get the same error.
> {noformat}
> ERROR [StreamReceiveTask:5] 2016-04-27 00:33:21,082 Keyspace.java:492 -
> Unknown exception caught while attempting to update MaterializedView!
> messages_dump.messages
> java.lang.IllegalArgumentException: Mutation of 34974901 bytes is too large
> for the maxiumum size of 33554432
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:264)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:469)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:217)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:146)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:724)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:487)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:217)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Mutation.applyUnsafe(Mutation.java:236)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:169)
> [apache-cassandra-3.0.5.jar:3.0.5]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_11]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_11]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_11]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_11]
> ERROR [StreamReceiveTask:5] 2016-04-27 00:33:21,082
> StreamReceiveTask.java:214 - Error applying streamed data:
> java.lang.IllegalArgumentException: Mutation of 34974901 bytes is too large
> for the maxiumum size of 33554432
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:264)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:469)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:384)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:205)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:217)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:146)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:724)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at
> org.apache.cassandra.db.view.ViewManager.pushViewReplicaUpdates(ViewManager.java:149)
> ~[apache-cassandra-3.0.5.jar:3.0.5]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:487)
> ~[apache-cassandra-3.0.5
[jira] [Updated] (CASSANDRA-12312) Restore JVM metric export for metric reporters
[
https://issues.apache.org/jira/browse/CASSANDRA-12312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-12312:
---
Fix Version/s: 3.x
3.0.x
2.2.x
> Restore JVM metric export for metric reporters
> --
>
> Key: CASSANDRA-12312
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12312
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 12312-2.2.patch, 12312-3.0.patch, 12312-trunk.patch,
> metrics-jvm-3.1.0.jar.asc
>
>
> JVM instrumentation as part of dropwizard metrics has been moved to a
> separate {{metrics-jvm}} artifact in metrics-v3.0. After CASSANDRA-5657, no
> jvm related metrics will be exported to any reporter configured via
> {{metrics-reporter-config}}, as this isn't part of {{metrics-core}} anymore.
> As memory and GC stats are essential for monitoring Cassandra, this turns out
> to be a blocker for us for upgrading to 2.2.
> I've included a patch that would add the now separate {{metrics-jvm}} package
> and enables some of the provided metrics on startup in case a metrics
> reporter is used ({{-Dcassandra.metricsReporterConfigFile}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395570#comment-15395570 ] Carl Yeksigian commented on CASSANDRA-12268: That sounds like a good plan; definitely missed the forest for the trees on this one. We want to find the right balance between sending each update individually versus combining the some number of updates so that we have less to apply on the replica, but we don't have the same consistency issues for this as we would for a regular update that needs to update previous values. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows
[ https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15394304#comment-15394304 ] Carl Yeksigian commented on CASSANDRA-12268: This is a side effect of the way that we read in a partition and create all of the mutations for that partition. This can also affect normal MV operations, for example when we issue a partition deletion on a very large partition. We need to be sure that we can build using smaller-than-partition ranges, which should alleviate the issue of holding large amounts of mutations in memory. > Make MV Index creation robust for wide referent rows > > > Key: CASSANDRA-12268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > > When creating an index for a materialized view for extant data, heap pressure > is very dependent on the cardinality of of rows associated with each index > value. With the way that per-index value rows are created within the index, > this can cause unbounded heap pressure, which can cause OOM. This appears to > be a side-effect of how each index row is applied atomically as with batches. > The commit logs can accumulate enough during the process to prevent the node > from being restarted. Given that this occurs during global index creation, > this can happen on multiple nodes, making stable recovery of a node set > difficult, as co-replicas become unavailable to assist in back-filling data > from commitlogs. > While it is understandable that you want to avoid having relatively wide rows > even in materialized views, this represents a particularly difficult > scenario for triage. > The basic recommendation for improving this is to sub-group the index > creation into smaller chunks internally, providing a maximal bound against > the heap pressure when it is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12302) Document compaction log messages
Carl Yeksigian created CASSANDRA-12302: -- Summary: Document compaction log messages Key: CASSANDRA-12302 URL: https://issues.apache.org/jira/browse/CASSANDRA-12302 Project: Cassandra Issue Type: Improvement Reporter: Carl Yeksigian Assignee: Carl Yeksigian Priority: Minor The compaction logger has a lot of different log messages that can be logged; these should be included in the doc directory along with a representative compaction log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
