[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15393308#comment-15393308 ] sankalp kohli commented on CASSANDRA-12180: --- Was CI Clean [~carlyeks] > 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 >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > 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] [Commented] (CASSANDRA-12181) Include table name in "Cannot get comparator" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393307#comment-15393307 ] sankalp kohli commented on CASSANDRA-12181: --- [~snazy] Can we please get the v3 committed > Include table name in "Cannot get comparator" exception > --- > > Key: CASSANDRA-12181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12181 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: sankalp kohli >Priority: Trivial > Attachments: CASSANDRA-12181-3.0_v2.txt, CASSANDRA-12181_3.0-v3.txt, > CASSANDRA-12181_3.0.txt > > > Having table name will help in debugging the following exception. > ERROR [MutationStage:xx] CassandraDaemon.java (line 199) Exception in thread > Thread[MutationStage:3788,5,main] > clusterName=itms8shared20 > java.lang.RuntimeException: Cannot get comparator 2 in > org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type). > > This might be due to a mismatch between the schema and the data read -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7384) Collect metrics on queries by consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393303#comment-15393303 ] sankalp kohli commented on CASSANDRA-7384: -- cc [~snazy] Can we commit this please > Collect metrics on queries by consistency level > --- > > Key: CASSANDRA-7384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7384 > Project: Cassandra > Issue Type: Improvement >Reporter: Vishy Kasar >Assignee: sankalp kohli >Priority: Minor > Fix For: 3.x > > Attachments: CASSANDRA-7384_3.0_v2.txt > > > We had cases where cassandra client users thought that they were doing > queries at one consistency level but turned out to be not correct. It will be > good to collect metrics on number of queries done at various consistency > level on the server. See the equivalent JIRA on java driver: > https://datastax-oss.atlassian.net/browse/JAVA-354 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12260) dtest failure in topology_test.TestTopology.decommissioned_node_cant_rejoin_test
[ https://issues.apache.org/jira/browse/CASSANDRA-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393301#comment-15393301 ] Joel Knighton commented on CASSANDRA-12260: --- That definitely seems to be the problem. The node should eventually shut down - after that message is printed, it just needs to execute the StorageService shutdown hook (and the JVM to exit). How long we should need to wait for that is a good question - evidently, it can be quite slow on CI. That said, it takes about two tenths of a second on my machine. If we're passing the thirty seconds here with no other symptoms (and that's what I see so far), there is something going pretty poorly in either C* or the test environment, and it might be better to investigate rather than change the test. To be more helpful in debugging this, I'd need trace level logging. Unfortunately, due to [CASSANDRA-12011], we lose logging in the shutdown hook, so we'd need a hacky fix to do that. I can do some or all of 1) a hacky branch fixing [CASSANDRA-12011], 2) running with trace logging on CI to try to repro, 3) analyzing those results. > dtest failure in > topology_test.TestTopology.decommissioned_node_cant_rejoin_test > > > Key: CASSANDRA-12260 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12260 > Project: Cassandra > Issue Type: Test >Reporter: Philip Thompson >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/cassandra-3.9_novnode_dtest/14/testReport/topology_test/TestTopology/decommissioned_node_cant_rejoin_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12294) LDAP Authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-12294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kleviansky updated CASSANDRA-12294: -- Description: Addition of an LDAP authentication plugin, in tree, along side the default authenticator, so that Cassandra can leverage existing LDAP-speaking servers to manage user logins. DSE offers this: [Enabling LDAP authentication | https://docs.datastax.com/en/datastax_enterprise/4.6/datastax_enterprise/sec/secLdapEnabling.html], but does not exist in vanilla C* as far as I can tell. Ideally would like to introduce this as part of the 2.2.x branch, as this is what is currently running in client production environment, and where it is needed at the moment. Would aim for support of at least Microsoft Active Directory running on Windows Server 2012. was: Addition of an LDAP authentication plugin, in tree, along side the default authenticator, so that Cassandra can leverage existing LDAP-speaking servers to manage user logins. Ideally would like to introduce this as part of the 2.2.x branch, as this is what is currently running in client production environment, and where it is needed at the moment. > LDAP Authentication > --- > > Key: CASSANDRA-12294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12294 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Daniel Kleviansky >Assignee: Daniel Kleviansky >Priority: Minor > Labels: security > Fix For: 2.2.x, 3.x > > > Addition of an LDAP authentication plugin, in tree, along side the default > authenticator, so that Cassandra can leverage existing LDAP-speaking servers > to manage user logins. > DSE offers this: [Enabling LDAP authentication | > https://docs.datastax.com/en/datastax_enterprise/4.6/datastax_enterprise/sec/secLdapEnabling.html], > but does not exist in vanilla C* as far as I can tell. > Ideally would like to introduce this as part of the 2.2.x branch, as this is > what is currently running in client production environment, and where it is > needed at the moment. > Would aim for support of at least Microsoft Active Directory running on > Windows Server 2012. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12294) LDAP Authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-12294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kleviansky updated CASSANDRA-12294: -- Description: Addition of an LDAP authentication plugin, in tree, along side the default authenticator, so that Cassandra can leverage existing LDAP-speaking servers to manage user logins. Ideally would like to introduce this as part of the 2.2.x branch, as this is what is currently running in client production environment, and where it is needed at the moment. was:Addition of an LDAP authentication plugin, in tree, along side the default authenticator, so that Cassandra can leverage existing LDAP-speaking servers to manage user logins. > LDAP Authentication > --- > > Key: CASSANDRA-12294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12294 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Daniel Kleviansky >Assignee: Daniel Kleviansky >Priority: Minor > Labels: security > Fix For: 2.2.x, 3.x > > > Addition of an LDAP authentication plugin, in tree, along side the default > authenticator, so that Cassandra can leverage existing LDAP-speaking servers > to manage user logins. > Ideally would like to introduce this as part of the 2.2.x branch, as this is > what is currently running in client production environment, and where it is > needed at the moment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12294) LDAP Authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-12294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kleviansky updated CASSANDRA-12294: -- Fix Version/s: (was: 4.x) 3.x 2.2.x > LDAP Authentication > --- > > Key: CASSANDRA-12294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12294 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Daniel Kleviansky >Assignee: Daniel Kleviansky >Priority: Minor > Labels: security > Fix For: 2.2.x, 3.x > > > Addition of an LDAP authentication plugin, in tree, along side the default > authenticator, so that Cassandra can leverage existing LDAP-speaking servers > to manage user logins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12294) LDAP Authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-12294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-12294: - Description: Addition of an LDAP authentication plugin, in tree, along side the default authenticator, so that Cassandra can leverage existing LDAP-speaking servers to manage user logins. (was: Addition of an LDAP authentication plugin, so that Cassandra can leverage existing LDAP-speaking servers to manage user logins.) > LDAP Authentication > --- > > Key: CASSANDRA-12294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12294 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Daniel Kleviansky >Assignee: Daniel Kleviansky >Priority: Minor > Labels: security > Fix For: 4.x > > > Addition of an LDAP authentication plugin, in tree, along side the default > authenticator, so that Cassandra can leverage existing LDAP-speaking servers > to manage user logins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12294) LDAP Authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-12294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-12294: - Fix Version/s: 4.x > LDAP Authentication > --- > > Key: CASSANDRA-12294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12294 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Daniel Kleviansky >Assignee: Daniel Kleviansky >Priority: Minor > Labels: security > Fix For: 4.x > > > Addition of an LDAP authentication plugin, so that Cassandra can leverage > existing LDAP-speaking servers to manage user logins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12294) LDAP Authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-12294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-12294: - Component/s: Distributed Metadata > LDAP Authentication > --- > > Key: CASSANDRA-12294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12294 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Daniel Kleviansky >Assignee: Daniel Kleviansky >Priority: Minor > Labels: security > > Addition of an LDAP authentication plugin, so that Cassandra can leverage > existing LDAP-speaking servers to manage user logins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12294) LDAP Authentication
Daniel Kleviansky created CASSANDRA-12294: - Summary: LDAP Authentication Key: CASSANDRA-12294 URL: https://issues.apache.org/jira/browse/CASSANDRA-12294 Project: Cassandra Issue Type: New Feature Reporter: Daniel Kleviansky Assignee: Daniel Kleviansky Priority: Minor Addition of an LDAP authentication plugin, so that Cassandra can leverage existing LDAP-speaking servers to manage user logins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: push down logging code to where it's used
Repository: cassandra
Updated Branches:
refs/heads/trunk c8a365309 -> 0f6461849
push down logging code to where it's used
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0f646184
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0f646184
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0f646184
Branch: refs/heads/trunk
Commit: 0f6461849c0acf146a019094dce55249113678b5
Parents: c8a3653
Author: Dave Brosius
Authored: Tue Jul 26 00:53:47 2016 -0400
Committer: Dave Brosius
Committed: Tue Jul 26 00:53:47 2016 -0400
--
src/java/org/apache/cassandra/tools/JsonTransformer.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0f646184/src/java/org/apache/cassandra/tools/JsonTransformer.java
--
diff --git a/src/java/org/apache/cassandra/tools/JsonTransformer.java
b/src/java/org/apache/cassandra/tools/JsonTransformer.java
index 3b98595..72008ab 100644
--- a/src/java/org/apache/cassandra/tools/JsonTransformer.java
+++ b/src/java/org/apache/cassandra/tools/JsonTransformer.java
@@ -176,7 +176,6 @@ public final class JsonTransformer
private void serializePartition(UnfilteredRowIterator partition)
{
-String key =
metadata.getKeyValidator().getString(partition.partitionKey().getKey());
try
{
json.writeStartObject();
@@ -223,6 +222,7 @@ public final class JsonTransformer
}
catch (IOException e)
{
+String key =
metadata.getKeyValidator().getString(partition.partitionKey().getKey());
logger.error("Fatal error parsing partition: {}", key, e);
}
}
[jira] [Commented] (CASSANDRA-12269) Faster write path
[
https://issues.apache.org/jira/browse/CASSANDRA-12269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393210#comment-15393210
]
Stefania commented on CASSANDRA-12269:
--
bq. This would mean we have to try catch every call vs just the ones that throw
checked exceptions.
No, we could have instantiated the call with RuntimeException as well as
IOException. Nevermind though, if you are happy with WrappedException let's
keep it, especially now that we have other wrapped classes anyway.
bq. ant microbench -Dbenchmark.name=MutationBench
Thanks, I has to do a realclean but it works now.
bq. The problem is none of these work with native types like int and boolean.
So unless I'm missing something the wrapper approach is what I went with.
That's true, the only way to avoid the wrapped classes is to implement the
lambda interface in a non-anonymous class, which is heavy, so let's go with the
wrapped classes. Did you mean to keep {{Wrapped}} even if it's not used?
Some more nits:
* Unused imports
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-75146ba408a51071a0b19ffdfbb2bb3cR35],
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-8336374a213ec8c7a6feca884793208eR30]
and
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-aa58d440e494ef966bf05abf4f6a9e61R26]
* The comment at [this
line|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-75146ba408a51071a0b19ffdfbb2bb3cR302]
is no longer relevant
* Indentation error
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-aa58d440e494ef966bf05abf4f6a9e61R88]
* Typo
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-4688f6b2ea84a0728a284ead1cf78adcR22]
Tests were aborted and it seems other jobs I launched in the last couple of
hours also did, so I cannot restart them for you right now but hopefully you
can restart them later and they'll work.
+1, subject to nits and clean test results, great work!
> Faster write path
> -
>
> Key: CASSANDRA-12269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12269
> Project: Cassandra
> Issue Type: Improvement
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.10
>
>
> The new storage engine (CASSANDRA-8099) has caused a regression in write
> performance. This ticket is to address it and bring 3.0 as close to 2.2 as
> possible. There are four main reasons for this I've discovered after much
> toil:
> 1. The cost of calculating the size of a serialized row is higher now since
> we no longer have the cell name and value managed as ByteBuffers as we did
> pre-3.0. That means we current re-serialize the row twice, once to calculate
> the size and once to write the data. This happens during the SSTable writes
> and was addressed in CASSANDRA-9766.
> Double serialization is also happening in CommitLog and the
> MessagingService. We need to apply the same techniques to these as we did to
> the SSTable serialization.
> 2. Even after fixing (1) there is still an issue with there being more GC
> pressure and CPU usage in 3.0 due to the fact that we encode everything from
> the {{Column}} to the {{Row}} to the {{Partition}} as a {{BTree}}.
> Specifically, the {{BTreeSearchIterator}} is used for all iterator() methods.
> Both these classes are useful for efficient removal and searching of the
> trees but in the case of SerDe we almost always want to simply walk the
> entire tree forwards or reversed and apply a function to each element. To
> that end, we can use lambdas and do this without any extra classes.
> 3. We use a lot of thread locals and check them constantly on the read/write
> paths. For client warnings, tracing, temp buffers, etc. We should move all
> thread locals to FastThreadLocals and threads to FastThreadLocalThreads.
> 4. We changed the memtable flusher defaults in 3.2 that caused a regression
> see: CASSANDRA-12228
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11465) dtest failure in cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393116#comment-15393116
]
Stefania commented on CASSANDRA-11465:
--
Thanks for the additional commit. I've incorporated it into the trunk patch and
discarded the futures commits on all branches except for trunk. I've also
rebased, squashed, prepared the patches for commit and relaunched the tests.
The multiplexer runs were aborted unfortunately, and I am not able to restart
them with the up-to-date commits, so would you mind doing that as well as
taking a another quick look at the final patches?
> dtest failure in cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test
> --
>
> Key: CASSANDRA-11465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11465
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Stefania
> Labels: dtest
>
> Failing on the following assert, on trunk only:
> {{self.assertEqual(len(errs[0]), 1)}}
> Is not failing consistently.
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1087/testReport/cql_tracing_test/TestCqlTracing/tracing_unknown_impl_test
> Failed on CassCI build trunk_dtest #1087
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12242) Could not create trigger
[ https://issues.apache.org/jira/browse/CASSANDRA-12242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393105#comment-15393105 ] RocWay Li commented on CASSANDRA-12242: --- Even though the TriggerExecutor instance is created in static context, it should be instantiated lazily, which happens at the fist call. > Could not create trigger > > > Key: CASSANDRA-12242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12242 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: RocWay Li > Attachments: DataTrigger.java > > > I tried cassandra 2.2.6 and 3.7, both of them could not create triggers. > It reports that the trigger class doesn't exist. But it actually does and is > at the right directory, the conf/triggers. > I debugged the source code, and I found that SEPWorker is used to create > triggers, but it's thread is not a secure thread, which should be managed by > cassandra's SecurityManager and belongs to SecurityThreadGroup. > When security validation failed, an exception will be thrown. That's direct > cause for creating triggers failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12242) Could not create trigger
[ https://issues.apache.org/jira/browse/CASSANDRA-12242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393080#comment-15393080 ] RocWay Li commented on CASSANDRA-12242: --- Yes, I did run on Windows. But I think the direct reason is that the SEPWorker's thread is not marked with SecurityThreadGroup. > Could not create trigger > > > Key: CASSANDRA-12242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12242 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: RocWay Li > Attachments: DataTrigger.java > > > I tried cassandra 2.2.6 and 3.7, both of them could not create triggers. > It reports that the trigger class doesn't exist. But it actually does and is > at the right directory, the conf/triggers. > I debugged the source code, and I found that SEPWorker is used to create > triggers, but it's thread is not a secure thread, which should be managed by > cassandra's SecurityManager and belongs to SecurityThreadGroup. > When security validation failed, an exception will be thrown. That's direct > cause for creating triggers failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12174) COPY FROM should raise error for non-existing input files
[
https://issues.apache.org/jira/browse/CASSANDRA-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393045#comment-15393045
]
Stefania commented on CASSANDRA-12174:
--
LGTM now, thank you!
I only have one suggestion, which is in the case where the glob expression
doesn't match any file, it should error out with "Can't open %r for reading: no
matching file found" rather than "Can't open %r for reading: file does not
exist".
I've applied your patch plus this minor change to a new branch and launched the
tests:
||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/12174-cqlsh]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12174-cqlsh-cqlsh-tests/]|
If the tests are OK we can commit this.
> COPY FROM should raise error for non-existing input files
> -
>
> Key: CASSANDRA-12174
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12174
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Stefan Podkowinski
>Assignee: Hiroyuki Nishi
>Priority: Minor
> Labels: lhf
> Attachments: CASSANDRA-12174-trunk.patch
>
>
> Currently the CSV COPY FROM command will not raise any error for non-existing
> paths. Instead only "0 rows imported" will be shown as result.
> As the COPY FROM command is often used for tutorials and getting started
> guides, I'd suggest to give a clear error message in case of a missing input
> file. Without such error it can be confusing for the user to see the command
> actually finish, without any clues why no rows have been imported.
> {noformat}
> CREATE KEYSPACE test
> WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 1
> };
> USE test;
> CREATE TABLE airplanes (
> name text PRIMARY KEY,
> manufacturer ascii,
> year int,
> mach float
> );
> COPY airplanes (name, manufacturer, year, mach) FROM '/tmp/1234-doesnotexist';
> Using 3 child processes
> Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
> Processed: 0 rows; Rate: 0 rows/s; Avg. rate: 0 rows/s
> 0 rows imported from 0 files in 0.216 seconds (0 skipped).
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12278) Cassandra not working with Java 8u102 on Windows
[ https://issues.apache.org/jira/browse/CASSANDRA-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393011#comment-15393011 ] Thomas Atwood commented on CASSANDRA-12278: --- Hi [~JoshuaMcKenzie], thanks for addressing so quickly. Do you know when the patch will be introduced into the distribution? > Cassandra not working with Java 8u102 on Windows > > > Key: CASSANDRA-12278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12278 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Windows 10 Enterprise with Cassandra 3.7 and JDK 8u102 >Reporter: Thomas Atwood >Assignee: Joshua McKenzie > Attachments: 12278_v1.txt, Error from 2nd PC.png, Error with Java > version prompt too.png, Java 8u102 issue.png > > > With the latest upgrade of Java to 8u102, Cassandra will no longer run and > states "Cassandra 3.0 and later require Java 8u40 or later. Please see > attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12292) Wrong buffer size after CASSANDRA-11580
[ https://issues.apache.org/jira/browse/CASSANDRA-12292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393009#comment-15393009 ] Stefania commented on CASSANDRA-12292: -- +1, and sorry I missed this during the review of 11580. The CI runs were aborted so I've restarted them. Feel free to commit once the CI results are available. > Wrong buffer size after CASSANDRA-11580 > --- > > Key: CASSANDRA-12292 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12292 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Trivial > Fix For: 3.x > > > CASSANDRA-11580 refactored around SegmentedFile(now FileHandle) in > o.a.c.io.util, but it introduced a bug in setting buffer size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12291) dtest failure in json_test.JsonFullRowInsertSelect.pkey_requirement_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392917#comment-15392917
]
Stefania commented on CASSANDRA-12291:
--
Same explanation as for CASSANDRA-12290, dtest and c* code got out-of-sync. It
should pass with the next run.
> dtest failure in json_test.JsonFullRowInsertSelect.pkey_requirement_test
>
>
> Key: CASSANDRA-12291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12291
> 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/354/testReport/json_test/JsonFullRowInsertSelect/pkey_requirement_test
> {code}
> Error Message
> Doctest failed! Captured output:
> **
> Line 25, in pkey_requirement_test
> Failed example:
> cqlsh_err_print('''INSERT INTO primitive_type_test JSON '{"col1": "bar"}'
> ''')
> Expected:
> :2:InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Invalid null value in condition for column key1"
>
> Got:
> :2:InvalidRequest: code=2200 [Invalid query] message="Invalid null
> value in condition for column key1"
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12290) dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_describe
[
https://issues.apache.org/jira/browse/CASSANDRA-12290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392915#comment-15392915
]
Stefania commented on CASSANDRA-12290:
--
This failed because the tests ran with the latest dtest code, which includes
the PR for CASSANDRA-11850, but without the CASSANDRA-11850 commit on trunk.
Unsure how since I merged the PR after committing the c* patch. Regardless, it
should pass with the next run.
> dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_describe
>
>
> Key: CASSANDRA-12290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12290
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/354/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe
> {code}
> Error Message
> Lists differ: ["CREATE KEYSPACE test WITH re... != ["CREATE KEYSPACE test
> WITH re...
> First differing element 9:
> AND cdc = false
> {code}
> Related Failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/354/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe_mv/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12041) Add CDC to describe table
[
https://issues.apache.org/jira/browse/CASSANDRA-12041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania resolved CASSANDRA-12041.
--
Resolution: Fixed
Fix Version/s: (was: 3.x)
3.9
CASSANDRA-11850 has been committed, closing this.
> Add CDC to describe table
> -
>
> Key: CASSANDRA-12041
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12041
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tools
>Reporter: Carl Yeksigian
>Assignee: Stefania
> Labels: client-impacting
> Fix For: 3.9
>
>
> Currently we do not output CDC with {{DESCRIBE TABLE}}, but should include
> that for 3.8+ tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12284) Cqlsh not supporting Copy command
[ https://issues.apache.org/jira/browse/CASSANDRA-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392898#comment-15392898 ] Stefania commented on CASSANDRA-12284: -- Thank you! > Cqlsh not supporting Copy command > - > > Key: CASSANDRA-12284 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12284 > Project: Cassandra > Issue Type: Bug > Components: CQL > Environment: Debian and OSX(yosemite) >Reporter: Abhinav Johri > Fix For: 3.3 > > > I installed cqlsh for my cassandra server using pip command. > I wanted to copy a table as CSV to my local system so I used COPY TO command > but it threw me the following error. > Traceback (most recent call last): > File "/usr/local/bin/cqlsh", line 1133, in onecmd > self.handle_statement(st, statementtext) > File "/usr/local/bin/cqlsh", line 1170, in handle_statement > return custom_handler(parsed) > File "/usr/local/bin/cqlsh", line 1837, in do_copy > rows = self.perform_csv_export(ks, cf, columns, fname, opts) > File "/usr/local/bin/cqlsh", line 1956, in perform_csv_export > csv_options, dialect_options, unrecognized_options = > copyutil.parse_options(self, opts) > AttributeError: 'module' object has no attribute 'parse_options' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12282) SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure
[ https://issues.apache.org/jira/browse/CASSANDRA-12282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392896#comment-15392896 ] Stefania commented on CASSANDRA-12282: -- Thanks Joel. I'm taking this since it is indeed the same root cause as CASSANDRA-12293, and I originally created these tests, so I should have a better chance at understanding what the problem is. > SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure > > > Key: CASSANDRA-12282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12282 > Project: Cassandra > Issue Type: Test >Reporter: Joshua McKenzie >Assignee: Stefania > Labels: unittest > > Error Message > expected:<3> but was:<4> > Stacktrace > junit.framework.AssertionFailedError: expected:<3> but was:<4> > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.executeAndCheck(SSTablesIteratedTest.java:45) > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:348) > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:312) > [Failure|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.miscellaneous/SSTablesIteratedTest/testDeletionOnIndexedSSTableASC_compression/] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12282) SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure
[ https://issues.apache.org/jira/browse/CASSANDRA-12282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefania reassigned CASSANDRA-12282: Assignee: Stefania (was: Marcus Eriksson) > SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure > > > Key: CASSANDRA-12282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12282 > Project: Cassandra > Issue Type: Test >Reporter: Joshua McKenzie >Assignee: Stefania > Labels: unittest > > Error Message > expected:<3> but was:<4> > Stacktrace > junit.framework.AssertionFailedError: expected:<3> but was:<4> > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.executeAndCheck(SSTablesIteratedTest.java:45) > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:348) > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:312) > [Failure|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.miscellaneous/SSTablesIteratedTest/testDeletionOnIndexedSSTableASC_compression/] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12282) SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure
[ https://issues.apache.org/jira/browse/CASSANDRA-12282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392837#comment-15392837 ] Joel Knighton commented on CASSANDRA-12282: --- When looking at these failures, I figured it was the same root cause as [CASSANDRA-12293]. It may make sense to move these to the same Assignee. > SSTablesIteratedTest.testDeletionOnIndexedSSTableASC-compression failure > > > Key: CASSANDRA-12282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12282 > Project: Cassandra > Issue Type: Test >Reporter: Joshua McKenzie >Assignee: Marcus Eriksson > Labels: unittest > > Error Message > expected:<3> but was:<4> > Stacktrace > junit.framework.AssertionFailedError: expected:<3> but was:<4> > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.executeAndCheck(SSTablesIteratedTest.java:45) > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:348) > at > org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnIndexedSSTableASC(SSTablesIteratedTest.java:312) > [Failure|http://cassci.datastax.com/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.miscellaneous/SSTablesIteratedTest/testDeletionOnIndexedSSTableASC_compression/] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12293) SSTablesIteratedTest.testDeletionOnOverlappingIndexedSSTable-compression is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-12293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392834#comment-15392834
]
Joel Knighton commented on CASSANDRA-12293:
---
When looking at these failures, I figured it was the same root cause as
[CASSANDRA-12282]. It may make sense to move these to the same Assignee.
> SSTablesIteratedTest.testDeletionOnOverlappingIndexedSSTable-compression is
> flaky
> -
>
> Key: CASSANDRA-12293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12293
> Project: Cassandra
> Issue Type: Test
>Reporter: Joshua McKenzie
>Assignee: Stefania
>Priority: Minor
> Labels: unittest
>
> [History|https://cassci.datastax.com/view/cassandra-3.9/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.miscellaneous/SSTablesIteratedTest/testDeletionOnOverlappingIndexedSSTable_compression/history/]
> Error Message
> expected:<2> but was:<3>
> Stacktrace
> {noformat}
> junit.framework.AssertionFailedError: expected:<2> but was:<3>
> at
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.executeAndCheck(SSTablesIteratedTest.java:45)
> at
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnOverlappingIndexedSSTable(SSTablesIteratedTest.java:435)
> at
> org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnOverlappingIndexedSSTable(SSTablesIteratedTest.java:361)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392813#comment-15392813
]
Carlos Abad edited comment on CASSANDRA-9608 at 7/25/16 11:11 PM:
--
About the new formatting for Java 9 Version String, we can use the ticket for
the [Verona Project|https://bugs.openjdk.java.net/browse/JDK-8061493] as a
reference.
Grizzly already updated its source code to accommodate the
[change|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java]
was (Author: carlosabad):
About the new formatting for Java 9 Version String take a look at the [Verona
Project|https://bugs.openjdk.java.net/browse/JDK-8061493].
Grizzly already updated its source code to accommodate the
[change|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java]
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392813#comment-15392813
]
Carlos Abad edited comment on CASSANDRA-9608 at 7/25/16 11:10 PM:
--
About the new formatting for Java 9 Version String take a look at the [Verona
Project|https://bugs.openjdk.java.net/browse/JDK-8061493].
Grizzly already updated its source code to accommodate the
[change|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java]
was (Author: carlosabad):
About the new formatting for Java 9 Version String, find a "more official"
specification for the new format
[here|https://bugs.openjdk.java.net/browse/JDK-8061493].
Grizzly already updated its source code to accommodate the change
([link|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java])
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392813#comment-15392813
]
Carlos Abad edited comment on CASSANDRA-9608 at 7/25/16 11:08 PM:
--
About the new formatting for Java 9 Version String, you can find a "more
official" specification for the new format
[here|https://bugs.openjdk.java.net/browse/JDK-8061493].
Grizzly already updated its source code to accommodate the change
([link|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java])
was (Author: carlosabad):
About the new formatting for Java 9 Version String, find a "more official"
specification for the new format
[here|https://bugs.openjdk.java.net/browse/JDK-8061493].
Grizzly already updated its source code to accommodate the change
([link|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java])
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392813#comment-15392813
]
Carlos Abad edited comment on CASSANDRA-9608 at 7/25/16 11:08 PM:
--
About the new formatting for Java 9 Version String, find a "more official"
specification for the new format
[here|https://bugs.openjdk.java.net/browse/JDK-8061493].
Grizzly already updated its source code to accommodate the change
([link|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java])
was (Author: carlosabad):
About the new formatting for Java 9 Version String, you can find a "more
official" specification for the new format
[here|https://bugs.openjdk.java.net/browse/JDK-8061493].
Grizzly already updated its source code to accommodate the change
([link|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java])
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392813#comment-15392813
]
Carlos Abad edited comment on CASSANDRA-9608 at 7/25/16 11:07 PM:
--
About the new formatting for Java 9 Version String, find a "more official"
specification for the new format
[here|https://bugs.openjdk.java.net/browse/JDK-8061493].
Grizzly already updated its source code to accommodate the change
([link|https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java])
was (Author: carlosabad):
About the new formatting for Java 9 Version String, find a "more official"
specification for the new format here:
https://bugs.openjdk.java.net/browse/JDK-8061493.
Grizzly already updated its source code to accommodate the change
(https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java)
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392813#comment-15392813
]
Carlos Abad commented on CASSANDRA-9608:
About the new formatting for Java 9 Version String, find a "more official"
specification for the new format here:
https://bugs.openjdk.java.net/browse/JDK-8061493.
Grizzly already updated its source code to accommodate the change
(https://github.com/GrizzlyNIO/grizzly-mirror/blob/ba1c00d568804c6443b952b8980788337b95a330/modules/grizzly/src/main/java/org/glassfish/grizzly/utils/JdkVersion.java)
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12229) Move streaming to non-blocking IO and netty (streaming 2.1)
[
https://issues.apache.org/jira/browse/CASSANDRA-12229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392800#comment-15392800
]
Paulo Motta commented on CASSANDRA-12229:
-
It seems to me that sstable-based streaming will potentially have higher
throughput than mutation-based streaming (since it skips sender ser/des
overhead and potentially component construction if you transfer whole
sstables), and may be preferable for bootstrapping specially of dense nodes in
a first moment. While we want to ideally/eventually have a single path for
bootstrap and repair streaming, from my understanding the main goal of
CASSANDRA-8911 is to make repair more robust and efficient, while having a
single path for that and bootstrap streaming would be a secondary goal to be
pursued in a different ticket, so I don't see that as immediately superseding
this.
With that said, while I agree we should synchronize between this and
CASSANDRA-8911, I think we can still pursue both in parallel, specially if this
is a requirement of CASSANDRA-8457, but initially focusing on porting the
current protocol (1, 2, 3) to NIO and applying improvements where
straightforward, while leaving more complex improvements (4, 5) for other
tickets so we can re-evaluate them after having more progress on
CASSANDRA-8911. Even if we advance with mutation-based streaming on
CASSANDRA-8911 we can still use this to benchmark bootstrap performance with
both approaches.
> Move streaming to non-blocking IO and netty (streaming 2.1)
> ---
>
> Key: CASSANDRA-12229
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12229
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
>Reporter: Jason Brown
>Assignee: Jason Brown
> Fix For: 4.0
>
>
> As followup work to CASSANDRA-8457, we need to move streaming to use netty.
> Streaming 2.0 (CASSANDRA-5286) brought many good improvements to how files
> are transferred between nodes in a cluster. However, the low-level details of
> the current streaming implementation does not line up nicely with a
> non-blocking model, so I think this is a good time to review some of those
> details and add in additional goodness. The current implementation assumes a
> sequential or "single threaded" approach to the sending of stream messages as
> well as the transfer of files. In short, after several iterative prototypes,
> I propose the following:
> 1) use a single bi-diredtional connection (instead of requiring to two
> sockets & two threads)
> 2) send the "non-file" {{StreamMessage}} s (basically anything not
> {{OutboundFileMessage}}) via the normal internode messaging. This will
> require a slight bit more management of the session (the ability to look up a
> {{StreamSession}} from a static function on {{StreamManager}}, but we have
> have most of the pieces we need for this already.
> 3) switch to a non-blocking IO model (facilitated via netty)
> 4) Allow files to be streamed in parallel (CASSANDRA-4663) - this should just
> be a thing already
> 5) If the entire sstable is to streamed, in addition to the DATA component,
> transfer all the components of the sstable (primary index, bloom filter,
> stats, and so on). This way we can avoid the CPU and GC pressure from
> deserializing the stream into objects. File streaming then amounts to a
> block-level transfer.
> Note: The progress/results of CASSANDRA-11303 will need to be reflected here,
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12008) Make decommission operations resumable
[
https://issues.apache.org/jira/browse/CASSANDRA-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392776#comment-15392776
]
Kaide Mu commented on CASSANDRA-12008:
--
Here's 3 operations I'm proposing for STREAMED_RANGES:
- updateStreamedRanges(String description, InetAddress endpoint, String
keyspace, Set> range)
- MultiMap> getAvailableRanges(String keyspace, IPartitioner
partitioner)
- void resetAvailableRanges()
Briefly the flow is:
# StreamPlan.transferRanges(InetAddress to, InetAddress connecting, String
keyspace, Collection> ranges)
# StreamSession.addTransferRanges(String keyspace, Collection>
ranges, Collection columnFamilies, boolean flushTables, long repairedAt)
# StreamSession.addTransferFiles(Collection
sstableDetails)
# And finally StreamTransferTask.complete which will make use of
{{updateStreamedRanges}}
As you can see {{updateStreamedRanges}} will need description, endpoint,
keyspace and range, and when we reached 4, we can only obtain description and
endpoint from {{StreamTransferTask.session}}, therefore some information is
"lost" and {{updateStreamedRanges}} cannot be accomplished. Thus additionally I
propose {{StreamTransferTask}} to receive keyspace and range, for that we may
need to create a new {{addTransferFiles}} to keep a record of keyspace and
transfer ranges.
WDYT? [~pauloricardomg] [~yukim]
> Make decommission operations resumable
> --
>
> Key: CASSANDRA-12008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12008
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
>Reporter: Tom van der Woerdt
>Assignee: Kaide Mu
>Priority: Minor
>
> We're dealing with large data sets (multiple terabytes per node) and
> sometimes we need to add or remove nodes. These operations are very dependent
> on the entire cluster being up, so while we're joining a new node (which
> sometimes takes 6 hours or longer) a lot can go wrong and in a lot of cases
> something does.
> It would be great if the ability to retry streams was implemented.
> Example to illustrate the problem :
> {code}
> 03:18 PM ~ $ nodetool decommission
> error: Stream failed
> -- StackTrace --
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1310)
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:210)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:186)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:430)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:622)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:486)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:274)
> at java.lang.Thread.run(Thread.java:745)
> 08:04 PM ~ $ nodetool decommission
> nodetool: Unsupported operation: Node in LEAVING state; wait for status to
> become normal or restart
> See 'nodetool help' or 'nodetool help '.
> {code}
> Streaming failed, probably due to load :
> {code}
> ERROR [STREAM-IN-/] 2016-06-14 18:05:47,275 StreamSession.java:520 -
> [Stream #] Streaming error occurred
> java.net.SocketTimeoutException: null
> at
> sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211)
> ~[na:1.8.0_77]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.8.0_77]
> at
> java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385)
> ~[na:1.8.0_77]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:54)
> ~[apache-cassandra-3.0.6.jar:3.0.6]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:268)
> ~[apache-cassandra-3.0.6.jar:3.0.6]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77]
> {code}
> If implementing retries is not possible, can we have a 'nodetool decommission
> resume'?
--
This message was sent by Atlassian JIRA
(v6.3.4#63
[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.
[
https://issues.apache.org/jira/browse/CASSANDRA-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392752#comment-15392752
]
Philip Thompson commented on CASSANDRA-12236:
-
Russ is out sick, but I believe the answer is yes.
> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format
> after 3.0, you will
> see error messages such as:
> "java.lang.RuntimeException: Unknown column cdc during
> deserialization"
> in your system logs on a mixed-version cluster during upgrades. This
> error message
> is harmless and due to the 3.8 nodes having cdc added to their schema
> tables while
> the <3.8 nodes do not. This message should cease once all nodes are
> upgraded to 3.8.
> As always, refrain from schema changes during cluster upgrades.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.
[
https://issues.apache.org/jira/browse/CASSANDRA-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392749#comment-15392749
]
Joshua McKenzie commented on CASSANDRA-12236:
-
[~rhatch]: Can [~slebresne] simply prefix his branch name with 'upgrade' now to
get the upgrade suite run against it, or is there still some manual
intervention required on this?
> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format
> after 3.0, you will
> see error messages such as:
> "java.lang.RuntimeException: Unknown column cdc during
> deserialization"
> in your system logs on a mixed-version cluster during upgrades. This
> error message
> is harmless and due to the 3.8 nodes having cdc added to their schema
> tables while
> the <3.8 nodes do not. This message should cease once all nodes are
> upgraded to 3.8.
> As always, refrain from schema changes during cluster upgrades.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12293) SSTablesIteratedTest.testDeletionOnOverlappingIndexedSSTable-compression is flaky
Joshua McKenzie created CASSANDRA-12293:
---
Summary:
SSTablesIteratedTest.testDeletionOnOverlappingIndexedSSTable-compression is
flaky
Key: CASSANDRA-12293
URL: https://issues.apache.org/jira/browse/CASSANDRA-12293
Project: Cassandra
Issue Type: Test
Reporter: Joshua McKenzie
Assignee: Stefania
Priority: Minor
[History|https://cassci.datastax.com/view/cassandra-3.9/job/cassandra-3.9_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.miscellaneous/SSTablesIteratedTest/testDeletionOnOverlappingIndexedSSTable_compression/history/]
Error Message
expected:<2> but was:<3>
Stacktrace
{noformat}
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at
org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.executeAndCheck(SSTablesIteratedTest.java:45)
at
org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnOverlappingIndexedSSTable(SSTablesIteratedTest.java:435)
at
org.apache.cassandra.cql3.validation.miscellaneous.SSTablesIteratedTest.testDeletionOnOverlappingIndexedSSTable(SSTablesIteratedTest.java:361)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392717#comment-15392717
]
Carlos Abad edited comment on CASSANDRA-9608 at 7/25/16 9:44 PM:
-
Found a fix to the failed cipher tests. Need to install the Java JCE (Java
Cryptographic Extension). It's already bundled, but not enabled, with the JDK9
EA build. Find it here /lib/security/unlimited_policy/. If not there,
like when using Oracle Java 8, need to be downloaded and installed manually.
was (Author: carlosabad):
Found a fix to the failed cipher tests. Need to install the Java JCE (Java
Cryptographic Extension). It's already bundled -but not enabled- with the JDK9
EA build. Find it here /lib/security/unlimited_policy/. If not there
(like when using Oracle Java 8), need to be downloaded and installed manually.
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392717#comment-15392717
]
Carlos Abad commented on CASSANDRA-9608:
Found a fix to the failed cipher tests. Need to install the Java JCE -Java
Cryptographic Extension-. It's already bundled -but not enabled- with the JDK9
EA build. Find it here /lib/security/unlimited_policy/. If not there
-like when using Oracle Java 8-, need to be downloaded and installed manually.
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9608) Support Java 9
[
https://issues.apache.org/jira/browse/CASSANDRA-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392717#comment-15392717
]
Carlos Abad edited comment on CASSANDRA-9608 at 7/25/16 9:44 PM:
-
Found a fix to the failed cipher tests. Need to install the Java JCE (Java
Cryptographic Extension). It's already bundled -but not enabled- with the JDK9
EA build. Find it here /lib/security/unlimited_policy/. If not there
(like when using Oracle Java 8), need to be downloaded and installed manually.
was (Author: carlosabad):
Found a fix to the failed cipher tests. Need to install the Java JCE -Java
Cryptographic Extension-. It's already bundled -but not enabled- with the JDK9
EA build. Find it here /lib/security/unlimited_policy/. If not there
-like when using Oracle Java 8-, need to be downloaded and installed manually.
> Support Java 9
> --
>
> Key: CASSANDRA-9608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9608
> Project: Cassandra
> Issue Type: Task
>Reporter: Robert Stupp
>Priority: Minor
>
> This ticket is intended to group all issues found to support Java 9 in the
> future.
> From what I've found out so far:
> * Maven dependency {{com.sun:tools:jar:0}} via cobertura cannot be resolved.
> It can be easily solved using this patch:
> {code}
> - artifactId="cobertura"/>
> + artifactId="cobertura">
> +
> +
> {code}
> * Another issue is that {{sun.misc.Unsafe}} no longer contains the methods
> {{monitorEnter}} + {{monitorExit}}. These methods are used by
> {{o.a.c.utils.concurrent.Locks}} which is only used by
> {{o.a.c.db.AtomicBTreeColumns}}.
> I don't mind to start working on this yet since Java 9 is in a too early
> development phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11927) dtest failure in replication_test.ReplicationTest.simple_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392663#comment-15392663
]
Paulo Motta commented on CASSANDRA-11927:
-
While I agree that this is not a bug and is working as intended, I still think
we should rethink this behavior on trunk and throw an RTE if CFS not found
during a mutation for the following reasons:
* In most other places we throw an exception if a table is not found during a
request
([SelectStatement|https://github.com/apache/cassandra/blob/087264f29c309ed0b2a18cc20b79016a05847f1c/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L724],
[thrift's
internal_insert|https://github.com/apache/cassandra/blob/fed476f9c049128674841d1c46b868979352b1a5/src/java/org/apache/cassandra/thrift/CassandraServer.java#L865],
or any caller of
[Keyspace.getColumnFamilyStore|https://github.com/apache/cassandra/blob/3c00a0674a4e8b71ae25439dc2a0dece2f460d21/src/java/org/apache/cassandra/db/Keyspace.java#L192]),
so I don't see why not being consistent and do it here.
* This would provide additional protection/assertion against bugs like
CASSANDRA-12083 and CASSANDRA-11027.
* While no one reported this as a problem, it could've been silently ignored,
since only a log message is print, while this will ensure that the request will
fail and the potential problem will be more easily noticed/reported.
bq. Second, the way this is implemented here means that any updates obtained
from the iterator before a missing cf is encountered, would be applied but the
RTE would still be thrown which is pretty confusing.
While this might be weird, it is exactly what happens if an error or unexpected
condition is found mid-update. What is unacceptable IMO is returning success
when not all updates were successfully applied, thus potentially breaking
consistency guarantees. So, unless there is another reason not to do it I don't
see why not improve this here.
> dtest failure in replication_test.ReplicationTest.simple_test
> -
>
> Key: CASSANDRA-11927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11927
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Paulo Motta
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log,
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/387/testReport/replication_test/ReplicationTest/simple_test
> Failed on CassCI build trunk_novnode_dtest #387
> Logs are attached.
> Unexpected error in question:
> {code}
> ERROR [SharedPool-Worker-1] 2016-05-30 16:00:17,211 Keyspace.java:504 -
> Attempting to mutate non-existant table 99f5be60-267f-11e6-ad5f-f13d771494ea
> (test.test)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10810) Make rebuild operations resumable
[ https://issues.apache.org/jira/browse/CASSANDRA-10810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392637#comment-15392637 ] Kaide Mu commented on CASSANDRA-10810: -- A new patch is available: https://github.com/riptano/cassandra-dtest/compare/master...kdmu:jira-10810?expand=1 > Make rebuild operations resumable > - > > Key: CASSANDRA-10810 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10810 > Project: Cassandra > Issue Type: Wish > Components: Streaming and Messaging >Reporter: Jeremy Hanna >Assignee: Kaide Mu > Fix For: 3.x > > > Related to CASSANDRA-8942, now that we can resume bootstrap operations, this > could also be possible with rebuild operations, such as when you bootstrap > new nodes in a completely new datacenter in two steps. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11465) dtest failure in cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392611#comment-15392611
]
Paulo Motta commented on CASSANDRA-11465:
-
New future-based approach LGTM. I added a [new
commit|https://github.com/pauloricardomg/cassandra/commit/7246dfbffcb99a6a3f54fef9f84e84072fa90e3c]
to the trunk version simplifying waitForPendingEvents to wait on a list of
{{CompletableFuture}} instead.
bq. Launched the tests again, the latest changes are in a separate commit so we
can choose which approach to use. I would prefer to use futures since it is
more accurate.
Since the no-op event solution is a bit simpler and less risky, I propose we
commit that for 2.2+ and commit the future-based version only to trunk as an
improvement. WDYT ?
Submitted 20x multiplexer run of {{cql_tracing_test.py:TestCqlTracing}} for 2.2
(no-op version) and trunk (future version):
*
[2.2|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/186/]
*
[trunk|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/185/]
> dtest failure in cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test
> --
>
> Key: CASSANDRA-11465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11465
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Stefania
> Labels: dtest
>
> Failing on the following assert, on trunk only:
> {{self.assertEqual(len(errs[0]), 1)}}
> Is not failing consistently.
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1087/testReport/cql_tracing_test/TestCqlTracing/tracing_unknown_impl_test
> Failed on CassCI build trunk_dtest #1087
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12292) Wrong buffer size after CASSANDRA-11580
[ https://issues.apache.org/jira/browse/CASSANDRA-12292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-12292: --- Reviewer: Stefania Fix Version/s: 3.x Status: Patch Available (was: Open) > Wrong buffer size after CASSANDRA-11580 > --- > > Key: CASSANDRA-12292 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12292 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Trivial > Fix For: 3.x > > > CASSANDRA-11580 refactored around SegmentedFile(now FileHandle) in > o.a.c.io.util, but it introduced a bug in setting buffer size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12292) Wrong buffer size after CASSANDRA-11580
[ https://issues.apache.org/jira/browse/CASSANDRA-12292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392548#comment-15392548 ] Yuki Morishita commented on CASSANDRA-12292: ||branch||testall||dtest|| |[12292|https://github.com/yukim/cassandra/tree/12292]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-12292-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-12292-dtest/lastCompletedBuild/testReport/]| > Wrong buffer size after CASSANDRA-11580 > --- > > Key: CASSANDRA-12292 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12292 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Trivial > > CASSANDRA-11580 refactored around SegmentedFile(now FileHandle) in > o.a.c.io.util, but it introduced a bug in setting buffer size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12292) Wrong buffer size after CASSANDRA-11580
Yuki Morishita created CASSANDRA-12292: -- Summary: Wrong buffer size after CASSANDRA-11580 Key: CASSANDRA-12292 URL: https://issues.apache.org/jira/browse/CASSANDRA-12292 Project: Cassandra Issue Type: Bug Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Trivial CASSANDRA-11580 refactored around SegmentedFile(now FileHandle) in o.a.c.io.util, but it introduced a bug in setting buffer size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12164) dtest failure in materialized_views_test.TestMaterializedViews.add_dc_after_mv_network_replication_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392541#comment-15392541
]
Joel Knighton commented on CASSANDRA-12164:
---
I agree that this looks like the same basic problem as [CASSANDRA-10978]. The
problem I found when I researched that issue was that flushes to disk were slow
- I picked 5 seconds because it was dramatically higher than the migration wait
times I had seen. We specified the migration wait period in the dtests because
we thought this was due to running multiple CCM nodes on a relatively small
host, so the problem wasn't likely to surface in real clusters. Hitting this
again could be due to a regression in time to flush the schema keyspace, or it
could be that I just never got lucky in my original investigation.
> dtest failure in
> materialized_views_test.TestMaterializedViews.add_dc_after_mv_network_replication_test
> ---
>
> Key: CASSANDRA-12164
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12164
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
> 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/trunk_offheap_dtest/309/testReport/materialized_views_test/TestMaterializedViews/add_dc_after_mv_network_replication_test
> Failed on CassCI build trunk_offheap_dtest #309
> {code}
> Standard Output
> Unexpected error in node4 log, error:
> ERROR [main] 2016-07-06 19:21:26,631 MigrationManager.java:164 - Migration
> task failed to complete
> {code}
> Related failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/423/testReport/materialized_views_test/TestMaterializedViews/add_node_after_mv_test/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11491) Split repair job into tasks per table
[ https://issues.apache.org/jira/browse/CASSANDRA-11491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-11491: Assignee: (was: Paulo Motta) Priority: Minor (was: Major) > Split repair job into tasks per table > - > > Key: CASSANDRA-11491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11491 > Project: Cassandra > Issue Type: Task > Components: Streaming and Messaging >Reporter: Paulo Motta >Priority: Minor > > We currently split a parent repair session into multiple repair sessions, one > per range. Each repair session is further split into multiple repair jobs, > one per table. > As we move into an auto-repair world with CASSANDRA-11190, with repair > settings per table, it will probably simplify things if we reason about > repair sessions on a per-table basis. > Besides simplifying current code, this will simplify adding more advanced > scheduling of repair tasks per table and other optimizations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12241) Error connecting to cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-12241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392299#comment-15392299
]
Eric Pedregosa commented on CASSANDRA-12241:
HI Alex,
It is not me who posted it. We are running on VMWare.
Thanks.
Eric
> Error connecting to cqlsh
> -
>
> Key: CASSANDRA-12241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12241
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Oracle Linux Server release 6.5
> Cassandra 3.0.8
> cqlsh 5.0.1
>Reporter: Eric Pedregosa
> Attachments: cassandra.log, cassandra.yaml.txt
>
>
> During Cassandra install we are experiencing this issue - "unable to connect
> to servers" when running cqlsh. Attached is the yaml config and log file.
> server 100.114.116.100
> [root@ushaplp00312la bin]# nodetool status
> Datacenter: USH
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns (effective) Host ID
>Rack
> UN 100.114.116.102 125.17 KB 256 32.1%
> b3366714-ecb3-46af-a3a1-f3b12648e358 RAC1
> UN 100.114.116.100 345.64 KB 256 33.4%
> 83dfbd38-9233-41db-812d-7cd1aa34401b RAC1
> UN 100.114.116.101 152.55 KB 256 34.5%
> b8011e64-266f-4f18-a381-5f6dd5816af0 RAC1
> [root@ushaplp00312la bin]# cqlsh
> Connection error: ('Unable to connect to any servers', {'127.0.0.1':
> error(111, "Tried connecting to [('127.0.0.1', 9042)]. Last error: Connection
> refused")})
> [root@ushaplp00312la ~]# cqlsh 100.114.116.100 9160
> Connection error: ('Unable to connect to any servers', {'100.114.116.100':
> ConnectionShutdown('Connection 100.114.116.100:9160 (closed)> is already closed',)})
> [root@ushaplp00312la ~]# lsof -i :9160
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> java42158 openplatform 66u IPv4 1889424 0t0 TCP
> ushaplp00312la.tfayd.com:apani1 (LISTEN)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10810) Make rebuild operations resumable
[
https://issues.apache.org/jira/browse/CASSANDRA-10810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392255#comment-15392255
]
Paulo Motta commented on CASSANDRA-10810:
-
It would be nice if you could execute the query before the successful rebuild
to make sure it will fail. Also, change the read query {{CL}} to {{LOCAL_ONE}}
to make sure it's being queried from the local dc only, otherwise the query
might go to dc1 if you use {{CL=ALL}}.
> Make rebuild operations resumable
> -
>
> Key: CASSANDRA-10810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10810
> Project: Cassandra
> Issue Type: Wish
> Components: Streaming and Messaging
>Reporter: Jeremy Hanna
>Assignee: Kaide Mu
> Fix For: 3.x
>
>
> Related to CASSANDRA-8942, now that we can resume bootstrap operations, this
> could also be possible with rebuild operations, such as when you bootstrap
> new nodes in a completely new datacenter in two steps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12008) Make decommission operations resumable
[
https://issues.apache.org/jira/browse/CASSANDRA-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392229#comment-15392229
]
Paulo Motta commented on CASSANDRA-12008:
-
bq. it seems StreamStateStore is not recording properly transferred ranges
(nothing is recorded). I guess everything is set-up correctly, would you mind
to taking a look?
It seems {{SessionCompleteEvent}} currently only exposes [requested
ranges|https://github.com/apache/cassandra/blob/3dcbe90e02440e6ee534f643c7603d50ca08482b/src/java/org/apache/cassandra/streaming/StreamEvent.java#L49],
which will be empty since decommission does not request any ranges, but
instead transfer its ranges to other nodes.
But it seems adding transferred ranges to {{SessionCompleteEvent}} will not be
sufficient, as it is possible for a leaving node to transfer a range to
multiple nodes (if there are 2 nodes leaving the ring at the same time, for
example), so we cannot mark the range as transferred when a session completes
with a particular peer. While this seem highly unlikely, it is a possible
scenario so we should probably protect against that. WDYT [~yukim] ?
My suggestion is to create a new system table {{streamed_ranges}} with the
following schema:
{noformat}
CREATE TABLE streamed_ranges (
operation text,
peer inet,
keyspace_name text,
ranges set,
PRIMARY KEY ((operation, keyspace_name), peer))
{noformat}
In this table we can store received or transferred ranges from any operation
(rebuild, bootstrap, stream) per peer, and deprecate the {{available_ranges}}
table in favor of this new table. With this we will be able to know if we can
skip streaming a particular range to/from a specific peer, and account for the
case where we stream a range to multiple peer, such as in decommission.
After that, we will probaby need to add transferred ranges to
{{StreamTransferTask}} so the transferred ranges can be added to
{{SessionCompleteEvent}}, so we can mark them in the {{streamed_ranges}} table.
> Make decommission operations resumable
> --
>
> Key: CASSANDRA-12008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12008
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
>Reporter: Tom van der Woerdt
>Assignee: Kaide Mu
>Priority: Minor
>
> We're dealing with large data sets (multiple terabytes per node) and
> sometimes we need to add or remove nodes. These operations are very dependent
> on the entire cluster being up, so while we're joining a new node (which
> sometimes takes 6 hours or longer) a lot can go wrong and in a lot of cases
> something does.
> It would be great if the ability to retry streams was implemented.
> Example to illustrate the problem :
> {code}
> 03:18 PM ~ $ nodetool decommission
> error: Stream failed
> -- StackTrace --
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1310)
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:210)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:186)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:430)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:622)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:486)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:274)
> at java.lang.Thread.run(Thread.java:745)
> 08:04 PM ~ $ nodetool decommission
> nodetool: Unsupported operation: Node in LEAVING state; wait for status to
> become normal or restart
> See 'nodetool help' or 'nodetool help '.
> {code}
> Streaming failed, probably due to load :
> {code}
> ERROR [STREAM-IN-/] 2016-06-14 18:05:47,275 StreamSession.java:520 -
> [Stream #] Streaming error occurred
> java.net.SocketTimeoutException: null
> at
> sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211)
> ~[na:1.8.0_77]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.8.0_77
[jira] [Commented] (CASSANDRA-12269) Faster write path
[
https://issues.apache.org/jira/browse/CASSANDRA-12269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392169#comment-15392169
]
T Jake Luciani commented on CASSANDRA-12269:
bq. Rather than creating utility classes for setting values we can use
references or optionals or, better, declare a small class that implements
the interface and store these values as class fields.
The problem is none of these work with native types like int and boolean. So
unless I'm missing something the wrapper approach is what I went with.
> Faster write path
> -
>
> Key: CASSANDRA-12269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12269
> Project: Cassandra
> Issue Type: Improvement
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.10
>
>
> The new storage engine (CASSANDRA-8099) has caused a regression in write
> performance. This ticket is to address it and bring 3.0 as close to 2.2 as
> possible. There are four main reasons for this I've discovered after much
> toil:
> 1. The cost of calculating the size of a serialized row is higher now since
> we no longer have the cell name and value managed as ByteBuffers as we did
> pre-3.0. That means we current re-serialize the row twice, once to calculate
> the size and once to write the data. This happens during the SSTable writes
> and was addressed in CASSANDRA-9766.
> Double serialization is also happening in CommitLog and the
> MessagingService. We need to apply the same techniques to these as we did to
> the SSTable serialization.
> 2. Even after fixing (1) there is still an issue with there being more GC
> pressure and CPU usage in 3.0 due to the fact that we encode everything from
> the {{Column}} to the {{Row}} to the {{Partition}} as a {{BTree}}.
> Specifically, the {{BTreeSearchIterator}} is used for all iterator() methods.
> Both these classes are useful for efficient removal and searching of the
> trees but in the case of SerDe we almost always want to simply walk the
> entire tree forwards or reversed and apply a function to each element. To
> that end, we can use lambdas and do this without any extra classes.
> 3. We use a lot of thread locals and check them constantly on the read/write
> paths. For client warnings, tracing, temp buffers, etc. We should move all
> thread locals to FastThreadLocals and threads to FastThreadLocalThreads.
> 4. We changed the memtable flusher defaults in 3.2 that caused a regression
> see: CASSANDRA-12228
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12269) Faster write path
[
https://issues.apache.org/jira/browse/CASSANDRA-12269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392165#comment-15392165
]
T Jake Luciani commented on CASSANDRA-12269:
Thanks for the reviews!
I've pushed a commit with most of the feedback addressed and restarted the
tests.
bq. We can get rid of WrappedException if we define this interface
This would mean we have to try catch every call vs just the ones that throw
checked exceptions. I've done some researching and this wrapped exception
seems to be the preferred way of dealing with this issue, and I'm ok with it.
bq. Isn't 1 MB a bit too much for MAX_RECYCLE_BUFFER_SIZE in DataOutputBuffer?
I added a property we can set if this ends up being too much, but I think
unless you have huge rows it's not going to affect you.
bq. How do we run MutationBench?
ant microbench -Dbenchmark.name=MutationBench
> Faster write path
> -
>
> Key: CASSANDRA-12269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12269
> Project: Cassandra
> Issue Type: Improvement
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.10
>
>
> The new storage engine (CASSANDRA-8099) has caused a regression in write
> performance. This ticket is to address it and bring 3.0 as close to 2.2 as
> possible. There are four main reasons for this I've discovered after much
> toil:
> 1. The cost of calculating the size of a serialized row is higher now since
> we no longer have the cell name and value managed as ByteBuffers as we did
> pre-3.0. That means we current re-serialize the row twice, once to calculate
> the size and once to write the data. This happens during the SSTable writes
> and was addressed in CASSANDRA-9766.
> Double serialization is also happening in CommitLog and the
> MessagingService. We need to apply the same techniques to these as we did to
> the SSTable serialization.
> 2. Even after fixing (1) there is still an issue with there being more GC
> pressure and CPU usage in 3.0 due to the fact that we encode everything from
> the {{Column}} to the {{Row}} to the {{Partition}} as a {{BTree}}.
> Specifically, the {{BTreeSearchIterator}} is used for all iterator() methods.
> Both these classes are useful for efficient removal and searching of the
> trees but in the case of SerDe we almost always want to simply walk the
> entire tree forwards or reversed and apply a function to each element. To
> that end, we can use lambdas and do this without any extra classes.
> 3. We use a lot of thread locals and check them constantly on the read/write
> paths. For client warnings, tracing, temp buffers, etc. We should move all
> thread locals to FastThreadLocals and threads to FastThreadLocalThreads.
> 4. We changed the memtable flusher defaults in 3.2 that caused a regression
> see: CASSANDRA-12228
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392144#comment-15392144
]
Alex Petrov commented on CASSANDRA-12012:
-
You can refer to complete runnable example
[here|https://github.com/ifesdjeen/cql_sstable_writer].
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
cassandra git commit: ninja: remove unused imports
Repository: cassandra Updated Branches: refs/heads/trunk 78a91dbe7 -> c8a365309 ninja: remove unused imports Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c8a36530 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c8a36530 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c8a36530 Branch: refs/heads/trunk Commit: c8a365309cdffc61f4e07aea4f4e566bd6283a3e Parents: 78a91db Author: Yuki Morishita Authored: Mon Jul 25 10:46:13 2016 -0500 Committer: Yuki Morishita Committed: Mon Jul 25 10:46:13 2016 -0500 -- src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 2 -- 1 file changed, 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c8a36530/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java -- diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java index 08f6aa6..975b10e 100644 --- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java +++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java @@ -23,7 +23,6 @@ import java.net.InetAddress; import java.net.UnknownHostException; import java.util.*; import java.util.concurrent.ConcurrentHashMap; -import java.util.concurrent.ConcurrentMap; import java.util.concurrent.TimeUnit; import com.codahale.metrics.ExponentiallyDecayingReservoir; @@ -39,7 +38,6 @@ import org.apache.cassandra.gms.VersionedValue; import org.apache.cassandra.net.MessagingService; import org.apache.cassandra.service.StorageService; import org.apache.cassandra.utils.FBUtilities; -import org.apache.ftpserver.command.impl.STOR; /**
[jira] [Commented] (CASSANDRA-9641) Occasional timeouts with blockFor=all for LOCAL_QUORUM query
[ https://issues.apache.org/jira/browse/CASSANDRA-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392096#comment-15392096 ] Richard Low commented on CASSANDRA-9641: I couldn't find the root cause. I'll look to see if it's happening on 2.1. > Occasional timeouts with blockFor=all for LOCAL_QUORUM query > > > Key: CASSANDRA-9641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9641 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Richard Low > Fix For: 2.1.x, 2.2.x, 3.0.x > > > We have a keyspace using NetworkTopologyStrategy with options DC1:3, DC2:3. > Our tables have > read_repair_chance = 0.0 > dclocal_read_repair_chance = 0.1 > speculative_retry = ’99.0PERCENTILE' > and all reads are at LOCAL_QUORUM. On 2.0.11, we occasionally see this > timeout: > Cassandra timeout during read query at consistency ALL (6 responses were > required but only 5 replica responded) > (sometimes only 4 respond). The ALL is probably due to CASSANDRA-7947 if this > occurs during a digest mismatch, but what is interesting is it is expecting 6 > responses i.e. blockFor is set to all replicas. I can’t see how this should > happen. From the code it should never set blockFor to more than 4 (although 4 > is still wrong - I'll make a separate JIRA for that). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10810) Make rebuild operations resumable
[
https://issues.apache.org/jira/browse/CASSANDRA-10810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392093#comment-15392093
]
Yuki Morishita commented on CASSANDRA-10810:
Thanks for the patch.
> 1.
It can be the test was terminated before the logs were flushed to disk.
By default, dtest generates logs when test fails for debugging purpose, so no
big deal.
> 2.
{{insert_c1c2}} can take {{keys}} argument instead of {{n}} to specify keys.
Please look at the source in {{tools.py}}.
Other than that, you need to add some {{ignore_log_patterns}}.
> Make rebuild operations resumable
> -
>
> Key: CASSANDRA-10810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10810
> Project: Cassandra
> Issue Type: Wish
> Components: Streaming and Messaging
>Reporter: Jeremy Hanna
>Assignee: Kaide Mu
> Fix For: 3.x
>
>
> Related to CASSANDRA-8942, now that we can resume bootstrap operations, this
> could also be possible with rebuild operations, such as when you bootstrap
> new nodes in a completely new datacenter in two steps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12289) dtest failure in cqlshlib.test.remove_test_db
[ https://issues.apache.org/jira/browse/CASSANDRA-12289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Kodman resolved CASSANDRA-12289. -- Resolution: Fixed > dtest failure in cqlshlib.test.remove_test_db > - > > Key: CASSANDRA-12289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12289 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/2/testReport/cqlshlib/test/remove_test_db > http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/3/cython=yes,label=ctool-lab/testReport/cqlshlib.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_create_columnfamily/ > http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/3/cython=yes,label=ctool-lab/testReport/cqlshlib.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_create_table/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12289) dtest failure in cqlshlib.test.remove_test_db
Craig Kodman created CASSANDRA-12289: Summary: dtest failure in cqlshlib.test.remove_test_db Key: CASSANDRA-12289 URL: https://issues.apache.org/jira/browse/CASSANDRA-12289 Project: Cassandra Issue Type: Test Reporter: Craig Kodman Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/2/testReport/cqlshlib/test/remove_test_db http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/3/cython=yes,label=ctool-lab/testReport/cqlshlib.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_create_columnfamily/ http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/3/cython=yes,label=ctool-lab/testReport/cqlshlib.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_create_table/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12291) dtest failure in json_test.JsonFullRowInsertSelect.pkey_requirement_test
Sean McCarthy created CASSANDRA-12291:
-
Summary: dtest failure in
json_test.JsonFullRowInsertSelect.pkey_requirement_test
Key: CASSANDRA-12291
URL: https://issues.apache.org/jira/browse/CASSANDRA-12291
Project: Cassandra
Issue Type: Test
Reporter: Sean McCarthy
Assignee: DS Test Eng
Attachments: node1.log, node1_debug.log, node1_gc.log
example failure:
http://cassci.datastax.com/job/trunk_offheap_dtest/354/testReport/json_test/JsonFullRowInsertSelect/pkey_requirement_test
{code}
Error Message
Doctest failed! Captured output:
**
Line 25, in pkey_requirement_test
Failed example:
cqlsh_err_print('''INSERT INTO primitive_type_test JSON '{"col1": "bar"}'
''')
Expected:
:2:InvalidRequest: Error from server: code=2200 [Invalid query]
message="Invalid null value in condition for column key1"
Got:
:2:InvalidRequest: code=2200 [Invalid query] message="Invalid null
value in condition for column key1"
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12289) dtest failure in cqlshlib.test.remove_test_db
[ https://issues.apache.org/jira/browse/CASSANDRA-12289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392070#comment-15392070 ] Philip Thompson commented on CASSANDRA-12289: - [~craig.kodman] this is a dupe of https://issues.apache.org/jira/browse/CASSANDRA-12214 which is already resolved. > dtest failure in cqlshlib.test.remove_test_db > - > > Key: CASSANDRA-12289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12289 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/2/testReport/cqlshlib/test/remove_test_db > http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/3/cython=yes,label=ctool-lab/testReport/cqlshlib.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_create_columnfamily/ > http://cassci.datastax.com/job/cassandra-3.9_cqlsh_tests/3/cython=yes,label=ctool-lab/testReport/cqlshlib.test.test_cqlsh_completion/TestCqlshCompletion/test_complete_in_create_table/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12290) dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_describe
Sean McCarthy created CASSANDRA-12290:
-
Summary: dtest failure in
cqlsh_tests.cqlsh_tests.TestCqlsh.test_describe
Key: CASSANDRA-12290
URL: https://issues.apache.org/jira/browse/CASSANDRA-12290
Project: Cassandra
Issue Type: Test
Reporter: Sean McCarthy
Assignee: DS Test Eng
example failure:
http://cassci.datastax.com/job/trunk_offheap_dtest/354/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe
{code}
Error Message
Lists differ: ["CREATE KEYSPACE test WITH re... != ["CREATE KEYSPACE test WITH
re...
First differing element 9:
AND cdc = false
{code}
Related Failure:
http://cassci.datastax.com/job/trunk_offheap_dtest/354/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe_mv/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391929#comment-15391929
]
Kuku1 edited comment on CASSANDRA-12012 at 7/25/16 3:11 PM:
I've added that before but it also gave me different Exceptions to fiddle with:
{code}
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.ja
va:427)
at de.xxx.bdrc.cassandrajsonimporter.CassandraJsonImporter.main(Cassand
raJsonImporter.java:67)
Caused by: java.lang.NullPointerException
at org.apache.cassandra.config.DatabaseDescriptor.getMaxMutationSize(Dat
abaseDescriptor.java:1258)
at org.apache.cassandra.db.commitlog.CommitLog.(CommitLog.java:66)
at org.apache.cassandra.db.commitlog.CommitLog.construct(CommitLog.java:
78)
at org.apache.cassandra.db.commitlog.CommitLog.(CommitLog.java:6
2)
... 2 more
{code}
Maybe there is something else I am missing, for example a configuration file?
I am running the program on a Client which does not have Cassandra
installed/running.
was (Author: kuku1):
I've added that before but it also gave me different Exceptions to fiddle with:
{code}
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.ja
va:427)
at de.vwag.bdrc.cassandrajsonimporter.CassandraJsonImporter.main(Cassand
raJsonImporter.java:67)
Caused by: java.lang.NullPointerException
at org.apache.cassandra.config.DatabaseDescriptor.getMaxMutationSize(Dat
abaseDescriptor.java:1258)
at org.apache.cassandra.db.commitlog.CommitLog.(CommitLog.java:66)
at org.apache.cassandra.db.commitlog.CommitLog.construct(CommitLog.java:
78)
at org.apache.cassandra.db.commitlog.CommitLog.(CommitLog.java:6
2)
... 2 more
{code}
Maybe there is something else I am missing, for example a configuration file?
I am running the program on a Client which does not have Cassandra
installed/running.
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
>
[jira] [Commented] (CASSANDRA-12240) Broken materialized view compatibility
[
https://issues.apache.org/jira/browse/CASSANDRA-12240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392065#comment-15392065
]
Bob Vawter commented on CASSANDRA-12240:
Ha, it seems in the time it took for me to hit this and produce a repro, the
devs already have a patch. Excellent.
> Broken materialized view compatibility
> --
>
> Key: CASSANDRA-12240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12240
> Project: Cassandra
> Issue Type: Bug
> Environment: datastax-ddc-3.7.0, Centos 7, x86_64
>Reporter: Gábor Auth
>Assignee: Sylvain Lebresne
>Priority: Blocker
>
> The behavior of the materialized view is not compatible with the previous
> versions of Cassandra, here is the simple test case, it is works from 3.3.0
> to 3.6.0. I've reproduced the issue with a single node installation and our
> eight node test environment too of the 3.7.0 version:
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor' : 1};
> USE test;
> CREATE TABLE test (id timeuuid PRIMARY KEY, segment text, xy text);
> CREATE MATERIALIZED VIEW test_by_segment AS SELECT * FROM test WHERE segment
> IS NOT NULL PRIMARY KEY (segment, id);
> CREATE MATERIALIZED VIEW test_by_xy AS SELECT * FROM test WHERE xy IS NOT
> NULL PRIMARY KEY (xy, id);
> UPDATE test SET segment=null, xy='{"x":0,"y":0}' WHERE
> id=8868dd90-fa48-11e3-afc8-c53da2f1a8ef;
> UPDATE test SET xy='{"x":0,"y":0}' WHERE
> id=8868dd90-fa48-11e3-afc8-c53da2f1a8ef;
> {code}
> The result of the `cqlsh` console:
> {code}
> WriteTimeout: code=1100 [Coordinator node timed out waiting for replica
> nodes' responses] message="Operation timed out - received only 0 responses."
> info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> The stack trace in the server log:
> {code}
> ERROR 19:40:19 Unknown exception caught while attempting to update
> MaterializedView! test
> 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.apply(Keyspace.java:399)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:228)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1343)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2519)
> ~[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.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> ~[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 19:40:19 Uncaught exception on thread
> Thread[SharedPool-Worker-2,5,main]: {}
> 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.cassan
[jira] [Commented] (CASSANDRA-12284) Cqlsh not supporting Copy command
[ https://issues.apache.org/jira/browse/CASSANDRA-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392060#comment-15392060 ] Michael Shuler commented on CASSANDRA-12284: The https://pypi.python.org/pypi/cqlsh latest version, 5.0.3, detail page shows: Author: Andrew Mussey Maintainer: Spiro Sideris Home Page: https://github.com/spiside/cqlsh Version 4.1.1 shows: Author: Andrew Mussey Home Page: https://github.com/amussey/cqlsh I would suggest opening a github issue for problems with pypi releases. Those releases are not done by the Apache Cassandra project. > Cqlsh not supporting Copy command > - > > Key: CASSANDRA-12284 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12284 > Project: Cassandra > Issue Type: Bug > Components: CQL > Environment: Debian and OSX(yosemite) >Reporter: Abhinav Johri > Fix For: 3.3 > > > I installed cqlsh for my cassandra server using pip command. > I wanted to copy a table as CSV to my local system so I used COPY TO command > but it threw me the following error. > Traceback (most recent call last): > File "/usr/local/bin/cqlsh", line 1133, in onecmd > self.handle_statement(st, statementtext) > File "/usr/local/bin/cqlsh", line 1170, in handle_statement > return custom_handler(parsed) > File "/usr/local/bin/cqlsh", line 1837, in do_copy > rows = self.perform_csv_export(ks, cf, columns, fname, opts) > File "/usr/local/bin/cqlsh", line 1956, in perform_csv_export > csv_options, dialect_options, unrecognized_options = > copyutil.parse_options(self, opts) > AttributeError: 'module' object has no attribute 'parse_options' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392062#comment-15392062
]
Alex Petrov commented on CASSANDRA-12012:
-
> I repeat that I try to run my Code on a Computer that has NO Cassandra
> Installation present.
This should not have any impact.
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12284) Cqlsh not supporting Copy command
[ https://issues.apache.org/jira/browse/CASSANDRA-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler resolved CASSANDRA-12284. Resolution: Invalid > Cqlsh not supporting Copy command > - > > Key: CASSANDRA-12284 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12284 > Project: Cassandra > Issue Type: Bug > Components: CQL > Environment: Debian and OSX(yosemite) >Reporter: Abhinav Johri > Fix For: 3.3 > > > I installed cqlsh for my cassandra server using pip command. > I wanted to copy a table as CSV to my local system so I used COPY TO command > but it threw me the following error. > Traceback (most recent call last): > File "/usr/local/bin/cqlsh", line 1133, in onecmd > self.handle_statement(st, statementtext) > File "/usr/local/bin/cqlsh", line 1170, in handle_statement > return custom_handler(parsed) > File "/usr/local/bin/cqlsh", line 1837, in do_copy > rows = self.perform_csv_export(ks, cf, columns, fname, opts) > File "/usr/local/bin/cqlsh", line 1956, in perform_csv_export > csv_options, dialect_options, unrecognized_options = > copyutil.parse_options(self, opts) > AttributeError: 'module' object has no attribute 'parse_options' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12240) Broken materialized view compatibility
[
https://issues.apache.org/jira/browse/CASSANDRA-12240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392059#comment-15392059
]
Bob Vawter commented on CASSANDRA-12240:
I can reproduce this exception on a fresh, single-node 3.0.8 cluster with the
following statements:
{code}
create table boom ( a text primary key, b text, c text);
create materialized view boom_mv as select * from boom where a is not null and
b is not null primary key (b,a);
insert into boom (a,b,c) values('a',null,'c');
update boom set c='bar' where a='a';
{code}
If I leave out the (b,null) from the insert statement, this executes as
expected.
> Broken materialized view compatibility
> --
>
> Key: CASSANDRA-12240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12240
> Project: Cassandra
> Issue Type: Bug
> Environment: datastax-ddc-3.7.0, Centos 7, x86_64
>Reporter: Gábor Auth
>Assignee: Sylvain Lebresne
>Priority: Blocker
>
> The behavior of the materialized view is not compatible with the previous
> versions of Cassandra, here is the simple test case, it is works from 3.3.0
> to 3.6.0. I've reproduced the issue with a single node installation and our
> eight node test environment too of the 3.7.0 version:
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor' : 1};
> USE test;
> CREATE TABLE test (id timeuuid PRIMARY KEY, segment text, xy text);
> CREATE MATERIALIZED VIEW test_by_segment AS SELECT * FROM test WHERE segment
> IS NOT NULL PRIMARY KEY (segment, id);
> CREATE MATERIALIZED VIEW test_by_xy AS SELECT * FROM test WHERE xy IS NOT
> NULL PRIMARY KEY (xy, id);
> UPDATE test SET segment=null, xy='{"x":0,"y":0}' WHERE
> id=8868dd90-fa48-11e3-afc8-c53da2f1a8ef;
> UPDATE test SET xy='{"x":0,"y":0}' WHERE
> id=8868dd90-fa48-11e3-afc8-c53da2f1a8ef;
> {code}
> The result of the `cqlsh` console:
> {code}
> WriteTimeout: code=1100 [Coordinator node timed out waiting for replica
> nodes' responses] message="Operation timed out - received only 0 responses."
> info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> The stack trace in the server log:
> {code}
> ERROR 19:40:19 Unknown exception caught while attempting to update
> MaterializedView! test
> 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.apply(Keyspace.java:399)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:228)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1343)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2519)
> ~[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.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> ~[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 19:40:19 Uncaught exception on thread
[jira] [Created] (CASSANDRA-12288) dtest failure in secondary_indexes_test.TestSecondaryIndexes.test_query_indexes_with_vnodes
Sean McCarthy created CASSANDRA-12288:
-
Summary: dtest failure in
secondary_indexes_test.TestSecondaryIndexes.test_query_indexes_with_vnodes
Key: CASSANDRA-12288
URL: https://issues.apache.org/jira/browse/CASSANDRA-12288
Project: Cassandra
Issue Type: Test
Reporter: Sean McCarthy
Assignee: DS Test Eng
Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
node2_debug.log, node2_gc.log
example failure:
http://cassci.datastax.com/job/trunk_offheap_dtest/347/testReport/secondary_indexes_test/TestSecondaryIndexes/test_query_indexes_with_vnodes
{code}
Standard Output
Unexpected error in node2 log, error:
ERROR [ReadStage-1] 2016-07-20 04:58:27,391 MessageDeliveryTask.java:74 - The
secondary index 'composites_index' is not yet available
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12277) Extend testing infrastructure to handle expected intermittent flaky tests - see ReplicationAwareTokenAllocatorTest.testNewCluster
[ https://issues.apache.org/jira/browse/CASSANDRA-12277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392042#comment-15392042 ] Joshua McKenzie commented on CASSANDRA-12277: - bq. I can easily see us defaulting to such mechanism every time we get a flaky test and that hiding genuine problems more often than not If we, collectively, don't have the discipline not to abuse something like this, we have bigger problems. bq. this feels to me like the test isn't precise enough and should be improved I'll let [~blambov] speak to that since this ticket was create from discussion with him. bq. that should be exceptional and I'd rather handle that in a case-by-case basis This ticket is about introducing infrastructure to allow us to formalize handling that on a case-by-case basis. If we leave a precise comment in the code, we still have a non-green test-board and the cognitive burden of filtering out "known flaky" failures when checking test results. > Extend testing infrastructure to handle expected intermittent flaky tests - > see ReplicationAwareTokenAllocatorTest.testNewCluster > - > > Key: CASSANDRA-12277 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12277 > Project: Cassandra > Issue Type: Bug >Reporter: Joshua McKenzie >Assignee: Branimir Lambov >Priority: Minor > Labels: test > > From an offline discussion: > bq. The ReplicationAwareTokenAllocatorTest.testNewCluster failure is a flake > -- randomness will sometimes (on the order of 1/100) cause it to fail. > Extending the ranges to avoid these flakes goes too far and makes the test > meaningless. > bq. How about instead of @flaky/@Ignore which currently indicates a test that > intermittently fails but we do not expect it to, we instead use @tries, or > @runs, or some annotation that indicates "run this thing N times, if M pass > we're good". This would allow us to keep the current "we don't care about > these test results (in context of green test board) because intermittent > failures are not expected and the test quality needs shoring up" from "we > expect this test to fail sometimes in this particular way." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12240) Broken materialized view compatibility
[
https://issues.apache.org/jira/browse/CASSANDRA-12240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-12240.
--
Resolution: Duplicate
Relatively sure this is the same problem than CASSANDRA-12247 (same stack and
same condition where a value that is part of the MV primary key is set to null
and the code crash on a following update). As the latter is patch available,
closing this one in favor.
> Broken materialized view compatibility
> --
>
> Key: CASSANDRA-12240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12240
> Project: Cassandra
> Issue Type: Bug
> Environment: datastax-ddc-3.7.0, Centos 7, x86_64
>Reporter: Gábor Auth
>Assignee: Sylvain Lebresne
>Priority: Blocker
>
> The behavior of the materialized view is not compatible with the previous
> versions of Cassandra, here is the simple test case, it is works from 3.3.0
> to 3.6.0. I've reproduced the issue with a single node installation and our
> eight node test environment too of the 3.7.0 version:
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor' : 1};
> USE test;
> CREATE TABLE test (id timeuuid PRIMARY KEY, segment text, xy text);
> CREATE MATERIALIZED VIEW test_by_segment AS SELECT * FROM test WHERE segment
> IS NOT NULL PRIMARY KEY (segment, id);
> CREATE MATERIALIZED VIEW test_by_xy AS SELECT * FROM test WHERE xy IS NOT
> NULL PRIMARY KEY (xy, id);
> UPDATE test SET segment=null, xy='{"x":0,"y":0}' WHERE
> id=8868dd90-fa48-11e3-afc8-c53da2f1a8ef;
> UPDATE test SET xy='{"x":0,"y":0}' WHERE
> id=8868dd90-fa48-11e3-afc8-c53da2f1a8ef;
> {code}
> The result of the `cqlsh` console:
> {code}
> WriteTimeout: code=1100 [Coordinator node timed out waiting for replica
> nodes' responses] message="Operation timed out - received only 0 responses."
> info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> The stack trace in the server log:
> {code}
> ERROR 19:40:19 Unknown exception caught while attempting to update
> MaterializedView! test
> 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.apply(Keyspace.java:399)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:202)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:228)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1343)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2519)
> ~[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.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> ~[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 19:40:19 Uncaught exception on thread
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.AssertionError: We shouldn't have got there is the base row had no
> associated entry
> at
> org.apache.cassandra.db.view.ViewUpdateGenerator.
[jira] [Updated] (CASSANDRA-12264) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean McCarthy updated CASSANDRA-12264:
--
Description:
example failure:
http://cassci.datastax.com/job/cassandra-3.9_dtest/15/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test
{code}
Error Message
'Repaired at: 0' unexpectedly found in 'SSTable:
{code}
Related failure:
http://cassci.datastax.com/job/trunk_dtest/1315/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test/
was:
example failure:
http://cassci.datastax.com/job/cassandra-3.9_dtest/15/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test
{code}
Error Message
'Repaired at: 0' unexpectedly found in 'SSTable:
{code}
> dtest failure in
> repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test
>
>
> Key: CASSANDRA-12264
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12264
> Project: Cassandra
> Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
> 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/cassandra-3.9_dtest/15/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test
> {code}
> Error Message
> 'Repaired at: 0' unexpectedly found in 'SSTable:
> {code}
> Related failure:
> http://cassci.datastax.com/job/trunk_dtest/1315/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12287) offline_tools_test.TestOfflineTools.sstablelevelreset_test
Craig Kodman created CASSANDRA-12287: Summary: offline_tools_test.TestOfflineTools.sstablelevelreset_test Key: CASSANDRA-12287 URL: https://issues.apache.org/jira/browse/CASSANDRA-12287 Project: Cassandra Issue Type: Test Reporter: Craig Kodman Assignee: DS Test Eng 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] [Comment Edited] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391992#comment-15391992
]
Kuku1 edited comment on CASSANDRA-12012 at 7/25/16 2:47 PM:
{code}
public static void main(String[] args) {
DataImporterConfiguration config;
try {
config = new DataImporterConfiguration(CONFIG_NAME);
final File outputPath = new
File(config.getOutputPath());
outputPath.mkdirs();
Config.setClientMode(true);
SchemaLoader.cleanupAndLeaveDirs(); //Here it's
crashing already (this line equals line 67 from the Log above)
Keyspace.setInitialized();
StorageService.instance.initServer();
//it does not get further than this so I left the rest
out.
...
{code}
There is no prior initialization or anything. Main is my entrypoint.
What else do you need?
Edit: I repeat that I try to run my Code on a Computer that has NO Cassandra
Installation present. Are there more Configuration Files which I need to pass
to the CQLSSTableWriter? For example the cassandra.yaml? But that would contain
directory paths of my unix system etc.
was (Author: kuku1):
{code}
public static void main(String[] args) {
DataImporterConfiguration config;
try {
config = new DataImporterConfiguration(CONFIG_NAME);
final File outputPath = new
File(config.getOutputPath());
outputPath.mkdirs();
Config.setClientMode(true);
SchemaLoader.cleanupAndLeaveDirs(); //Here it's
crashing already (this line equals line 67 from the Log above)
Keyspace.setInitialized();
StorageService.instance.initServer();
//it does not get further than this so I left the rest
out.
...
{code}
There is no prior initialization or anything. Main is my entrypoint.
What else do you need?
Edit: I repeat that I try to run my Code on a Computer that has NO Cassandra
Installation present. Are there more Configuration Files which I need to pass
to the CQLSSTableWriter. For example the cassandra.yaml? But that would contain
directory paths of my unix system etc.
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestri
[jira] [Comment Edited] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391992#comment-15391992
]
Kuku1 edited comment on CASSANDRA-12012 at 7/25/16 2:42 PM:
{code}
public static void main(String[] args) {
DataImporterConfiguration config;
try {
config = new DataImporterConfiguration(CONFIG_NAME);
final File outputPath = new
File(config.getOutputPath());
outputPath.mkdirs();
Config.setClientMode(true);
SchemaLoader.cleanupAndLeaveDirs(); //Here it's
crashing already (this line equals line 67 from the Log above)
Keyspace.setInitialized();
StorageService.instance.initServer();
//it does not get further than this so I left the rest
out.
...
{code}
There is no prior initialization or anything. Main is my entrypoint.
What else do you need?
Edit: I repeat that I try to run my Code on a Computer that has NO Cassandra
Installation present. Are there more Configuration Files which I need to pass
to the CQLSSTableWriter. For example the cassandra.yaml? But that would contain
directory paths of my unix system etc.
was (Author: kuku1):
{code}
public static void main(String[] args) {
DataImporterConfiguration config;
try {
config = new DataImporterConfiguration(CONFIG_NAME);
final File outputPath = new
File(config.getOutputPath());
outputPath.mkdirs();
Config.setClientMode(true);
SchemaLoader.cleanupAndLeaveDirs(); //Here it's
crashing already (this line equals line 67 from the Log above)
Keyspace.setInitialized();
StorageService.instance.initServer();
//it does not get further than this so I left the rest
out.
...
{code}
There is no prior initialization or anything. Main is my entrypoint.
What else do you need?
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java
[jira] [Updated] (CASSANDRA-12247) UPDATE fails with write timeout if row has null value on a field that is a clustering key in a materialized view
[ https://issues.apache.org/jira/browse/CASSANDRA-12247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-12247: - Reviewer: Carl Yeksigian Fix Version/s: 3.x Status: Patch Available (was: Open) This is due to an almost typo. Attached very trivial patch and unit test below. | [12247-3.0|https://github.com/pcmanus/cassandra/commits/12247-3.0] | [utests|http://cassci.datastax.com/job/pcmanus-12247-3.0-testall] | [dtests|http://cassci.datastax.com/job/pcmanus-12247-3.0-dtest] | | [12247-trunk|https://github.com/pcmanus/cassandra/commits/12247-trunk] | [utests|http://cassci.datastax.com/job/pcmanus-12247-trunk-testall] | [dtests|http://cassci.datastax.com/job/pcmanus-12247-trunk-dtest] | > UPDATE fails with write timeout if row has null value on a field that is a > clustering key in a materialized view > > > Key: CASSANDRA-12247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12247 > Project: Cassandra > Issue Type: Bug > 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.x, 3.x > > > Complete steps to reproduce: > https://gist.github.com/brstgt/4c3269eaec50a7d4abac5690157b238c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12286) dtest failure in cdc_test.TestCDC.test_cdc_data_available_in_cdc_raw
[ https://issues.apache.org/jira/browse/CASSANDRA-12286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Kodman updated CASSANDRA-12286: - Assignee: Jim Witschey (was: DS Test Eng) > dtest failure in cdc_test.TestCDC.test_cdc_data_available_in_cdc_raw > > > Key: CASSANDRA-12286 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12286 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: Jim Witschey > Labels: dtest > Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, > node2_debug.log, node2_gc.log > > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_dtest/18/testReport/cdc_test/TestCDC/test_cdc_data_available_in_cdc_raw -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391992#comment-15391992
]
Kuku1 commented on CASSANDRA-12012:
---
{code}
public static void main(String[] args) {
DataImporterConfiguration config;
try {
config = new DataImporterConfiguration(CONFIG_NAME);
final File outputPath = new
File(config.getOutputPath());
outputPath.mkdirs();
Config.setClientMode(true);
SchemaLoader.cleanupAndLeaveDirs(); //Here it's
crashing already (this line equals line 67 from the Log above)
Keyspace.setInitialized();
StorageService.instance.initServer();
//it does not get further than this so I left the rest
out.
...
{code}
There is no prior initialization or anything. Main is my entrypoint.
What else do you need?
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.
[
https://issues.apache.org/jira/browse/CASSANDRA-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391971#comment-15391971
]
T Jake Luciani commented on CASSANDRA-12236:
bq. I do will note that RowUpdateBuilder was used quite a bit in tests now (in
fact, some of the features of RowUpdateBuilder only existed for tests) so I
didn't removed the class, but simply moved it to the tests.
Sounds like the tests use one row update builder and the actual code uses
another. That's probably not the best idea.
> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format
> after 3.0, you will
> see error messages such as:
> "java.lang.RuntimeException: Unknown column cdc during
> deserialization"
> in your system logs on a mixed-version cluster during upgrades. This
> error message
> is harmless and due to the 3.8 nodes having cdc added to their schema
> tables while
> the <3.8 nodes do not. This message should cease once all nodes are
> upgraded to 3.8.
> As always, refrain from schema changes during cluster upgrades.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.
[
https://issues.apache.org/jira/browse/CASSANDRA-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-12236:
Reviewer: Aleksey Yeschenko (was: Joshua McKenzie)
> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format
> after 3.0, you will
> see error messages such as:
> "java.lang.RuntimeException: Unknown column cdc during
> deserialization"
> in your system logs on a mixed-version cluster during upgrades. This
> error message
> is harmless and due to the 3.8 nodes having cdc added to their schema
> tables while
> the <3.8 nodes do not. This message should cease once all nodes are
> upgraded to 3.8.
> As always, refrain from schema changes during cluster upgrades.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12286) dtest failure in cdc_test.TestCDC.test_cdc_data_available_in_cdc_raw
Craig Kodman created CASSANDRA-12286: Summary: dtest failure in cdc_test.TestCDC.test_cdc_data_available_in_cdc_raw Key: CASSANDRA-12286 URL: https://issues.apache.org/jira/browse/CASSANDRA-12286 Project: Cassandra Issue Type: Test Reporter: Craig Kodman Assignee: DS Test Eng Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, node2_debug.log, node2_gc.log example failure: http://cassci.datastax.com/job/cassandra-3.9_dtest/18/testReport/cdc_test/TestCDC/test_cdc_data_available_in_cdc_raw -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.
[
https://issues.apache.org/jira/browse/CASSANDRA-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391956#comment-15391956
]
Joshua McKenzie commented on CASSANDRA-12236:
-
Kicking review over to [~iamaleksey] since this outgrew the initial scope and
we're blocking 3.8 on this. Better to have him review since it's in the same
domain as things he reviewed for CASSANDRA-8099 and I'd prefer not to delay
release longer just to make sure I get up to speed appropriately.
> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format
> after 3.0, you will
> see error messages such as:
> "java.lang.RuntimeException: Unknown column cdc during
> deserialization"
> in your system logs on a mixed-version cluster during upgrades. This
> error message
> is harmless and due to the 3.8 nodes having cdc added to their schema
> tables while
> the <3.8 nodes do not. This message should cease once all nodes are
> upgraded to 3.8.
> As always, refrain from schema changes during cluster upgrades.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391953#comment-15391953
]
Alex Petrov commented on CASSANDRA-12012:
-
[~Kuku1] could you please post an entire code you're running? Configuration
file would be great, too!
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391929#comment-15391929
]
Kuku1 commented on CASSANDRA-12012:
---
I've added that before but it also gave me different Exceptions to fiddle with:
{code}
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.apache.cassandra.SchemaLoader.cleanupAndLeaveDirs(SchemaLoader.ja
va:427)
at de.vwag.bdrc.cassandrajsonimporter.CassandraJsonImporter.main(Cassand
raJsonImporter.java:67)
Caused by: java.lang.NullPointerException
at org.apache.cassandra.config.DatabaseDescriptor.getMaxMutationSize(Dat
abaseDescriptor.java:1258)
at org.apache.cassandra.db.commitlog.CommitLog.(CommitLog.java:66)
at org.apache.cassandra.db.commitlog.CommitLog.construct(CommitLog.java:
78)
at org.apache.cassandra.db.commitlog.CommitLog.(CommitLog.java:6
2)
... 2 more
{code}
Maybe there is something else I am missing, for example a configuration file?
I am running the program on a Client which does not have Cassandra
installed/running.
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12285) dtest failure in user_functions_test.TestUserFunctions.test_migration
[ https://issues.apache.org/jira/browse/CASSANDRA-12285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Kodman updated CASSANDRA-12285: - Attachment: node3.log node3_gc.log node3_debug.log node2.log node2_gc.log node2_debug.log node1.log node1_gc.log node1_debug.log > dtest failure in user_functions_test.TestUserFunctions.test_migration > - > > Key: CASSANDRA-12285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12285 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >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/cassandra-3.9_dtest/17/testReport/user_functions_test/TestUserFunctions/test_migration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.
[
https://issues.apache.org/jira/browse/CASSANDRA-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-12236:
-
Status: Patch Available (was: Open)
Btw, I haven't run the upgrade tests at all, so I haven't verified this fixes
the upgrade problem. If someone could trigger those (once maybe the utest and
dtests shows the patch isn't too broken), that would be great.
> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format
> after 3.0, you will
> see error messages such as:
> "java.lang.RuntimeException: Unknown column cdc during
> deserialization"
> in your system logs on a mixed-version cluster during upgrades. This
> error message
> is harmless and due to the 3.8 nodes having cdc added to their schema
> tables while
> the <3.8 nodes do not. This message should cease once all nodes are
> upgraded to 3.8.
> As always, refrain from schema changes during cluster upgrades.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.
[
https://issues.apache.org/jira/browse/CASSANDRA-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391906#comment-15391906
]
Sylvain Lebresne commented on CASSANDRA-12236:
--
So the idea of not sending the {{cdc}} boolean to old node is correct (I
think), but unfortunately we use {{RowUpdateBuilder}} to construct the mutation
and that class is a bit naive and includes all the known columns from the
metadata in the header of the mutation it sends (out of simplicity), even if
there is not value for some of the columns.
Now, the {{RowUpdateBuilder}} and the way we use it building schema mutation is
a bit of a mess as we sometimes reuse a particular {{PartitionUpdate}}, but not
in all path and without a good way to distinguish, which, long story short,
makes it harder to figure out which columns will actually be used in the
PartitionUpdate (and {{PartitionUpdate}} needs to know that upfront). Truth
being told, I think {{RowUpdateBuilder}} has overgrown its initial intention
and it's imo time for a small refactor.
So I'm attaching a patch that refactor {{RowUpdateBuilder}}, and make it only
include the column it needs to so that Josh's patch work as intended. It moves
a bit of code around, but I think the result is overall a lot cleaner (and
potentially more reusable). I do will note that {{RowUpdateBuilder}} was used
quite a bit in tests now (in fact, some of the features of {{RowUpdateBuilder}}
only existed for tests) so I didn't removed the class, but simply moved it to
the tests.
| [12236-trunk|https://github.com/pcmanus/cassandra/commits/12236-trunk] |
[utests|http://cassci.datastax.com/job/pcmanus-12236-trunk-testall] |
[dtests|http://cassci.datastax.com/job/pcmanus-12236-trunk-dtest] |
> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format
> after 3.0, you will
> see error messages such as:
> "java.lang.RuntimeException: Unknown column cdc during
> deserialization"
> in your system logs on a mixed-version cluster during upgrades. This
> error message
> is harmless and due to the 3.8 nodes having cdc added to their schema
> tables while
> the <3.8 nodes do not. This message should cease once all nodes are
> upgraded to 3.8.
> As always, refrain from schema changes during cluster upgrades.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12285) dtest failure in user_functions_test.TestUserFunctions.test_migration
[ https://issues.apache.org/jira/browse/CASSANDRA-12285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-12285: Status: Patch Available (was: Open) https://github.com/riptano/cassandra-dtest/pull/1124 > dtest failure in user_functions_test.TestUserFunctions.test_migration > - > > Key: CASSANDRA-12285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12285 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: Philip Thompson > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_dtest/17/testReport/user_functions_test/TestUserFunctions/test_migration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12285) dtest failure in user_functions_test.TestUserFunctions.test_migration
[ https://issues.apache.org/jira/browse/CASSANDRA-12285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson reassigned CASSANDRA-12285: --- Assignee: Philip Thompson (was: DS Test Eng) > dtest failure in user_functions_test.TestUserFunctions.test_migration > - > > Key: CASSANDRA-12285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12285 > Project: Cassandra > Issue Type: Test >Reporter: Craig Kodman >Assignee: Philip Thompson > Labels: dtest > > example failure: > http://cassci.datastax.com/job/cassandra-3.9_dtest/17/testReport/user_functions_test/TestUserFunctions/test_migration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12285) dtest failure in user_functions_test.TestUserFunctions.test_migration
Craig Kodman created CASSANDRA-12285: Summary: dtest failure in user_functions_test.TestUserFunctions.test_migration Key: CASSANDRA-12285 URL: https://issues.apache.org/jira/browse/CASSANDRA-12285 Project: Cassandra Issue Type: Test Reporter: Craig Kodman Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-3.9_dtest/17/testReport/user_functions_test/TestUserFunctions/test_migration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12174) COPY FROM should raise error for non-existing input files
[
https://issues.apache.org/jira/browse/CASSANDRA-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391869#comment-15391869
]
Hiroyuki Nishi commented on CASSANDRA-12174:
Hi [~Stefania],
Thanks for your response.
I changed the patch as the following.
https://github.com/yhnishi/cassandra/commit/db75d9dd0d74d3476d500f6b99c22e117dc73ec6
Below is sample results.
Success:
{code}
cqlsh> COPY test.airplanes (name, manufacturer, year, mach) FROM '/tmp/1.csv';
Using 7 child processes
Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
1 rows imported from 1 files in 0.420 seconds (0 skipped).
cqlsh> COPY test.airplanes (name, manufacturer, year, mach) FROM
'/tmp/1.csv,/tmp/2.csv';
Using 7 child processes
Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
Processed: 2 rows; Rate: 3 rows/s; Avg. rate: 5 rows/s
2 rows imported from 2 files in 0.418 seconds (0 skipped).
cqlsh> COPY test.airplanes (name, manufacturer, year, mach) FROM '/tmp/*.csv';
Using 7 child processes
Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
Processed: 2 rows; Rate: 3 rows/s; Avg. rate: 5 rows/s
2 rows imported from 2 files in 0.413 seconds (0 skipped).
{code}
Error:
{code}
cqlsh> COPY test.airplanes (name, manufacturer, year, mach) FROM
'/tmp/1234-doesnotexist';
Using 7 child processes
Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
Failed to import 0 rows: IOError - Can't open '/tmp/1234-doesnotexist' for
reading: file does not exist, given up after 1 attempts
Processed: 0 rows; Rate: 0 rows/s; Avg. rate: 0 rows/s
0 rows imported from 0 files in 0.218 seconds (0 skipped).
cqlsh> COPY test.airplanes (name, manufacturer, year, mach) FROM
'/tmp/*-doesnotexist';
Using 7 child processes
Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
Failed to import 0 rows: IOError - Can't open '/tmp/*-doesnotexist' for
reading: file does not exist, given up after 1 attempts
Processed: 0 rows; Rate: 0 rows/s; Avg. rate: 0 rows/s
0 rows imported from 0 files in 0.218 seconds (0 skipped).
cqlsh> COPY test.airplanes (name, manufacturer, year, mach) FROM
'/tmp/1234-doesnotexist,/tmp/1235-doesnotexist';
Using 7 child processes
Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
Failed to import 0 rows: IOError - Can't open '/tmp/1234-doesnotexist' for
reading: file does not exist, given up after 1 attempts
Processed: 0 rows; Rate: 0 rows/s; Avg. rate: 0 rows/s
0 rows imported from 0 files in 0.217 seconds (0 skipped).
cqlsh> COPY test.airplanes (name, manufacturer, year, mach) FROM
'/tmp/1.csv,/tmp/*-doesnotexist';
Using 7 child processes
Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
Failed to import 0 rows: IOError - Can't open '/tmp/*-doesnotexist' for
reading: file does not exist, given up after 1 attempts
Processed: 0 rows; Rate: 0 rows/s; Avg. rate: 0 rows/s
0 rows imported from 1 files in 0.219 seconds (0 skipped).
{code}
Please check the patch once again.
> COPY FROM should raise error for non-existing input files
> -
>
> Key: CASSANDRA-12174
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12174
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Stefan Podkowinski
>Assignee: Hiroyuki Nishi
>Priority: Minor
> Labels: lhf
> Attachments: CASSANDRA-12174-trunk.patch
>
>
> Currently the CSV COPY FROM command will not raise any error for non-existing
> paths. Instead only "0 rows imported" will be shown as result.
> As the COPY FROM command is often used for tutorials and getting started
> guides, I'd suggest to give a clear error message in case of a missing input
> file. Without such error it can be confusing for the user to see the command
> actually finish, without any clues why no rows have been imported.
> {noformat}
> CREATE KEYSPACE test
> WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 1
> };
> USE test;
> CREATE TABLE airplanes (
> name text PRIMARY KEY,
> manufacturer ascii,
> year int,
> mach float
> );
> COPY airplanes (name, manufacturer, year, mach) FROM '/tmp/1234-doesnotexist';
> Using 3 child processes
> Starting copy of test.airplanes with columns [name, manufacturer, year, mach].
> Processed: 0 rows; Rate: 0 rows/s; Avg. rate: 0 rows/s
> 0 rows imported from 0 files in 0.216 seconds (0 skipped).
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12039) Add an index callback to be notified post bootstrap and before joining the ring
[
https://issues.apache.org/jira/browse/CASSANDRA-12039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391866#comment-15391866
]
Sam Tunnicliffe commented on CASSANDRA-12039:
-
Thanks, the updated patch is looking good. If you amend slightly the new log
statement in {{SIM}} to include the value being passed in, we can properly
check that in a dtest. Otherwise, modulo the couple of nits below I think we'll
be good to go once we get some dtests in place.
One thing that we should note is that when pre-join tasks are executed as a
result of manually joining (i.e. start in write survey mode, then join via
nodetool/JMX), the value of the bootstrap flag is always false. Obviously, this
might not always be accurate as a node can perfectly well start up in survey
mode but also perform bootstrap before an operator joins it. Short of exposing
the overload of {{joinRing}} and extending the nodetool join command, I'm not
sure there's any practical solution to this. However, I guess this is quite a
niche scenario, so I suggest that clearly documenting this limitation in
{{NEWS.txt}} is sufficient. Would you mind adding an entry to {{NEWS.txt}}
please?
Nits:
The filter condition in {{StorageService::executePreJoinTasks}} can be
streamlined to:
{code}
.filter(cfs ->
Schema.instance.getUserKeyspaces().contains(cfs.keyspace.getName()))
{code}
{{SIM::executeAllBlocking}} handles null {{Callable}} correctly, so the default
impl of {{getPreJoinTask}} can just return {{null}} rather than a task which
returns {{null}}.
There's a couple of other minor formatting things, but I can fix those on
commit.
> Add an index callback to be notified post bootstrap and before joining the
> ring
> ---
>
> Key: CASSANDRA-12039
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12039
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> Custom index implementations might need to be notified when the node finishes
> bootstrapping in order to execute some blocking tasks before the node itself
> goes into NORMAL state.
> This is a proposal to add such functionality, which should roughly require
> the following:
> 1) Add a {{getPostBootstrapTask}} callback to the {{Index}} interface.
> 2) Add an {{executePostBootstrapBlockingTasks}} method to
> {{SecondaryIndexManager}} calling into the previously mentioned callback.
> 3) Hook that into {{StorageService#joinTokenRing}}.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov resolved CASSANDRA-12012.
-
Resolution: Not A Bug
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391783#comment-15391783
]
Alex Petrov commented on CASSANDRA-12012:
-
They're not required. Please refer to [this
example|https://github.com/apache/cassandra/blob/cassandra-3.0/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java#L54-L56]
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11927) dtest failure in replication_test.ReplicationTest.simple_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-11927:
Status: Open (was: Patch Available)
bq. applying a mutation to an unknown table/CF should cause the write request
to fail
I'm not convinced about this tbh.
First, I disagree that it is a bug, I would argue rather that the behaviour is
fully intended. As such, changing it would be invalid in 2.2/3.0/3.9 and
debatable even for trunk given that nobody actually reported it as a problem.
Second, the way this is implemented here means that any updates obtained from
the iterator *before* a missing cf is encountered, *would* be applied but the
RTE would *still* be thrown which is pretty confusing.
So given that the actual cause of the test failure has been addressed by
CASSANDRA-12083, I suggest we close this.
> dtest failure in replication_test.ReplicationTest.simple_test
> -
>
> Key: CASSANDRA-11927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11927
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Paulo Motta
> Labels: dtest
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log,
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/387/testReport/replication_test/ReplicationTest/simple_test
> Failed on CassCI build trunk_novnode_dtest #387
> Logs are attached.
> Unexpected error in question:
> {code}
> ERROR [SharedPool-Worker-1] 2016-05-30 16:00:17,211 Keyspace.java:504 -
> Attempting to mutate non-existant table 99f5be60-267f-11e6-ad5f-f13d771494ea
> (test.test)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12012) CQLSSTableWriter and composite clustering keys trigger NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-12012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391730#comment-15391730
]
Kuku1 commented on CASSANDRA-12012:
---
I ran into the same problem with Cassandra 3.0.8. Is there any easy fix that
does not need me to rebuild Cassandra from Source and then edit the lines
according to [~pierz]?
I am limited on my workstation and I can't rebuild Cassandra manually here.
Is it possible that I can swap out an existing .jar into the one that contains
the changes from Pierre?
> CQLSSTableWriter and composite clustering keys trigger NPE
> --
>
> Key: CASSANDRA-12012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12012
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Pierre N.
>Assignee: Mahdi Mohammadi
>
> It triggers when using multiple clustering keys in the primary keys
> {code}
> package tests;
> import java.io.File;
> import org.apache.cassandra.io.sstable.CQLSSTableWriter;
> import org.apache.cassandra.config.Config;
> public class DefaultWriter {
>
> public static void main(String[] args) throws Exception {
> Config.setClientMode(true);
>
> String createTableQuery = "CREATE TABLE ks_test.table_test ("
> + "pk1 int,"
> + "ck1 int,"
> + "ck2 int,"
> + "PRIMARY KEY ((pk1), ck1, ck2)"
> + ");";
> String insertQuery = "INSERT INTO ks_test.table_test(pk1, ck1, ck2)
> VALUES(?,?,?)";
>
> CQLSSTableWriter writer = CQLSSTableWriter.builder()
> .inDirectory(Files.createTempDirectory("sst").toFile())
> .forTable(createTableQuery)
> .using(insertQuery)
> .build();
> writer.close();
> }
> }
> {code}
> Exception :
> {code}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:159)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.hasSupportingIndex(PrimaryKeyRestrictionSet.java:156)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.(PrimaryKeyRestrictionSet.java:118)
> at
> org.apache.cassandra.cql3.restrictions.PrimaryKeyRestrictionSet.mergeWith(PrimaryKeyRestrictionSet.java:213)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addSingleColumnRestriction(StatementRestrictions.java:266)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.addRestriction(StatementRestrictions.java:250)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:159)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:183)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:782)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:768)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:505)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.getStatement(CQLSSTableWriter.java:508)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSSTableWriter.java:439)
> at tests.DefaultWriter.main(DefaultWriter.java:29)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:127)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12269) Faster write path
[
https://issues.apache.org/jira/browse/CASSANDRA-12269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391685#comment-15391685
]
Stefania commented on CASSANDRA-12269:
--
Sylvain has definitely picked up the most important points, especially breaking
of encapsulation, I would really rather avoid the following:
{code}
assert row instanceof BTreeRow;
Object[] btree = ((BTreeRow)row).btree;
{code}
Here are some other points, in addition to those raised above by Sylvain:
* We can get rid of {{WrappedException}} if we define this interface:
{code}
public interface ApplyFunction
{
void accept(T t) throws E;
}
{code}
and change the signatures to:
{code}
public static void applyForwards(Object[] btree,
ApplyFunction function, Predicate stopCondition) throws E
{code}
* Rather than creating utility classes for setting values we can use references
or optionals or, better, declare a small class that implements
the interface and store these values as class fields. This should also help in
debugging and profiling.
* Isn't 1 MB a bit too much for {{MAX_RECYCLE_BUFFER_SIZE}} in
DataOutputBuffer? We have lots of threads at the moment, WDYT?
* We got one weird failure (StaticColumnsTest) and several timeouts in the unit
tests, it's better to rebase and rerun to try and shake some of the failures.
* How do we run MutationBench? I got this error when running it from IntelliJ:
{{java.lang.RuntimeException: ERROR: Unable to find the resource:
/META-INF/BenchmarkList}}
* I spent a bit of time trying to understand {{BTree.applyReverseInner()}} and
eventually I got there, mostly because I was not familiar with how the values
are stored in BTree. It's a matter of personal preference but, for me it would
be clearer if the index in {{BTree.applyReverseInner()}} was calculated with
the exact mirror of {{BTree.applyForwardInner()}}, therefore {{int idx = isLeaf
? i : i + (visited / 2) - (i % 2 == 0 ? 0 : childOffset);}} but leaving some
comments albeit condensed in one paragraph just above that line. Really up to
you though.
--
Nits:
* Unused imports in SerializationHeader.java, UnfilteredSerializer.java,
DataOutputBuffer.java, ParitionUpdate.java, MutationBench.java
* Two identical typos in BTree.java documentation: {{till a stop condition it
reached}} -> {{till a stop condition is reached}}
* Maybe a comment for {{FastThreadExecutor}} explaining that this class is used
by {{MutationBench}} via {{-Djmh.executor.class}} would be useful.
> Faster write path
> -
>
> Key: CASSANDRA-12269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12269
> Project: Cassandra
> Issue Type: Improvement
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.10
>
>
> The new storage engine (CASSANDRA-8099) has caused a regression in write
> performance. This ticket is to address it and bring 3.0 as close to 2.2 as
> possible. There are four main reasons for this I've discovered after much
> toil:
> 1. The cost of calculating the size of a serialized row is higher now since
> we no longer have the cell name and value managed as ByteBuffers as we did
> pre-3.0. That means we current re-serialize the row twice, once to calculate
> the size and once to write the data. This happens during the SSTable writes
> and was addressed in CASSANDRA-9766.
> Double serialization is also happening in CommitLog and the
> MessagingService. We need to apply the same techniques to these as we did to
> the SSTable serialization.
> 2. Even after fixing (1) there is still an issue with there being more GC
> pressure and CPU usage in 3.0 due to the fact that we encode everything from
> the {{Column}} to the {{Row}} to the {{Partition}} as a {{BTree}}.
> Specifically, the {{BTreeSearchIterator}} is used for all iterator() methods.
> Both these classes are useful for efficient removal and searching of the
> trees but in the case of SerDe we almost always want to simply walk the
> entire tree forwards or reversed and apply a function to each element. To
> that end, we can use lambdas and do this without any extra classes.
> 3. We use a lot of thread locals and check them constantly on the read/write
> paths. For client warnings, tracing, temp buffers, etc. We should move all
> thread locals to FastThreadLocals and threads to FastThreadLocalThreads.
> 4. We changed the memtable flusher defaults in 3.2 that caused a regression
> see: CASSANDRA-12228
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12242) Could not create trigger
[
https://issues.apache.org/jira/browse/CASSANDRA-12242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391676#comment-15391676
]
Alex Petrov commented on CASSANDRA-12242:
-
{{TriggerExecutor}} instance is created in static context:
{code}
public static final TriggerExecutor instance = new TriggerExecutor();
{code}
Could you check the permissions on the file? It also looks like you're running
on windows, I'm wondering if this can be related in any way.
> Could not create trigger
>
>
> Key: CASSANDRA-12242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12242
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: RocWay Li
> Attachments: DataTrigger.java
>
>
> I tried cassandra 2.2.6 and 3.7, both of them could not create triggers.
> It reports that the trigger class doesn't exist. But it actually does and is
> at the right directory, the conf/triggers.
> I debugged the source code, and I found that SEPWorker is used to create
> triggers, but it's thread is not a secure thread, which should be managed by
> cassandra's SecurityManager and belongs to SecurityThreadGroup.
> When security validation failed, an exception will be thrown. That's direct
> cause for creating triggers failed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12142) Add "beta" version native protocol flag
[
https://issues.apache.org/jira/browse/CASSANDRA-12142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391481#comment-15391481
]
Alex Petrov commented on CASSANDRA-12142:
-
I've made the mentioned changes to the patch. I have initially left the check
for lower version in it's original, but since I could not reproduce the size
mismatch, I've moved it down.
Might be that someone from driver team would like to take a look? [~adutra]
[~omichallat] [~andrew.tolbert] there's also an (early) version of driver
changes [here|https://datastax-oss.atlassian.net/browse/JAVA-1248]. I'd have to
add more tests to it.
> Add "beta" version native protocol flag
> ---
>
> Key: CASSANDRA-12142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12142
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Alex Petrov
> Labels: protocolv5
>
> As discussed in CASSANDRA-10786, we'd like to add a new flag to the native
> protocol to allow drivers to connect using a "beta" native protocol version.
> This would be used for native protocol versions that are still in development
> and may not have all of the final features. Without the "beta" flag, drivers
> will be prevented from using the protocol version.
> This is primarily useful for driver authors to start work against a new
> protocol version when the work on that spans multiple releases. Users would
> not generally be expected to utilize this flag, although it could potentially
> be used to offer early feedback on new protocol features.
> It seems like the {{STARTUP}} message body is the best place for the new beta
> flag. We may also considering adding protocol information to the
> {{SUPPORTED}} message as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
