[jira] [Commented] (CASSANDRA-8279) Geo-Red : Streaming is working fine on two nodes but failing on one node repeatedly.
[ https://issues.apache.org/jira/browse/CASSANDRA-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206068#comment-14206068 ] Akhtar Hussain commented on CASSANDRA-8279: --- Yes, we are using using Cassandra version 2.0.3. I think we have discovered the cause of streaming failure on one of the nodes. While capturing nodetool stats asked by you, We observed that nodetool status on the node where streaming failed, showed all nodes from both the data centers under ONE data center. When we analyzed the Cassandra-topology.properties files on all the nodes of both data centers, we discovered that one node in each data center(including the node where streaming failed) was having obsolete configuration which was there when both data centers were operating separately and not added in same Cassandra cluster. Obsolete files had only private Host entries/RAC for local data center. Ideally it should have public hosts of both data centers. I think we missed these two files while setting up two data centers. Do you think this may be the reason? If yes, how can we correct the issue such that node is in stable state? Though We have corrected the configuration and are not observing any problems as of now. Thanks you so much for guiding > Geo-Red : Streaming is working fine on two nodes but failing on one node > repeatedly. > - > > Key: CASSANDRA-8279 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8279 > Project: Cassandra > Issue Type: Bug > Components: API > Environment: LINUX >Reporter: Akhtar Hussain > > Exception in thread "main" java.lang.RuntimeException: Error while rebuilding > node: Stream failed > at > org.apache.cassandra.service.StorageService.rebuild(StorageService.java:896) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) > at > com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at > com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468) > at > javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487) > at > javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97) > at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328) > at java.security.AccessController.doPrivileged(Native Method) > at > javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427) > at > javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) > at sun.rmi.transport.Transport$1.run(Transport.java:177) > at sun.rmi.transport.Transport$1.run(Transport.java:174) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:173) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811) > at
[jira] [Comment Edited] (CASSANDRA-8281) CQLSSTableWriter close does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205779#comment-14205779
]
Xu Zhongxing edited comment on CASSANDRA-8281 at 11/11/14 6:11 AM:
---
It could be reproduced on cassandra 2.1.2, 2.1.1, but not on 2.1.0.
{code}
import org.apache.cassandra.io.sstable.CQLSSTableWriter;
class A {
public static void main(String[] args) {
String schema = "create table mgindex.test (x int primary key, y int)";
String insert = "insert into mgindex.test (x,y) values(?,?)";
CQLSSTableWriter w = CQLSSTableWriter.builder()
.inDirectory("/tmp/mgindex/test")
.forTable(schema)
.using(insert)
.build();
try {
w.addRow(1,1);
w.close();
} catch (Exception e) {
System.out.println(e);
}
}
}
{code}
was (Author: xuzhongxing):
It could be reproduced on cassandra 2.1.1, but not on 2.1.0.
{code}
import org.apache.cassandra.io.sstable.CQLSSTableWriter;
class A {
public static void main(String[] args) {
String schema = "create table mgindex.test (x int primary key, y int)";
String insert = "insert into mgindex.test (x,y) values(?,?)";
CQLSSTableWriter w = CQLSSTableWriter.builder()
.inDirectory("/tmp/mgindex/test")
.forTable(schema)
.using(insert)
.build();
try {
w.addRow(1,1);
w.close();
} catch (Exception e) {
System.out.println(e);
}
}
}
{code}
> CQLSSTableWriter close does not work
>
>
> Key: CASSANDRA-8281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8281
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Environment: Cassandra 2.1.1
>Reporter: Xu Zhongxing
>
> I called CQLSSTableWriter.close(). But the program still cannot exit. But the
> same code works fine on Cassandra 2.0.10.
> It seems that CQLSSTableWriter cannot be closed, and blocks the program from
> exit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205958#comment-14205958 ] Dave Brosius edited comment on CASSANDRA-8241 at 11/11/14 5:20 AM: --- TBH, not a big fan of either solution, each is nasty in its own right. I agree with Robert, using Java Assist means you will always be in a state of catch up language wise. But relying on eclipse means dragging an elephant of configuration test matrix problems around with you forever. My experience with user-provided source code level integration is just a painful painful thing. I'm not sure it's worth it. I'm also not a big fan of building prototype java code up in StringBuilders. Can we externalize the prototype into a first class file that get's getResourceAsStream'ed in and modified thru markers of some sort? was (Author: dbrosius): TBH, not a big fan of either solution, each is nasty in its own right. I agree with Robert, using Java Assist means you will always be in a state of catch up language wise. But relying on eclipse means dragging an elephant of configuration test matrix problems around with you forever. I'm also not a big fan of building prototype java code up in StringBuilders. Can we externalize the prototype into a first class file that get's getResourceAsStream'ed in and modified thru markers of some sort? > Use javac instead of javassist > -- > > Key: CASSANDRA-8241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8241 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Fix For: 3.0 > > Attachments: 8241-ecj.txt, udf-java-javac.txt > > > Using JDK's built-in Java-Compiler API has some advantages over javassist. > Although compilation feels a bit slower, Java compiler API has some > advantages: > * boxing + unboxing works > * generics work > * compiler error messages are better (or at least known) and have line/column > numbers > The implementation does not use any temp files. Everything's in memory. > Patch attached to this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205958#comment-14205958 ] Dave Brosius commented on CASSANDRA-8241: - TBH, not a big fan of either solution, each is nasty in its own right. I agree with Robert, using Java Assist means you will always be in a state of catch up language wise. But relying on eclipse means dragging an elephant of configuration test matrix problems around with you forever. I'm also not a big fan of building prototype java code up in StringBuilders. Can we externalize the prototype into a first class file that get's getResourceAsStream'ed in and modified thru markers of some sort? > Use javac instead of javassist > -- > > Key: CASSANDRA-8241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8241 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Fix For: 3.0 > > Attachments: 8241-ecj.txt, udf-java-javac.txt > > > Using JDK's built-in Java-Compiler API has some advantages over javassist. > Although compilation feels a bit slower, Java compiler API has some > advantages: > * boxing + unboxing works > * generics work > * compiler error messages are better (or at least known) and have line/column > numbers > The implementation does not use any temp files. Everything's in memory. > Patch attached to this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8288) cqlsh describe needs to show 'sstable_compression': ''
Jeremiah Jordan created CASSANDRA-8288:
--
Summary: cqlsh describe needs to show 'sstable_compression': ''
Key: CASSANDRA-8288
URL: https://issues.apache.org/jira/browse/CASSANDRA-8288
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Jeremiah Jordan
For uncompressed tables cqlsh describe schema should show "AND compression =
{'sstable_compression': ''}" otherwise when you replay the schema you get the
default of LZ4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8281) CQLSSTableWriter close does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205779#comment-14205779
]
Xu Zhongxing commented on CASSANDRA-8281:
-
It could be reproduced on cassandra 2.1.1, but not on 2.1.0.
{code}
import org.apache.cassandra.io.sstable.CQLSSTableWriter;
class A {
public static void main(String[] args) {
String schema = "create table mgindex.test (x int primary key, y int)";
String insert = "insert into mgindex.test (x,y) values(?,?)";
CQLSSTableWriter w = CQLSSTableWriter.builder()
.inDirectory("/tmp/mgindex/test")
.forTable(schema)
.using(insert)
.build();
try {
w.addRow(1,1);
w.close();
} catch (Exception e) {
System.out.println(e);
}
}
}
{code}
> CQLSSTableWriter close does not work
>
>
> Key: CASSANDRA-8281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8281
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Environment: Cassandra 2.1.1
>Reporter: Xu Zhongxing
>
> I called CQLSSTableWriter.close(). But the program still cannot exit. But the
> same code works fine on Cassandra 2.0.10.
> It seems that CQLSSTableWriter cannot be closed, and blocks the program from
> exit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8287) Row Level Isolation is violated by read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-8287: --- Assignee: Sylvain Lebresne > Row Level Isolation is violated by read repair > -- > > Key: CASSANDRA-8287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8287 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: sankalp kohli >Assignee: Sylvain Lebresne >Priority: Minor > > In 1.1, row level isolation was added. As per the blog post > http://www.datastax.com/dev/blog/row-level-isolation > "Cassandra guarantees that the changes to login and password are either both > applied or none are." > This is not true with background read repair. Consider this as given in the > blog post. > You run > UPDATE Users > SET login='eric22' AND password='f3g$dq!' > WHERE key='550e8400-e29b-41d4-a716-44665544' > There are 3 machines A,B and C and replication is RF=3 > 1) Machine A did not get this update as it was down and past hint window. > 2) Machine A comes online. > 3) You now only read the password. > 4) password is now read repaired on A. > SO on machine A, password = f3g$dq! and login is still old -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8287) Row Level Isolation is violated by read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205713#comment-14205713 ] sankalp kohli commented on CASSANDRA-8287: -- cc [~brandon.williams], [~slebresne] > Row Level Isolation is violated by read repair > -- > > Key: CASSANDRA-8287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8287 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: sankalp kohli >Priority: Minor > > In 1.1, row level isolation was added. As per the blog post > http://www.datastax.com/dev/blog/row-level-isolation > "Cassandra guarantees that the changes to login and password are either both > applied or none are." > This is not true with background read repair. Consider this as given in the > blog post. > You run > UPDATE Users > SET login='eric22' AND password='f3g$dq!' > WHERE key='550e8400-e29b-41d4-a716-44665544' > There are 3 machines A,B and C and replication is RF=3 > 1) Machine A did not get this update as it was down and past hint window. > 2) Machine A comes online. > 3) You now only read the password. > 4) password is now read repaired on A. > SO on machine A, password = f3g$dq! and login is still old -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8287) Row Level Isolation is violated by read repair
sankalp kohli created CASSANDRA-8287: Summary: Row Level Isolation is violated by read repair Key: CASSANDRA-8287 URL: https://issues.apache.org/jira/browse/CASSANDRA-8287 Project: Cassandra Issue Type: Bug Components: Core Reporter: sankalp kohli Priority: Minor In 1.1, row level isolation was added. As per the blog post http://www.datastax.com/dev/blog/row-level-isolation "Cassandra guarantees that the changes to login and password are either both applied or none are." This is not true with background read repair. Consider this as given in the blog post. You run UPDATE Users SET login='eric22' AND password='f3g$dq!' WHERE key='550e8400-e29b-41d4-a716-44665544' There are 3 machines A,B and C and replication is RF=3 1) Machine A did not get this update as it was down and past hint window. 2) Machine A comes online. 3) You now only read the password. 4) password is now read repaired on A. SO on machine A, password = f3g$dq! and login is still old -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8193) Multi-DC parallel snapshot repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8193: -- Reviewer: Yuki Morishita Yuki to review. > Multi-DC parallel snapshot repair > - > > Key: CASSANDRA-8193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8193 > Project: Cassandra > Issue Type: Improvement >Reporter: Jimmy Mårdell >Assignee: Jimmy Mårdell >Priority: Minor > Fix For: 2.0.12 > > Attachments: cassandra-2.0-8193-1.txt > > > The current behaviour of snapshot repair is to let one node at a time > calculate a merkle tree. This is to ensure only one node at a time is doing > the expensive calculation. The drawback is that it takes even longer time to > do the merkle tree calculation. > In a multi-DC setup, I think it would make more sense to have one node in > each DC calculate the merkle tree at the same time. This would yield a > significant improvement when you have many data centers. > I'm not sure how relevant this is in 2.1, but I don't see us upgrading to 2.1 > any time soon. Unless there is an obvious drawback that I'm missing, I'd like > to implement this in the 2.0 branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8285) OOME in Cassandra 2.0.11
[ https://issues.apache.org/jira/browse/CASSANDRA-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205600#comment-14205600 ] Jonathan Ellis commented on CASSANDRA-8285: --- [~pingtimeout] please upload a heap dump and we'll have a look. may be we're not flushing aggressively enough. > OOME in Cassandra 2.0.11 > > > Key: CASSANDRA-8285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8285 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 2.0.11 + java-driver 2.0.8-SNAPSHOT > Cassandra 2.0.11 + ruby-driver 1.0-beta >Reporter: Pierre Laporte >Assignee: Ryan McGuire > Attachments: OOME_node_system.log, gc.log.gz, > heap-usage-after-gc-zoom.png, heap-usage-after-gc.png > > > We ran drivers 3-days endurance tests against Cassandra 2.0.11 and C* crashed > with an OOME. This happened both with ruby-driver 1.0-beta and java-driver > 2.0.8-snapshot. > Attached are : > | OOME_node_system.log | The system.log of one Cassandra node that crashed | > | gc.log.gz | The GC log on the same node | > | heap-usage-after-gc.png | The heap occupancy evolution after every GC cycle > | > | heap-usage-after-gc-zoom.png | A focus on when things start to go wrong | > Workload : > Our test executes 5 CQL statements (select, insert, select, delete, select) > for a given unique id, during 3 days, using multiple threads. There is not > change in the workload during the test. > Symptoms : > In the attached log, it seems something starts in Cassandra between > 2014-11-06 10:29:22 and 2014-11-06 10:45:32. This causes an allocation that > fills the heap. We eventually get stuck in a Full GC storm and get an OOME > in the logs. > I have run the java-driver tests against Cassandra 1.2.19 and 2.1.1. The > error does not occur. It seems specific to 2.0.11. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8285) OOME in Cassandra 2.0.11
[ https://issues.apache.org/jira/browse/CASSANDRA-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8285: -- Assignee: Ryan McGuire Ryan, who can do a first cut heap analysis? > OOME in Cassandra 2.0.11 > > > Key: CASSANDRA-8285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8285 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 2.0.11 + java-driver 2.0.8-SNAPSHOT > Cassandra 2.0.11 + ruby-driver 1.0-beta >Reporter: Pierre Laporte >Assignee: Ryan McGuire > Attachments: OOME_node_system.log, gc.log.gz, > heap-usage-after-gc-zoom.png, heap-usage-after-gc.png > > > We ran drivers 3-days endurance tests against Cassandra 2.0.11 and C* crashed > with an OOME. This happened both with ruby-driver 1.0-beta and java-driver > 2.0.8-snapshot. > Attached are : > | OOME_node_system.log | The system.log of one Cassandra node that crashed | > | gc.log.gz | The GC log on the same node | > | heap-usage-after-gc.png | The heap occupancy evolution after every GC cycle > | > | heap-usage-after-gc-zoom.png | A focus on when things start to go wrong | > Workload : > Our test executes 5 CQL statements (select, insert, select, delete, select) > for a given unique id, during 3 days, using multiple threads. There is not > change in the workload during the test. > Symptoms : > In the attached log, it seems something starts in Cassandra between > 2014-11-06 10:29:22 and 2014-11-06 10:45:32. This causes an allocation that > fills the heap. We eventually get stuck in a Full GC storm and get an OOME > in the logs. > I have run the java-driver tests against Cassandra 1.2.19 and 2.1.1. The > error does not occur. It seems specific to 2.0.11. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8241) Use javac instead of javassist
[ https://issues.apache.org/jira/browse/CASSANDRA-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205584#comment-14205584 ] Jonathan Ellis commented on CASSANDRA-8241: --- How do you evaluate the goodness of eclipse vs javassist? /cc [~dbrosius] [~blerer] > Use javac instead of javassist > -- > > Key: CASSANDRA-8241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8241 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Fix For: 3.0 > > Attachments: 8241-ecj.txt, udf-java-javac.txt > > > Using JDK's built-in Java-Compiler API has some advantages over javassist. > Although compilation feels a bit slower, Java compiler API has some > advantages: > * boxing + unboxing works > * generics work > * compiler error messages are better (or at least known) and have line/column > numbers > The implementation does not use any temp files. Everything's in memory. > Patch attached to this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-5483) Repair tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205451#comment-14205451 ] Ben Chan commented on CASSANDRA-5483: - Sorry; SMART and reallocated sectors. Which only really accounts for about 2-3 days of the delay. But just to say that it wasn't merely a case of hangover from too much Halloween candy. Updated https://github.com/usrbincc/cassandra/tree/5483-review (currently at commit 202a2e2e5e602). Merges cleanly with trunk (at commit d286ac7d072fe), building and testing cleanly. I decided to be a little opinionated and did some refactoring along the lines of my Oct 23 message. - Used a TraceState#waitActivity function instead of TraceState#isDone (waitActivity gets closer to doing only what it says on the tin; makes it less hairy to comment). - Moved all exponential backoff timeout code to StorageService#createQueryThread In addition, I renamed TraceState#enableNotifications to TraceState#enableActivityNotification to attempt (naming is hard) to avoid confusion with TraceState#setNotificationHandle, which is entirely unrelated. Note: beyond having made this opinionated edit, I'm not planning to be particularly opinionated about advocating for it. All of that code should eventually go away once there is some way to get notified about table updates instead of having to do all that messy polling. Extra note: Cassandra triggers seem to be very close to what is needed, if only they could be specified to run on a given node (i.e. the node that is being repaired). The last time I checked on this, this wasn't possible. Unfiltered traces: - The extra traces are generic message send-receive traces that existed prior to this patch. They were originally there for query tracing, which benefits from more detailed tracing. - These extra traces were filtered out for repair up until v16 of this patch. This means that any discussions of trace messages prior to that point are referring to the filtered traces. But I can't say that they're doing any real harm. I mean, it's only 3x the traces (estimated), and not an order of magnitude or more. It's probably fine as it is. I certainly can't unequivocally state that there's no use for those extra traces. Besides, extra information can always be filtered out at a higher level (assuming it's tagged appropriately). > Repair tracing > -- > > Key: CASSANDRA-5483 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5483 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Yuki Morishita >Assignee: Ben Chan >Priority: Minor > Labels: repair > Fix For: 3.0 > > Attachments: 5483-full-trunk.txt, > 5483-v06-04-Allow-tracing-ttl-to-be-configured.patch, > 5483-v06-05-Add-a-command-column-to-system_traces.events.patch, > 5483-v06-06-Fix-interruption-in-tracestate-propagation.patch, > 5483-v07-07-Better-constructor-parameters-for-DebuggableThreadPoolExecutor.patch, > 5483-v07-08-Fix-brace-style.patch, > 5483-v07-09-Add-trace-option-to-a-more-complete-set-of-repair-functions.patch, > 5483-v07-10-Correct-name-of-boolean-repairedAt-to-fullRepair.patch, > 5483-v08-11-Shorten-trace-messages.-Use-Tracing-begin.patch, > 5483-v08-12-Trace-streaming-in-Differencer-StreamingRepairTask.patch, > 5483-v08-13-sendNotification-of-local-traces-back-to-nodetool.patch, > 5483-v08-14-Poll-system_traces.events.patch, > 5483-v08-15-Limit-trace-notifications.-Add-exponential-backoff.patch, > 5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch, > 5483-v10-17-minor-bugfixes-and-changes.patch, > 5483-v10-rebased-and-squashed-471f5cc.patch, 5483-v11-01-squashed.patch, > 5483-v11-squashed-nits.patch, 5483-v12-02-cassandra-yaml-ttl-doc.patch, > 5483-v13-608fb03-May-14-trace-formatting-changes.patch, > 5483-v14-01-squashed.patch, > 5483-v15-02-Hook-up-exponential-backoff-functionality.patch, > 5483-v15-03-Exact-doubling-for-exponential-backoff.patch, > 5483-v15-04-Re-add-old-StorageService-JMX-signatures.patch, > 5483-v15-05-Move-command-column-to-system_traces.sessions.patch, > 5483-v15.patch, 5483-v17-00.patch, 5483-v17-01.patch, 5483-v17.patch, > ccm-repair-test, cqlsh-left-justify-text-columns.patch, > prerepair-vs-postbuggedrepair.diff, test-5483-system_traces-events.txt, > trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch, > trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch, > tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt, > tr...@8ebeee1-5483-v01-002-simple-repair-tracing.txt, > v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch, > v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch, > v02p02-5
[jira] [Commented] (CASSANDRA-7396) Allow selecting Map key, List index
[ https://issues.apache.org/jira/browse/CASSANDRA-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205368#comment-14205368 ] Robert Stupp commented on CASSANDRA-7396: - [~philipthompson] from a quick look this looks good - nice :) > Allow selecting Map key, List index > --- > > Key: CASSANDRA-7396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7396 > Project: Cassandra > Issue Type: New Feature > Components: API >Reporter: Jonathan Ellis >Assignee: Robert Stupp > Labels: cql > Fix For: 3.0 > > > Allow "SELECT map['key]" and "SELECT list[index]." (Selecting a UDT subfield > is already supported.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-7874: Attachment: 7874v6.txt Damn - did not see that garbage in my IDE. Seems that copy from VirtualBox to OS X added that garbage. Sorry - for that. 'echo' stuff removed, too. > Validate functionality of different JSR-223 providers in UDFs > - > > Key: CASSANDRA-7874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7874 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Fix For: 3.0 > > Attachments: 7874.txt, 7874v2.txt, 7874v3.txt, 7874v4.txt, > 7874v5.txt, 7874v6.txt > > > CASSANDRA-7526 introduces ability to support optional JSR-223 providers like > Clojure, Jython, Groovy or JRuby. > This ticket is about to test functionality with these providers but not to > include them in C* distribution. > Expected result is a "how to" document, wiki page or similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205322#comment-14205322
]
Philip Thompson commented on CASSANDRA-8286:
Despite the commit being in 2.1.x as well, the tests are passing there with no
error.
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.0.12
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8286:
---
Reproduced In: 2.1.2, 2.0.12 (was: 2.0.12)
Fix Version/s: 2.1.3
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.0.12, 2.1.3
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205322#comment-14205322
]
Philip Thompson edited comment on CASSANDRA-8286 at 11/10/14 8:58 PM:
--
Despite the commit being in 2.1.x as well, the tests are passing there with no
error. This is due to CASSANDRA-4911.
was (Author: philipthompson):
Despite the commit being in 2.1.x as well, the tests are passing there with no
error.
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.0.12
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8286:
---
Reproduced In: 2.0.12 (was: 2.0.12, 2.1.2, 2.1.3)
Since Version: 2.0.12 (was: 2.1.2)
Fix Version/s: (was: 2.1.3)
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.0.12
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205331#comment-14205331
]
Philip Thompson commented on CASSANDRA-8286:
However, in the 2.1 test {{TestCQL.in_order_by_without_selecting_test}}, the
following exception has begun appearing at the same time:
http://cassci.datastax.com/job/cassandra-2.1_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/in_order_by_without_selecting_test/history/
{code}ERROR [SharedPool-Worker-3] 2014-11-10 14:58:28,591 Message.java
:538 - Unexpected exception during request; channel = [id: 0x5aa
e53fd, /127.0.0.1:63101 => /127.0.0.1:9042]
java.lang.AssertionError: null
at org.apache.cassandra.cql3.ResultSet.addRow(ResultSet.java:63)
~[main/:na]
at
org.apache.cassandra.cql3.statements.Selection$ResultSetBuilder.newRow(Selection.java:333)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.processColumnFamily(SelectStatement.java:1227)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:1161)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:290)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:267)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:215)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:64)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:226)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:248)
~[main/:na]
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
~[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
[main/:na]
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
[netty-all-4.0.23.Final.jar:4.0.23.Final]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[na:1.7.0_67]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
[main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]{code}
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.0.12
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8286:
---
Reproduced In: 2.1.2, 2.0.12, 2.1.3 (was: 2.1.2, 2.1.3)
Fix Version/s: 2.0.12
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.0.12, 2.1.3
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8193) Multi-DC parallel snapshot repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-8193: -- Fix Version/s: 2.0.12 > Multi-DC parallel snapshot repair > - > > Key: CASSANDRA-8193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8193 > Project: Cassandra > Issue Type: Improvement >Reporter: Jimmy Mårdell >Assignee: Jimmy Mårdell >Priority: Minor > Fix For: 2.0.12 > > Attachments: cassandra-2.0-8193-1.txt > > > The current behaviour of snapshot repair is to let one node at a time > calculate a merkle tree. This is to ensure only one node at a time is doing > the expensive calculation. The drawback is that it takes even longer time to > do the merkle tree calculation. > In a multi-DC setup, I think it would make more sense to have one node in > each DC calculate the merkle tree at the same time. This would yield a > significant improvement when you have many data centers. > I'm not sure how relevant this is in 2.1, but I don't see us upgrading to 2.1 > any time soon. Unless there is an obvious drawback that I'm missing, I'd like > to implement this in the 2.0 branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8286:
---
Description:
The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in 2.0:
http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
This failure began at the commit for CASSANDRA-8178.
The error message reads
{code}==
ERROR: order_by_multikey_test (cql_tests.TestCQL)
--
Traceback (most recent call last):
File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
wrapped
f(obj)
File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
in order_by_multikey_test
res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1', 'key2',
'key3') ORDER BY col1;")
File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281, in
execute
result = future.result(timeout)
File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771, in
result
raise self._final_exception
InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
on columns missing in select clause."{code}
and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1', 'key2',
'key3') ORDER BY col1;}}
was:
The dtest cql_tests.py:TestCQL.order_by_multikey_test is now failing in 2.0:
http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
This failure began at the commit for CASSANDRA-8178.
The error message reads
{code}==
ERROR: order_by_multikey_test (cql_tests.TestCQL)
--
Traceback (most recent call last):
File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
wrapped
f(obj)
File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
in order_by_multikey_test
res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1', 'key2',
'key3') ORDER BY col1;")
File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281, in
execute
result = future.result(timeout)
File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771, in
result
raise self._final_exception
InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
on columns missing in select clause."{code}
and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1', 'key2',
'key3') ORDER BY col1;}}
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.1.3
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205312#comment-14205312
]
Philip Thompson commented on CASSANDRA-8286:
The test {{TestCQL.order_by_with_in_test}} is failing for the same reason and
began at the same commit.
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.1.3
>
>
> The dtest cql_tests.py:TestCQL.order_by_multikey_test is now failing in 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6434) Repair-aware gc grace period
[ https://issues.apache.org/jira/browse/CASSANDRA-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205328#comment-14205328 ] Aleksey Yeschenko commented on CASSANDRA-6434: -- That, and there is the similar issue of hints, batches, and paxos. Similar ideas have already been proposed before, but this issue killed them - see, for example, CASSANDRA-3620. I don't see how to work around that at the moment. > Repair-aware gc grace period > - > > Key: CASSANDRA-6434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6434 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: sankalp kohli >Assignee: Marcus Eriksson > Fix For: 3.0 > > > Since the reason for gcgs is to ensure that we don't purge tombstones until > every replica has been notified, it's redundant in a world where we're > tracking repair times per sstable (and repairing frequentily), i.e., a world > where we default to incremental repair a la CASSANDRA-5351. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8286) Regression in ORDER BY
Philip Thompson created CASSANDRA-8286:
--
Summary: Regression in ORDER BY
Key: CASSANDRA-8286
URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
Project: Cassandra
Issue Type: Bug
Reporter: Philip Thompson
Assignee: Tyler Hobbs
Fix For: 2.1.3
The dtest cql_tests.py:TestCQL.order_by_multikey_test is now failing in 2.0:
http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
This failure began at the commit for CASSANDRA-8178.
The error message reads
{code}==
ERROR: order_by_multikey_test (cql_tests.TestCQL)
--
Traceback (most recent call last):
File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
wrapped
f(obj)
File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
in order_by_multikey_test
res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1', 'key2',
'key3') ORDER BY col1;")
File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281, in
execute
result = future.result(timeout)
File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771, in
result
raise self._final_exception
InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
on columns missing in select clause."{code}
and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1', 'key2',
'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8193) Multi-DC parallel snapshot repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Mårdell updated CASSANDRA-8193: - Attachment: cassandra-2.0-8193-1.txt > Multi-DC parallel snapshot repair > - > > Key: CASSANDRA-8193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8193 > Project: Cassandra > Issue Type: Improvement >Reporter: Jimmy Mårdell >Assignee: Jimmy Mårdell >Priority: Minor > Attachments: cassandra-2.0-8193-1.txt > > > The current behaviour of snapshot repair is to let one node at a time > calculate a merkle tree. This is to ensure only one node at a time is doing > the expensive calculation. The drawback is that it takes even longer time to > do the merkle tree calculation. > In a multi-DC setup, I think it would make more sense to have one node in > each DC calculate the merkle tree at the same time. This would yield a > significant improvement when you have many data centers. > I'm not sure how relevant this is in 2.1, but I don't see us upgrading to 2.1 > any time soon. Unless there is an obvious drawback that I'm missing, I'd like > to implement this in the 2.0 branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6434) Repair-aware gc grace period
[ https://issues.apache.org/jira/browse/CASSANDRA-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205304#comment-14205304 ] Jeremiah Jordan commented on CASSANDRA-6434: I think we need to make sure we still have some kind of grace period for tombstones. An extreme edge case here, but: 1. user insert Y at time 10. 2. Insert gets held up in coordinator or something. 3. User inserts delete for Y at time 11 to a different node. 4. Incremental repair happens. 5. compaction happens (dropping the tombstone) because it was repaired. 6. insert at time 10 comes through. If you have a gcgs > timeout period the data from step 6 will be ignored (though you probably want it even longer than the timeout, as client retries with same old timestamp could happen). If you don't have gcgs, the data could suddenly show up even though a delete went through. So as much as I like the idea of just removing gc grace, I think we really need to keep it as the minimum time tombstones will stay around. But we could make the default 30 minutes or something if we have the repair aware tombstone removal. > Repair-aware gc grace period > - > > Key: CASSANDRA-6434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6434 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: sankalp kohli >Assignee: Marcus Eriksson > Fix For: 3.0 > > > Since the reason for gcgs is to ensure that we don't purge tombstones until > every replica has been notified, it's redundant in a world where we're > tracking repair times per sstable (and repairing frequentily), i.e., a world > where we default to incremental repair a la CASSANDRA-5351. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205292#comment-14205292
]
Joshua McKenzie commented on CASSANDRA-7874:
v5 has some garbage in cassandra-env.ps1:
{code}
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 685a86f..cfb281d 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -195,6 +195,42 @@ Function CalculateHeapSizes
$env:HEAP_NEWSIZE = [System.Convert]::ToString($desiredYG) + "M"
}
}
+
{code}
Similar in cassandra.bat:
{code}
diff --git a/bin/cassandra.bat b/bin/cassandra.bat
index 02f9677..4e3cafc 100644
--- a/bin/cassandra.bat
+++ b/bin/cassandra.bat
@@ -85,6 +85,33 @@ goto :eof
REM
-
:okClasspath
+
+REM JSR223 - collect all JSR223 engines' jars
{code}
Also - we should remove the printed "Detected jruby N" etc at runtime.
All that being said, both legacy .bat run and .ps1 run work w/the garbage
removed. A few tweaks and the Windows side is gtg.
> Validate functionality of different JSR-223 providers in UDFs
> -
>
> Key: CASSANDRA-7874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7874
> Project: Cassandra
> Issue Type: Task
> Components: Core
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: udf
> Fix For: 3.0
>
> Attachments: 7874.txt, 7874v2.txt, 7874v3.txt, 7874v4.txt, 7874v5.txt
>
>
> CASSANDRA-7526 introduces ability to support optional JSR-223 providers like
> Clojure, Jython, Groovy or JRuby.
> This ticket is about to test functionality with these providers but not to
> include them in C* distribution.
> Expected result is a "how to" document, wiki page or similar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7124) Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
[
https://issues.apache.org/jira/browse/CASSANDRA-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205273#comment-14205273
]
Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-7124:
-
[~thobbs] I have done the first cut of changes for the JMX notifications for
the "cleanup" command. Here are the things I have done
1) Implemented an abstract Runner class
2) Inherited the CleanupRunner from Runner and implemented the "run" method
specific to the "cleanup"
3) In the NodeProbe.java class implemented a cleanupAsync method with the JMX
related changes
4) In the NodeTool.java, the newly added method is called
I have done the clean compilation and other sanity tests related to the
changes. How do I test it, should you want to have a look at the changes done?
In that case should I upload a temporary patch? Please let me know. Thanks
> Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
>
>
> Key: CASSANDRA-7124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7124
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
>
> If {{nodetool cleanup}} or some other long-running operation takes too long
> to complete, you'll see an error like the one in CASSANDRA-2126, so you can't
> tell if the operation completed successfully or not. CASSANDRA-4767 fixed
> this for repairs with JMX notifications. We should do something similar for
> nodetool cleanup, compact, decommission, move, relocate, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8070) OutOfMemoryError in OptionalTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205263#comment-14205263
]
Joshua McKenzie commented on CASSANDRA-8070:
I'd argue that 32-bit *anything* w/small amount of RAM isn't an ideal
environment. ;)
> OutOfMemoryError in OptionalTasks
> -
>
> Key: CASSANDRA-8070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8070
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows-7-32 bit, 3GB RAM, Java 1.7.0_67
>Reporter: Andreas Schnitzerling
> Attachments: system.log
>
>
> Since update of 2 of 12 nodes from 2.0.10 to 2.1-release Exception during
> operation.
> {panel:title=system.log}
> ERROR [OptionalTasks:1] 2014-10-02 09:26:42,821 CassandraDaemon.java:166 -
> Exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.OutOfMemoryError: Java heap space
> at com.yammer.metrics.stats.Snapshot.(Snapshot.java:30)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.getSnapshot(ExponentiallyDecayingSample.java:131)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.getSnapshot(Histogram.java:180)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.getSnapshot(Timer.java:183)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$2.run(ColumnFamilyStore.java:340)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:75)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
> [na:1.7.0_67]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
> Source) [na:1.7.0_67]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source) [na:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> [na:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> [na:1.7.0_67]
> at java.lang.Thread.run(Unknown Source) [na:1.7.0_67]
> {panel}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8120) Failed creating a merkle tree during repair.
[
https://issues.apache.org/jira/browse/CASSANDRA-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-8120:
--
Description:
Seeing this while running nodetool repair on several nodes of our new (not an
upgrade) 2.1.0 cluster. Multiple keyspaces. Doesn't hang the repair job.
Storage is SSD ephemeral (EC2). No storage errors in syslog.
{noformat}
ERROR [ValidationExecutor:39] 2014-10-13 22:20:51,140 Validator.java:242 -
Failed creating a merkle tree for [repair #1523dfa0-5327-11e4-925c-65a001aa6d80
on censored/censored, (-4468426774357114003,-4433737571269222163]],
/10.37.666.175 (see log for details)
INFO [AntiEntropySessions:37] 2014-10-13 22:20:51,141 RepairSession.java:260 -
[repair #308e2750-5327-11e4-925c-65a001aa6d80] new session: will sync
ip-10-37-666-175.ec2.internal/10.37.666.175, /10.167.666.137, /10.164.666.81 on
range (6870883176570587821,6871062738154464368] for censored.[censored]
INFO [AntiEntropyStage:1] 2014-10-13 22:20:51,142 ColumnFamilyStore.java:856 -
Enqueuing flush of censored: 3227760 (0%) on-heap, 0 (0%) off-heap
INFO [MemtableFlushWriter:2295] 2014-10-13 22:20:51,145 Memtable.java:326 -
Writing Memtable-censored@2052537453(380369 serialized bytes, 8235 ops, 0%/0%
of on/off-heap limit)
ERROR [AntiEntropySessions:34] 2014-10-13 22:20:51,148 RepairSession.java:303 -
[repair #1523dfa0-5327-11e4-925c-65a001aa6d80] session completed with the
following error
org.apache.cassandra.exceptions.RepairException: [repair
#1523dfa0-5327-11e4-925c-65a001aa6d80 on censored/censored,
(-4468426774357114003,-4433737571269222163]] Validation failed in /10.37.666.175
at
org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:166)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:384)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:123)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
ERROR [ValidationExecutor:39] 2014-10-13 22:20:51,148 CassandraDaemon.java:166
- Exception in thread Thread[ValidationExecutor:39,1,main]
java.lang.AssertionError: row DecoratedKey(-4468391015221140553,
0004000108005abc2d00) received out of order wrt
DecoratedKey(-4436255891196926644, 000400010800617f4400)
at org.apache.cassandra.repair.Validator.add(Validator.java:136)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:916)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:100)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:560)
~[apache-cassandra-2.1.0.jar:2.1.0]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
~[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
ERROR [AntiEntropySessions:34] 2014-10-13 22:20:51,149 CassandraDaemon.java:166
- Exception in thread Thread[AntiEntropySessions:34,5,RMI Runtime]
java.lang.RuntimeException: org.apache.cassandra.exceptions.RepairException:
[repair #1523dfa0-5327-11e4-925c-65a001aa6d80 on censored/censored,
(-4468426774357114003,-4433737571269222163]] Validation failed in /10.37.666.175
at com.google.common.base.Throwables.propagate(Throwables.java:160)
~[guava-16.0.jar:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
~[na:1.7.0_67]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
~[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
Caused by: org.apache.cassandra.exceptions.RepairException: [repair
#1523dfa0-5327-11e4-925c-65a001aa6d80 on censored/censored,
(-44684267743571
[jira] [Updated] (CASSANDRA-8081) AssertionError with 2ndary indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-8081:
--
Assignee: Marcus Eriksson
> AssertionError with 2ndary indexes
> ---
>
> Key: CASSANDRA-8081
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8081
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: kais
>Assignee: Marcus Eriksson
>
> If you create a table with a column type text or blob and add a secondary
> index on it. If you insert a value that is longer than
> FBUtilities.MAX_UNSIGNED_SHORT, then flush, you get an assertion error
> {code}
> CREATE TABLE test_text (key text PRIMARY KEY, col text);
> CREATE INDEX test_text_col_idx ON test_text (col);
> {code}
> {code}
> INFO [FlushWriter:3] 2014-10-08 10:53:38,471 Memtable.java (line 331)
> Writing Memtable-test_text.test_text_col_idx@849649959(15/150 serialized/live
> bytes, 1 ops)
> INFO [FlushWriter:4] 2014-10-08 10:53:38,554 Memtable.java (line 331)
> Writing Memtable-test_text@1448092010(100025/1000250 serialized/live bytes, 2
> ops)
> ERROR [FlushWriter:3] 2014-10-08 10:53:38,554 CassandraDaemon.java (line 196)
> Exception in thread Thread[FlushWriter:3,5,RMI Runtime]
> java.lang.AssertionError: 10
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:342)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8070) OutOfMemoryError in OptionalTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler resolved CASSANDRA-8070.
---
Resolution: Not a Problem
> OutOfMemoryError in OptionalTasks
> -
>
> Key: CASSANDRA-8070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8070
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows-7-32 bit, 3GB RAM, Java 1.7.0_67
>Reporter: Andreas Schnitzerling
> Attachments: system.log
>
>
> Since update of 2 of 12 nodes from 2.0.10 to 2.1-release Exception during
> operation.
> {panel:title=system.log}
> ERROR [OptionalTasks:1] 2014-10-02 09:26:42,821 CassandraDaemon.java:166 -
> Exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.OutOfMemoryError: Java heap space
> at com.yammer.metrics.stats.Snapshot.(Snapshot.java:30)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.getSnapshot(ExponentiallyDecayingSample.java:131)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.getSnapshot(Histogram.java:180)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.getSnapshot(Timer.java:183)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$2.run(ColumnFamilyStore.java:340)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:75)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
> [na:1.7.0_67]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
> Source) [na:1.7.0_67]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source) [na:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> [na:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> [na:1.7.0_67]
> at java.lang.Thread.run(Unknown Source) [na:1.7.0_67]
> {panel}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8070) OutOfMemoryError in OptionalTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205239#comment-14205239
]
Michael Shuler commented on CASSANDRA-8070:
---
32-bit Windows with a small amount of RAM is not an ideal environment to work
with. Some would argue that a minimum of 8G RAM is needed for relatively decent
normal day-to-day dev environments, with 32-64G for production nodes. 64-bit OS
and JVM. Always. Windows may be a functional platform, but may not be a better
choice over 64-bit Linux.
Since you ran out of heap, you'll need some more RAM. This is really
symptomatic of the env.
> OutOfMemoryError in OptionalTasks
> -
>
> Key: CASSANDRA-8070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8070
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows-7-32 bit, 3GB RAM, Java 1.7.0_67
>Reporter: Andreas Schnitzerling
> Attachments: system.log
>
>
> Since update of 2 of 12 nodes from 2.0.10 to 2.1-release Exception during
> operation.
> {panel:title=system.log}
> ERROR [OptionalTasks:1] 2014-10-02 09:26:42,821 CassandraDaemon.java:166 -
> Exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.OutOfMemoryError: Java heap space
> at com.yammer.metrics.stats.Snapshot.(Snapshot.java:30)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.getSnapshot(ExponentiallyDecayingSample.java:131)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.getSnapshot(Histogram.java:180)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.getSnapshot(Timer.java:183)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$2.run(ColumnFamilyStore.java:340)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:75)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
> [na:1.7.0_67]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
> Source) [na:1.7.0_67]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source) [na:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> [na:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> [na:1.7.0_67]
> at java.lang.Thread.run(Unknown Source) [na:1.7.0_67]
> {panel}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7423) Allow updating individual subfields of UDT
[ https://issues.apache.org/jira/browse/CASSANDRA-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-7423: --- Tester: Philip Thompson Fix Version/s: 3.0 > Allow updating individual subfields of UDT > -- > > Key: CASSANDRA-7423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7423 > Project: Cassandra > Issue Type: Improvement > Components: API, Core >Reporter: Tupshin Harper > Labels: cql > Fix For: 3.0 > > > Since user defined types were implemented in CASSANDRA-5590 as blobs (you > have to rewrite the entire type in order to make any modifications), they > can't be safely used without LWT for any operation that wants to modify a > subset of the UDT's fields by any client process that is not authoritative > for the entire blob. > When trying to use UDTs to model complex records (particularly with nesting), > this is not an exceptional circumstance, this is the totally expected normal > situation. > The use of UDTs for anything non-trivial is harmful to either performance or > consistency or both. > edit: to clarify, i believe that most potential uses of UDTs should be > considered anti-patterns until/unless we have field-level r/w access to > individual elements of the UDT, with individual timestamps and standard LWW > semantics -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205140#comment-14205140 ] Mikhail Stepura commented on CASSANDRA-7874: @JoshuaMcKenzie could you please review v5 ? > Validate functionality of different JSR-223 providers in UDFs > - > > Key: CASSANDRA-7874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7874 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Fix For: 3.0 > > Attachments: 7874.txt, 7874v2.txt, 7874v3.txt, 7874v4.txt, 7874v5.txt > > > CASSANDRA-7526 introduces ability to support optional JSR-223 providers like > Clojure, Jython, Groovy or JRuby. > This ticket is about to test functionality with these providers but not to > include them in C* distribution. > Expected result is a "how to" document, wiki page or similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8158) network_topology_test is failing with inconsistent results
[ https://issues.apache.org/jira/browse/CASSANDRA-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205135#comment-14205135 ] Michael Shuler commented on CASSANDRA-8158: --- This test also leaves behind ccm nodes when it fails > network_topology_test is failing with inconsistent results > -- > > Key: CASSANDRA-8158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8158 > Project: Cassandra > Issue Type: Test >Reporter: Philip Thompson > > replication_test.py:ReplicationTest.network_topology_test is a no vnode test > that has been failing in 2.0 and 2.1 for quite a while. Sample cassci output > here: > http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/lastCompletedBuild/testReport/replication_test/ReplicationTest/network_topology_test/ > The missing replicas marked in the failure output are very inconsistent. Due > to the fact that it is failing on practically every version, and no bugs have > been filed relating to a failure of the feature this is testing, there is > most likely an issue with the test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8265) Disable SSLv3 for POODLE
[ https://issues.apache.org/jira/browse/CASSANDRA-8265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205118#comment-14205118 ] Michael Shuler commented on CASSANDRA-8265: --- Sounds reasonable to me. Is there a safety net of enabling SSLv3 if a user needs it? (Haven't played with ssl in c*) > Disable SSLv3 for POODLE > > > Key: CASSANDRA-8265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8265 > Project: Cassandra > Issue Type: Bug >Reporter: Jeremiah Jordan > > We should probably disable SSLv3. > http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8122) Undeclare throwable exception while executing 'nodetool netstats localhost'
[
https://issues.apache.org/jira/browse/CASSANDRA-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205114#comment-14205114
]
Michael Shuler commented on CASSANDRA-8122:
---
[~molsson] would you be so kind as to recreate your patch without whitespace
modifications? Thanks!
> Undeclare throwable exception while executing 'nodetool netstats localhost'
> ---
>
> Key: CASSANDRA-8122
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8122
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra: 2.0.9
>Reporter: Vishal Mehta
>Priority: Minor
> Attachments: CASSANDRA-8122.patch
>
>
> *Steps*
> # Stop cassandra service
> # Check netstats of nodetool using 'nodetool netstats localhost'
> # Start cassandra service
> # Again check netstats of nodetool using 'nodetool netstats localhost'
> *Expected output*
> Mode: STARTING
> Not sending any streams. (End of output - no further exceptions)
> *Observed output*
> {noformat}
> nodetool netstats localhost
> Mode: STARTING
> Not sending any streams.
> Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
> at com.sun.proxy.$Proxy6.getReadRepairAttempted(Unknown Source)
> at
> org.apache.cassandra.tools.NodeProbe.getReadRepairAttempted(NodeProbe.java:897)
> at
> org.apache.cassandra.tools.NodeCmd.printNetworkStats(NodeCmd.java:726)
> at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:1281)
> Caused by: javax.management.InstanceNotFoundException:
> org.apache.cassandra.db:type=StorageProxy
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1464)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at
> javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:657)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
> 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:724)
> at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160)
> at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
> at
> javax.management.remote.rmi.RMIConnectionImpl_Stub.getAttribute(Unknown
> Source)
> at
> javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getAttribute(RMIConnector.java:902)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:267)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7826) support non-frozen, nested collections
[ https://issues.apache.org/jira/browse/CASSANDRA-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205111#comment-14205111 ] Philip Thompson commented on CASSANDRA-7826: Will this support arbitrary nesting? If not, to what depth will we be able to nest collections? Given CASSANDRA-7396 and CASSANDRA-7423, and [~thobbs] earlier comments, we will be able to update and retrieve individual elements from the root collection and any nested collections, correct? > support non-frozen, nested collections > -- > > Key: CASSANDRA-7826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7826 > Project: Cassandra > Issue Type: Improvement > Components: API, Core >Reporter: Tupshin Harper >Assignee: Tyler Hobbs > Labels: ponies > Fix For: 3.0 > > > The inability to nest collections is one of the bigger data modelling > limitations we have right now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7396) Allow selecting Map key, List index
[ https://issues.apache.org/jira/browse/CASSANDRA-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-7396: --- Tester: Philip Thompson [~snazy] I've written some tentative dtests based on the grammar you outlined. Thoughts? https://github.com/riptano/cassandra-dtest/commit/331e704a9406c3ade1e99d949767a86e6601b52a > Allow selecting Map key, List index > --- > > Key: CASSANDRA-7396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7396 > Project: Cassandra > Issue Type: New Feature > Components: API >Reporter: Jonathan Ellis >Assignee: Robert Stupp > Labels: cql > Fix For: 3.0 > > > Allow "SELECT map['key]" and "SELECT list[index]." (Selecting a UDT subfield > is already supported.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8211) Overlapping sstables in L1+
[
https://issues.apache.org/jira/browse/CASSANDRA-8211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205007#comment-14205007
]
Marcus Eriksson commented on CASSANDRA-8211:
i think it could happen if we have overlapping in L1, then pick compaction
candidates for L2 with a bit of bad luck
> Overlapping sstables in L1+
> ---
>
> Key: CASSANDRA-8211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8211
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.0.12
>
> Attachments: 0001-Avoid-overlaps-in-L1-v2.patch,
> 0001-Avoid-overlaps-in-L1.patch
>
>
> Seems we have a bug that can create overlapping sstables in L1:
> {code}
> WARN [main] 2014-10-28 04:09:42,295 LeveledManifest.java (line 164) At level
> 2, SSTableReader(path='') [DecoratedKey(2838397575996053472, 00
> 10066059b210066059b210400100),
> DecoratedKey(5516674013223138308,
> 001000ff2d161000ff2d160
> 00010400100)] overlaps
> SSTableReader(path='') [DecoratedKey(2839992722300822584,
> 0010
> 00229ad21000229ad210400100),
> DecoratedKey(5532836928694021724,
> 0010034b05a610034b05a6100
> 000400100)]. This could be caused by a bug in
> Cassandra 1.1.0 .. 1.1.3 or due to the fact that you have dropped sstables
> from another node into the data directory. Sending back to L0. If
> you didn't drop in sstables, and have not yet run scrub, you should do so
> since you may also have rows out-of-order within an sstable
> {code}
> Which might manifest itself during compaction with this exception:
> {code}
> ERROR [CompactionExecutor:3152] 2014-10-28 00:24:06,134 CassandraDaemon.java
> (line 199) Exception in thread Thread[CompactionExecutor:3152,1,main]
> java.lang.RuntimeException: Last written key
> DecoratedKey(5516674013223138308,
> 001000ff2d161000ff2d1610400100)
> >= current key DecoratedKey(2839992722300822584,
> 001000229ad21000229ad210400100)
> writing into
> {code}
> since we use LeveledScanner when compacting (the backing sstable scanner
> might go beyond the start of the next sstable scanner)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8211) Overlapping sstables in L1+
[
https://issues.apache.org/jira/browse/CASSANDRA-8211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204994#comment-14204994
]
Nikolai Grigoriev commented on CASSANDRA-8211:
--
Could it happen at any level? I did use sstablesplit in my cluster and I have
recently spotted a number of messages like:
{code}
system.log.1: WARN [main] 2014-11-09 03:32:17,434 LeveledManifest.java (line
164) At level 1,
SSTableReader(path='/cassandra-data/disk2/myks/mytable1/myks-mytable1-jb-200217-Data.db')
[DecoratedKey(-163275977074170,
001001164335100116433510400100),
DecoratedKey(2116162112767472431,
001001432a4c1001432a4c10400100)]
overlaps
SSTableReader(path='/cassandra-data/disk3/myks/mytable1/myks-mytable1-jb-200215-Data.db')
[DecoratedKey(665029536263181199,
0010052d6e8d10052d6e8d10400100),
DecoratedKey(1008355148187355376,
001001135f971001135f9710400100)].
This could be caused by a bug in Cassandra 1.1.0 .. 1.1.3 or due to the fact
that you have dropped sstables from another node into the data directory.
Sending back to L0. If you didn’t drop in sstables, and have not yet run
scrub, you should do so since you may also have rows out-of-order within an
sstable
{code}
> Overlapping sstables in L1+
> ---
>
> Key: CASSANDRA-8211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8211
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.0.12
>
> Attachments: 0001-Avoid-overlaps-in-L1-v2.patch,
> 0001-Avoid-overlaps-in-L1.patch
>
>
> Seems we have a bug that can create overlapping sstables in L1:
> {code}
> WARN [main] 2014-10-28 04:09:42,295 LeveledManifest.java (line 164) At level
> 2, SSTableReader(path='') [DecoratedKey(2838397575996053472, 00
> 10066059b210066059b210400100),
> DecoratedKey(5516674013223138308,
> 001000ff2d161000ff2d160
> 00010400100)] overlaps
> SSTableReader(path='') [DecoratedKey(2839992722300822584,
> 0010
> 00229ad21000229ad210400100),
> DecoratedKey(5532836928694021724,
> 0010034b05a610034b05a6100
> 000400100)]. This could be caused by a bug in
> Cassandra 1.1.0 .. 1.1.3 or due to the fact that you have dropped sstables
> from another node into the data directory. Sending back to L0. If
> you didn't drop in sstables, and have not yet run scrub, you should do so
> since you may also have rows out-of-order within an sstable
> {code}
> Which might manifest itself during compaction with this exception:
> {code}
> ERROR [CompactionExecutor:3152] 2014-10-28 00:24:06,134 CassandraDaemon.java
> (line 199) Exception in thread Thread[CompactionExecutor:3152,1,main]
> java.lang.RuntimeException: Last written key
> DecoratedKey(5516674013223138308,
> 001000ff2d161000ff2d1610400100)
> >= current key DecoratedKey(2839992722300822584,
> 001000229ad21000229ad210400100)
> writing into
> {code}
> since we use LeveledScanner when compacting (the backing sstable scanner
> might go beyond the start of the next sstable scanner)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6544) Reduce GC activity during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-6544: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Reduce GC activity during compaction > > > Key: CASSANDRA-6544 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6544 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Vijay >Assignee: Vijay > Labels: compaction > Fix For: 2.1.3 > > > We are noticing increase in P99 while the compactions are running at full > stream. Most of it is because of the increased GC activity (followed by full > GC). > The obvious solution/work around is to throttle the compactions, but with > SSD's we can get more disk bandwidth for reads and compactions. > It will be nice to move the compaction object allocations off heap. First > thing to do might be create a Offheap Slab allocator with the size as the > compaction in memory size and recycle it. > Also we might want to make it configurable so folks can disable it when they > don't have off-heap memory to reserve. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8055) Centralize shared executors
[ https://issues.apache.org/jira/browse/CASSANDRA-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8055: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Centralize shared executors > --- > > Key: CASSANDRA-8055 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8055 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: lhf > Fix For: 2.1.3 > > > As mentioned in CASSANDRA-7930 we should put shared executors in a common > class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7113) Unhandled ClassCastException Around Migrations
[
https://issues.apache.org/jira/browse/CASSANDRA-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-7113:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Unhandled ClassCastException Around Migrations
> --
>
> Key: CASSANDRA-7113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7113
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
> Fix For: 2.1.3
>
>
> I'm having trouble reproducing this, but a run of the pycassa integration
> tests against the latest 2.1 left this in the logs:
> {noformat}
> INFO [MigrationStage:1] 2014-04-29 18:42:22,088 DefsTables.java:388 -
> Loading
> org.apache.cassandra.config.CFMetaData@52f225c1[cfId=e8c08650-cff7-11e3-8109-6b09a6cc3d5a,ksName=PycassaTestKeyspace,cfName=SingleComposite,cfType=Standard,comparator=org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.IntegerType),comment=,readRepairChance=0.1,dclocalReadRepairChance=0.0,gcGraceSeconds=864000,defaultValidator=org.apache.cassandra.db.marshal.BytesType,keyValidator=org.apache.cassandra.db.marshal.BytesType,minCompactionThreshold=4,maxCompactionThreshold=32,columnMetadata={java.nio.HeapByteBuffer[pos=0
> lim=3 cap=3]=ColumnDefinition{name=key,
> type=org.apache.cassandra.db.marshal.BytesType, kind=PARTITION_KEY,
> componentIndex=null, indexName=null, indexType=null},
> java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]=ColumnDefinition{name=value,
> type=org.apache.cassandra.db.marshal.BytesType, kind=COMPACT_VALUE,
> componentIndex=null, indexName=null, indexType=null},
> java.nio.HeapByteBuffer[pos=0 lim=7 cap=7]=ColumnDefinition{name=column1,
> type=org.apache.cassandra.db.marshal.IntegerType, kind=CLUSTERING_COLUMN,
> componentIndex=0, indexName=null,
> indexType=null}},compactionStrategyClass=class
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,compactionStrategyOptions={},compressionParameters={sstable_compression=org.apache.cassandra.io.compress.LZ4Compressor},bloomFilterFpChance=,memtableFlushPeriod=0,caching={"keys":"ALL",
>
> "rows_per_partition":"NONE"},defaultTimeToLive=0,minIndexInterval=128,maxIndexInterval=2048,speculativeRetry=NONE,droppedColumns={},triggers={}]
> INFO [MigrationStage:1] 2014-04-29 18:42:22,090 ColumnFamilyStore.java:285 -
> Initializing PycassaTestKeyspace.SingleComposite
> INFO [CompactionExecutor:9] 2014-04-29 18:42:22,096 CompactionTask.java:252
> - Compacted 4 sstables to
> [/var/lib/cassandra/data/system/schema_columns-296e9c049bec3085827dc17d3df2122a/system-schema_columns-ka-169,].
> 18,036 bytes to 17,507 (~97% of original) in 23ms = 0.725912MB/s. 7 total
> partitions merged to 4. Partition merge counts were {1:3, 4:1, }
> ERROR [Thrift:24] 2014-04-29 18:42:22,109 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.lang.ClassCastException: null
> ERROR [Thrift:34] 2014-04-29 18:42:22,130 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.lang.ClassCastException: null
> ERROR [Thrift:25] 2014-04-29 18:42:22,173 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.lang.ClassCastException: null
> ERROR [Thrift:11] 2014-04-29 18:42:22,258 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.lang.ClassCastException: null
> ERROR [Thrift:16] 2014-04-29 18:42:22,422 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.lang.ClassCastException: null
> ERROR [Thrift:26] 2014-04-29 18:42:22,747 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.lang.ClassCastException: null
> INFO [Thrift:7] 2014-04-29 18:42:22,790 MigrationManager.java:220 - Create
> new ColumnFamily:
> org.apache.cassandra.config.CFMetaData@461a7048[cfId=e9380040-cff7-11e3-8109-6b09a6cc3d5a,ksName=PycassaTestKeyspace,cfName=UUIDComposite,cfType=Standard,comparator=org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.IntegerType),org.apache.cassandra.db.marshal.TimeUUIDType),comment=,readRepairChance=0.1,dclocalReadRepairChance=0.0,gcGraceSeconds=864000,defaultValidator=org.apache.cassandra.db.marshal.UTF8Type,keyValidator=org.apache.cassandra.db.marshal.TimeUUIDType,minCompactionThreshold=4,maxCompactionThreshold=32,columnMetadata={java.nio.HeapByteBuffer[pos=0
> lim=3 cap=3]=ColumnDefinition{name=key,
> type=org.apache.cassandra.db.marshal.TimeUUIDType, kind=PARTITION_KEY,
> componentIndex=null, indexName=null, indexType=null},
> java.nio.HeapByteBuffer[pos=0 lim=7 cap=7]=ColumnDefinition{name=column2,
> type=org.apache.cassandra.db.marshal.TimeUUIDType, kind=CLUSTERING_COLUMN,
[jira] [Updated] (CASSANDRA-8221) Specify keyspace in error message when streaming fails due to missing replicas
[ https://issues.apache.org/jira/browse/CASSANDRA-8221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8221: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Specify keyspace in error message when streaming fails due to missing replicas > -- > > Key: CASSANDRA-8221 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8221 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Tyler Hobbs >Assignee: Rajanarayanan Thottuvaikkatumana >Priority: Trivial > Labels: lhf > Fix For: 2.0.12, 2.1.3 > > Attachments: cassandra-2.0.11-8221.txt, cassandra-2.1.1-8221.txt > > > When there aren't sufficient live replicas for streaming (during bootstrap, > etc), you'll get an error message like "unable to find sufficient sources for > streaming range". It would be helpful to include the keyspace that this > failed for, since each keyspace can have different replication settings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[ https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7386: -- Fix Version/s: (was: 2.1.2) 2.1.3 > JBOD threshold to prevent unbalanced disk utilization > - > > Key: CASSANDRA-7386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7386 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Assignee: Ryan McGuire >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, > mean-writevalue-7disks.png, patch_2_1_branch_proto.diff, > sstable-count-second-run.png > > > Currently the pick the disks are picked first by number of current tasks, > then by free space. This helps with performance but can lead to large > differences in utilization in some (unlikely but possible) scenarios. Ive > seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and > STCS (although my suspicion is that STCS makes it worse since harder to be > balanced). > I purpose the algorithm change a little to have some maximum range of > utilization where it will pick by free space over load (acknowledging it can > be slower). So if a disk A is 30% full and disk B is 5% full it will never > pick A over B until it balances out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6018) Add option to encrypt commitlog
[ https://issues.apache.org/jira/browse/CASSANDRA-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-6018: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Add option to encrypt commitlog > > > Key: CASSANDRA-6018 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6018 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jason Brown >Assignee: Jason Brown > Labels: commit_log, encryption, security > Fix For: 2.1.3 > > > We are going to start using cassandra for a billing system, and while I can > encrypt sstables at rest (via Datastax Enterprise), commit logs are more or > less plain text. Thus, an attacker would be able to easily read, for example, > credit card numbers in the clear text commit log (if the calling app does not > encrypt the data itself before sending it to cassandra). > I want to allow the option of encrypting the commit logs, most likely > controlled by a property in the yaml. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7645) cqlsh: show partial trace if incomplete after max_trace_wait
[
https://issues.apache.org/jira/browse/CASSANDRA-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-7645:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> cqlsh: show partial trace if incomplete after max_trace_wait
>
>
> Key: CASSANDRA-7645
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7645
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Trivial
> Fix For: 2.1.3
>
>
> If a trace hasn't completed within {{max_trace_wait}}, cqlsh will say the
> trace is unavailable and not show anything. It (and the underlying python
> driver) determines when the trace is complete by checking if the {{duration}}
> column in {{system_traces.sessions}} is non-null. If {{duration}} is null
> but we still have some trace events when the timeout is hit, cqlsh should
> print whatever trace events we have along with a warning about it being
> incomplete.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7217) Native transport performance (with cassandra-stress) drops precipitously past around 1000 threads
[ https://issues.apache.org/jira/browse/CASSANDRA-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7217: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Native transport performance (with cassandra-stress) drops precipitously past > around 1000 threads > - > > Key: CASSANDRA-7217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7217 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benedict >Assignee: Shawn Kumar > Labels: performance, triaged > Fix For: 2.1.3 > > > This is obviously bad. Let's figure out why it's happening and put a stop to > it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8012) cqlsh "DESCRIBE KEYSPACES;" returns empty after upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8012:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> cqlsh "DESCRIBE KEYSPACES;" returns empty after upgrade
> ---
>
> Key: CASSANDRA-8012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8012
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: cassandra 2.1.0
>Reporter: Shawn Zhou
>Assignee: Tyler Hobbs
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.3
>
>
> after upgrade from 2.0.7 to 2.1.0
> run cqlsh "DESCRIBE KEYSPACES;" returns empty result;
> query individual table does return data;
> See below:
> {noformat}
> [root@dc1-stg-cassandra-08 cassandra]# cqlsh
> dc1-stg-cassandra-08.dc01.revsci.net -k as_user_segment
> Connected to Stage Cluster at dc1-stg-cassandra-08.dc01.revsci.net:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> Use HELP for help.
> cqlsh:as_user_segment> DESCRIBE KEYSPACES;
>
> cqlsh:as_user_segment> select * from user_segments_blob where id =
> '8e6090087fc1a7591a99dc4cb744ac43';
> id | segments
> --+
> 8e6090087fc1a7591a99dc4cb744ac43 |
> 0x9416b015911d3b0e211aee227216ab1cdf0f4204
> (1 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7555) Support copy and link for commitlog archiving without forking the jvm
[ https://issues.apache.org/jira/browse/CASSANDRA-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7555: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Support copy and link for commitlog archiving without forking the jvm > - > > Key: CASSANDRA-7555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7555 > Project: Cassandra > Issue Type: Improvement >Reporter: Nick Bailey >Assignee: Joshua McKenzie >Priority: Minor > Fix For: 2.1.3 > > > Right now for commitlog archiving the user specifies a command to run and c* > forks the jvm to run that command. The most common operations will be either > copy or link (hard or soft). Since we can do all of these operations without > forking the jvm, which is very expensive, we should have special cases for > those. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7623) Altering keyspace truncates DESCRIBE output until you reconnect.
[
https://issues.apache.org/jira/browse/CASSANDRA-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-7623:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Altering keyspace truncates DESCRIBE output until you reconnect.
>
>
> Key: CASSANDRA-7623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7623
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ryan McGuire
>Assignee: Tyler Hobbs
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.3
>
>
> Run DESCRIBE on a keyspace:
> {code}
> cqlsh> DESCRIBE KEYSPACE system_traces ;
> CREATE KEYSPACE system_traces WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '2'} AND durable_writes = true;
> CREATE TABLE system_traces.events (
> session_id uuid,
> event_id timeuuid,
> activity text,
> source inet,
> source_elapsed int,
> thread text,
> PRIMARY KEY (session_id, event_id)
> ) WITH CLUSTERING ORDER BY (event_id ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'min_threshold': '4', 'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 0
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 360
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> CREATE TABLE system_traces.sessions (
> session_id uuid PRIMARY KEY,
> coordinator inet,
> duration int,
> parameters map,
> request text,
> started_at timestamp
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'traced sessions'
> AND compaction = {'min_threshold': '4', 'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 0
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 360
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> {code}
> Alter it and run DESCRIBE again:
> {code}
> cqlsh> ALTER KEYSPACE system_traces WITH durable_writes = false;
> cqlsh> DESCRIBE KEYSPACE system_traces ;
> CREATE KEYSPACE system_traces WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '2'} AND durable_writes = false;
> {code}
> You can issue the DESCRIBE command multiple times and get the same output.
> You have to disconnect and reconnect to get the table definition output to
> show again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-4763) SSTableLoader shouldn't get keyspace from path
[
https://issues.apache.org/jira/browse/CASSANDRA-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-4763:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> SSTableLoader shouldn't get keyspace from path
> --
>
> Key: CASSANDRA-4763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4763
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Affects Versions: 1.2.0 beta 1
>Reporter: Nick Bailey
>Priority: Minor
> Fix For: 2.1.3
>
>
> SSTableLoader currently gets the keyspace it is going to load to from the
> path of the directoy of sstables it is loading. This isn't really documented
> (or I didn't see it), but also isn't really a good way of doing it in general.
> {noformat}
> this.keyspace = directory.getParentFile().getName();
> {noformat}
> We should probably just let users pass the name in. If you are loading a
> snapshot the file names will have the keyspace which is slightly better but
> people manually creating their own sstables might not format them the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-4338) Experiment with direct buffer in SequentialWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-4338: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Experiment with direct buffer in SequentialWriter > - > > Key: CASSANDRA-4338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4338 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Labels: performance > Fix For: 2.1.3 > > Attachments: 4338-gc.tar.gz, 4338.benchmark.png, > 4338.benchmark.snappycompressor.png, 4338.single_node.read.png, > 4338.single_node.write.png, gc-4338-patched.png, gc-trunk-me.png, > gc-trunk.png, gc-with-patch-me.png > > > Using a direct buffer instead of a heap-based byte[] should let us avoid a > copy into native memory when we flush the buffer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7793) Utilize BATCH statements in COPY FROM
[ https://issues.apache.org/jira/browse/CASSANDRA-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7793: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Utilize BATCH statements in COPY FROM > - > > Key: CASSANDRA-7793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7793 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Mikhail Stepura >Priority: Minor > Labels: cqlsh > Fix For: 2.1.3 > > > If we assume that a significant subset of COPY FROM csv's are going to be > results of COPY TO command, then rows will be grouped by the partition key. > In that case we'd win from batching (until another partition key is met, and > constrained by some limit of rows per batch, we don't want huge batches) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7523: -- Fix Version/s: (was: 2.1.2) 2.1.3 > add date and time types > --- > > Key: CASSANDRA-7523 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7523 > Project: Cassandra > Issue Type: New Feature > Components: API >Reporter: Jonathan Ellis >Assignee: Joshua McKenzie >Priority: Minor > Labels: docs > Fix For: 2.1.3 > > > http://www.postgresql.org/docs/9.1/static/datatype-datetime.html > (we already have timestamp; interval is out of scope for now, and see > CASSANDRA-6350 for discussion on timestamp-with-time-zone. but date/time > should be pretty easy to add.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-4476) Support 2ndary index queries with only inequality clauses (LT, LTE, GT, GTE)
[ https://issues.apache.org/jira/browse/CASSANDRA-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-4476: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Support 2ndary index queries with only inequality clauses (LT, LTE, GT, GTE) > > > Key: CASSANDRA-4476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4476 > Project: Cassandra > Issue Type: Improvement > Components: API, Core >Reporter: Sylvain Lebresne >Priority: Minor > Labels: cql > Fix For: 2.1.3 > > Attachments: cassandra-trunk-4476.patch > > > Currently, a query that uses 2ndary indexes must have at least one EQ clause > (on an indexed column). Given that indexed CFs are local (and use > LocalPartitioner that order the row by the type of the indexed column), we > should extend 2ndary indexes to allow querying indexed columns even when no > EQ clause is provided. > As far as I can tell, the main problem to solve for this is to update > KeysSearcher.highestSelectivityPredicate(). I.e. how do we estimate the > selectivity of non-EQ clauses? I note however that if we can do that estimate > reasonably accurately, this might provide better performance even for index > queries that both EQ and non-EQ clauses, because some non-EQ clauses may have > a much better selectivity than EQ ones (say you index both the user country > and birth date, for SELECT * FROM users WHERE country = 'US' AND birthdate > > 'Jan 2009' AND birtdate < 'July 2009', you'd better use the birthdate index > first). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-3486) Node Tool command to stop repair
[ https://issues.apache.org/jira/browse/CASSANDRA-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-3486: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Node Tool command to stop repair > > > Key: CASSANDRA-3486 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3486 > Project: Cassandra > Issue Type: Improvement > Components: Tools > Environment: JVM >Reporter: Vijay >Assignee: Jason Brown >Priority: Minor > Labels: repair > Fix For: 2.1.3 > > Attachments: 0001-stop-repair-3583.patch > > > After CASSANDRA-1740, If the validation compaction is stopped then the repair > will hang. This ticket will allow users to kill the original repair. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6382) Allow indexing nested types
[ https://issues.apache.org/jira/browse/CASSANDRA-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-6382: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Allow indexing nested types > --- > > Key: CASSANDRA-6382 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6382 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Labels: cql > Fix For: 2.1.3 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8132) Save or stream hints to a safe place in node replacement
[ https://issues.apache.org/jira/browse/CASSANDRA-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8132: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Save or stream hints to a safe place in node replacement > > > Key: CASSANDRA-8132 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8132 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Minh Do >Assignee: Minh Do > Fix For: 2.1.3 > > > Often, we need to replace a node with a new instance in the cloud environment > where we have all nodes are still alive. To be safe without losing data, we > usually make sure all hints are gone before we do this operation. > Replacement means we just want to shutdown C* process on a node and bring up > another instance to take over that node's token. > However, if a node to be replaced has a lot of stored hints, its > HintedHandofManager seems very slow to send the hints to other nodes. In our > case, we tried to replace a node and had to wait for several days before its > stored hints are clear out. As mentioned above, we need all hints on this > node to clear out before we can terminate it and replace it by a new > instance/machine. > Since this is not a decommission, I am proposing that we have the same > hints-streaming mechanism as in the decommission code. Furthermore, there > needs to be a cmd for NodeTool to trigger this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8019:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Labels: windows
> Fix For: 2.1.3
>
> Attachments: 8019_aggressive_v1.txt, 8019_conservative_v1.txt,
> 8019_v2.txt
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7130) Make sstable checksum type configurable and optional
[ https://issues.apache.org/jira/browse/CASSANDRA-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7130: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Make sstable checksum type configurable and optional > > > Key: CASSANDRA-7130 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7130 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Jason Brown >Priority: Minor > Labels: performance > Fix For: 2.1.3 > > > A lot of our users are becoming bottlenecked on CPU rather than IO, and > whilst Adler32 is faster than CRC, it isn't anything like as fast as xxhash > (used by LZ4), which can push Gb/s. I propose making the checksum type > configurable so that users who want speed can shift to xxhash, and those who > want security can use Adler or CRC. > It's worth noting that at some point in the future (JDK8?) optimised > implementations using latest intel crc instructions will be added, though > it's not clear from the mailing list discussion if/when that will materialise: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-May/010775.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8263) Cqlshlib tests are mostly stubs
[
https://issues.apache.org/jira/browse/CASSANDRA-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8263:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Cqlshlib tests are mostly stubs
> ---
>
> Key: CASSANDRA-8263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8263
> Project: Cassandra
> Issue Type: Test
>Reporter: Philip Thompson
>Assignee: Philip Thompson
> Labels: cqlsh
> Fix For: 2.1.3
>
>
> Most of the tests in cqlshlib/tests are just stubs that look like: {code}
> def test_parse_create_index(self):
> pass
> def test_parse_drop_index(self):
> pass
> {code}
> These tests need implemented.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7974) Enable tooling to detect hot partitions
[ https://issues.apache.org/jira/browse/CASSANDRA-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7974: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Enable tooling to detect hot partitions > --- > > Key: CASSANDRA-7974 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7974 > Project: Cassandra > Issue Type: Improvement >Reporter: Brandon Williams >Assignee: Chris Lohfink > Fix For: 2.1.3 > > Attachments: 7974.txt, cassandra-2.1-7974v2.txt > > > Sometimes you know you have a hot partition by the load on a replica set, but > have no way of determining which partition it is. Tracing is inadequate for > this without a lot of post-tracing analysis that might not yield results. > Since we already include stream-lib for HLL in compaction metadata, it > shouldn't be too hard to wire up topK for X seconds via jmx/nodetool and then > return the top partitions hit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8162) Log client address in query trace
[ https://issues.apache.org/jira/browse/CASSANDRA-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8162: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Log client address in query trace > - > > Key: CASSANDRA-8162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8162 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs >Priority: Minor > Fix For: 2.1.3 > > > With probabilistic tracing, it can be helpful to log the source IP for > queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7021) With tracing enabled, queries should still be recorded when using prepared and batch statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7021: -- Fix Version/s: (was: 2.1.2) 2.1.3 > With tracing enabled, queries should still be recorded when using prepared > and batch statements > --- > > Key: CASSANDRA-7021 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7021 > Project: Cassandra > Issue Type: Improvement > Components: Core > Environment: C* 2.0.6 running on Ubuntu 12.04 >Reporter: Bill Joyce >Assignee: Tyler Hobbs >Priority: Minor > Fix For: 2.1.3 > > > I've enabled tracing on my cluster and am analyzing data in the > system_traces.sessions table. Single statement, non-prepared queries show up > with data in the 'parameters' field like 'query=select * from tablename where > x=1' and the request field is execute_cql3_query. But batches have null in > the parameters field and prepared statements just have 'page size=5000' in > the parameters field (the request field values are 'Execute batch of CQL3 > queries' and 'Execute CQL3 prepared query'). Please include the actual query > text with prepared and batch statements. This will make performance analysis > much easier so I can do things like sort by duration and find my most > expensive queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8238) NPE in SizeTieredCompactionStrategy.filterColdSSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8238:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> NPE in SizeTieredCompactionStrategy.filterColdSSTables
> --
>
> Key: CASSANDRA-8238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8238
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Marcus Eriksson
> Fix For: 2.1.3
>
>
> {noformat}
> ERROR [CompactionExecutor:15] 2014-10-31 15:28:32,318
> CassandraDaemon.java:153 - Exception in thread
> Thread[CompactionExecutor:15,1,main]
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.filterColdSSTables(SizeTieredCompactionStrategy.java:181)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:83)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:267)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:226)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_72]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_72]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_72]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_72]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_72]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8225) Production-capable COPY FROM
[
https://issues.apache.org/jira/browse/CASSANDRA-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8225:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Production-capable COPY FROM
>
>
> Key: CASSANDRA-8225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8225
> Project: Cassandra
> Issue Type: New Feature
> Components: Tools
>Reporter: Jonathan Ellis
>Assignee: Tyler Hobbs
> Fix For: 2.1.3
>
>
> Via [~schumacr],
> bq. I pulled down a sourceforge data generator and created a moc file of
> 500,000 rows that had an incrementing sequence number, date, and SSN. I then
> used our COPY command and MySQL's LOAD DATA INFILE to load the file on my
> Mac. Results were:
> {noformat}
> mysql> load data infile '/Users/robin/dev/datagen3.txt' into table p_test
> fields terminated by ',';
> Query OK, 50 rows affected (2.18 sec)
> {noformat}
> C* 2.1.0 (pre-CASSANDRA-7405)
> {noformat}
> cqlsh:dev> copy p_test from '/Users/robin/dev/datagen3.txt' with
> delimiter=',';
> 50 rows imported in 16 minutes and 45.485 seconds.
> {noformat}
> Cassandra 2.1.1:
> {noformat}
> cqlsh:dev> copy p_test from '/Users/robin/dev/datagen3.txt' with
> delimiter=',';
> Processed 50 rows; Write: 4037.46 rows/s
> 50 rows imported in 2 minutes and 3.058 seconds.
> {noformat}
> [jbellis] 7405 gets us almost an order of magnitude improvement.
> Unfortunately we're still almost 2 orders slower than mysql.
> I don't think we can continue to tell people, "use sstableloader instead."
> The number of users sophisticated enough to use the sstable writers is small
> and (relatively) decreasing as our user base expands.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8148) sstableloader needs ability to stream to private IP
[ https://issues.apache.org/jira/browse/CASSANDRA-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8148: -- Fix Version/s: (was: 2.1.2) 2.1.3 > sstableloader needs ability to stream to private IP > --- > > Key: CASSANDRA-8148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8148 > Project: Cassandra > Issue Type: Improvement >Reporter: Yuki Morishita > Fix For: 2.1.3 > > > sstableloader gets where to stream from the contacting node, but destinations > returned are all broadcast address. > It is nice if we can somehow tell sstableloader to stream to private IP > instead. > To do this, we have to find the way to load cassandra topology to > sstableloader. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8213) Grant Permission fails if permission had been revoked previously
[
https://issues.apache.org/jira/browse/CASSANDRA-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8213:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Grant Permission fails if permission had been revoked previously
>
>
> Key: CASSANDRA-8213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8213
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Aleksey Yeschenko
> Fix For: 2.1.3
>
>
> The dtest auth_test.py:TestAuth.alter_cf_auth_test is failing.
> {code}
> cassandra.execute("GRANT ALTER ON ks.cf TO cathy")
> cathy.execute("ALTER TABLE ks.cf ADD val int")
> cassandra.execute("REVOKE ALTER ON ks.cf FROM cathy")
> self.assertUnauthorized("User cathy has no ALTER permission on ks.cf> or any of its parents",
> cathy, "CREATE INDEX ON ks.cf(val)")
> cassandra.execute("GRANT ALTER ON ks.cf TO cathy")
> cathy.execute("CREATE INDEX ON ks.cf(val)")
> {code}
> In this section of code, the user cathy is granted "ALTER" permissions on
> 'ks.cf', then they are revoked, then granted again. Monitoring
> system_auth.permissions during this section of code show that the permission
> is added with the initial grant, and revoked properly, but the table remains
> empty after the second grant.
> When the cathy user attempts to create an index, the following exception is
> thrown:
> {code}
> Unauthorized: code=2100 [Unauthorized] message="User cathy has no ALTER
> permission on or any of its parents"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7855) Genralize use of IN for compound partition keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-7855:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Genralize use of IN for compound partition keys
> ---
>
> Key: CASSANDRA-7855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7855
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql
> Fix For: 2.1.3
>
>
> When you have a compount partition key, we currently only support to have a
> {{IN}} on the last column of that partition key. So given:
> {noformat}
> CREATE TABLE foo (
> k1 int,
> k2 int,
> v int,
> PRIMARY KEY ((k1, k2))
> )
> {noformat}
> we allow
> {noformat}
> SELECT * FROM foo WHERE k1 = 0 AND k2 IN (1, 2)
> {noformat}
> but not
> {noformat}
> SELECT * FROM foo WHERE k1 IN (0, 1) AND k2 IN (1, 2)
> {noformat}
> There is no particular reason for us not supporting the later (to the best of
> my knowledge) since it's reasonably straighforward, so we should fix it.
> I'll note that using {{IN}} on a partition key is not necessarily a better
> idea than parallelizing queries server client side so this syntax, when
> introduced, should probably be used sparingly, but given we do support IN on
> partition keys, I see no reason not to extend it to compound PK properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8177) sequential repair is much more expensive than parallel repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8177: -- Fix Version/s: (was: 2.1.2) 2.1.3 > sequential repair is much more expensive than parallel repair > - > > Key: CASSANDRA-8177 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8177 > Project: Cassandra > Issue Type: Bug >Reporter: Sean Bridges >Assignee: Yuki Morishita > Fix For: 2.1.3 > > Attachments: cassc-week.png, iostats.png > > > This is with 2.0.10 > The attached graph shows io read/write throughput (as measured with iostat) > when doing repairs. > The large hump on the left is a sequential repair of one node. The two much > smaller peaks on the right are parallel repairs. > This is a 3 node cluster using vnodes (I know vnodes on small clusters isn't > recommended). Cassandra reports load of 40 gigs. > We noticed a similar problem with a larger cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7910) wildcard prepared statements are incorrect after a column is added to the table
[ https://issues.apache.org/jira/browse/CASSANDRA-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7910: -- Fix Version/s: (was: 2.1.2) 2.1.3 > wildcard prepared statements are incorrect after a column is added to the > table > --- > > Key: CASSANDRA-7910 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7910 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Oded Peer >Assignee: Tyler Hobbs >Priority: Minor > Fix For: 2.1.3 > > Attachments: PreparedStatementAfterAddColumnTest.java > > > 1. Prepare a statement with a wildcard in the select clause. > 2. Alter the table - add a column > 3. execute the prepared statement > Expected result - get all the columns including the new column > Actual result - get the columns except the new column > Attached a test using cassandra-unit -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8092) Check for swallowed Throwable in CI environment
[ https://issues.apache.org/jira/browse/CASSANDRA-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8092: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Check for swallowed Throwable in CI environment > --- > > Key: CASSANDRA-8092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8092 > Project: Cassandra > Issue Type: Test >Reporter: Joshua McKenzie >Assignee: Michael Shuler >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7507_check_swallowed.txt > > > Reference CASSANDRA-7507. We don't want to swallow Throwable or Exception's > in the code-base but rather delegate them to the JVMStabilityInspector added > in that ticket. Attached patch adds a python script to tools\bin (maybe > incorrect placement) that'll check for Throwable and return count of > swallowed. It will also do the same for Exception if you pass it the flag > for that. > Ideally we'd integrate checking our code-base on build in the CI environment > and fail if we have count > 0 on Throwable for now, and update it to include > Exception as well after CASSANDRA-7579. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7875) Prepared statements using dropped indexes are not handled correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-7875:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Prepared statements using dropped indexes are not handled correctly
> ---
>
> Key: CASSANDRA-7875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7875
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Minor
> Fix For: 2.1.3
>
> Attachments: repro.py
>
>
> When select statements are prepared, we verify that the column restrictions
> use indexes (where necessary). However, we don't perform a similar check
> when the statement is executed, so it fails somewhere further down the line.
> In this case, it hits an assertion:
> {noformat}
> java.lang.AssertionError: Sequential scan with filters is not supported (if
> you just created an index, you need to wait for the creation to be propagated
> to all nodes before querying it)
> at
> org.apache.cassandra.db.filter.ExtendedFilter$WithClauses.getExtraFilter(ExtendedFilter.java:259)
> at
> org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1759)
> at
> org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1709)
> at
> org.apache.cassandra.db.PagedRangeCommand.executeLocally(PagedRangeCommand.java:119)
> at
> org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1394)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1936)
> 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:724)
> {noformat}
> During execution, we should check that the indexes still exist and provide a
> better error if they do not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6323) Create new sstables in the highest possible level
[ https://issues.apache.org/jira/browse/CASSANDRA-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-6323: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Create new sstables in the highest possible level > - > > Key: CASSANDRA-6323 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6323 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Minh Do >Priority: Minor > Labels: compaction > Fix For: 2.1.3 > > > See PickLevelForMemTableOutput here: > https://code.google.com/p/leveldb/source/browse/db/version_set.cc#507 > (Moving from CASSANDRA-5936) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6388) delay vnode selection if bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-6388: -- Fix Version/s: (was: 2.1.2) 2.1.3 > delay vnode selection if bootstrapping > -- > > Key: CASSANDRA-6388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6388 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams > Fix For: 2.1.3 > > > Currently when bootstrapping with vnodes, we choose random vnodes first, then > bootstrap. Now that we do a shadow gossip round to prevent booting an > existing address, we could delay the token selection until after the shadow > round in order to choose more balanced tokens. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-5902: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 2.1.3 > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7016) can't map/reduce over subset of rows with cql
[ https://issues.apache.org/jira/browse/CASSANDRA-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7016: -- Fix Version/s: (was: 2.1.2) 2.1.3 > can't map/reduce over subset of rows with cql > - > > Key: CASSANDRA-7016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7016 > Project: Cassandra > Issue Type: Bug > Components: Core, Hadoop >Reporter: Jonathan Halliday >Assignee: Benjamin Lerer >Priority: Minor > Labels: cql > Fix For: 2.1.3 > > Attachments: CASSANDRA-7016-V2.txt, CASSANDRA-7016-V3.txt, > CASSANDRA-7016.txt > > > select ... where token(k) < x and token(k) >= y and k in (a,b) allow > filtering; > This fails on 2.0.6: can't restrict k by more than one relation. > In the context of map/reduce (hence the token range) I want to map over only > a subset of the keys (hence the 'in'). Pushing the 'in' filter down to cql > is substantially cheaper than pulling all rows to the client and then > discarding most of them. > Currently this is possible only if the hadoop integration code is altered to > apply the AND on the client side and use cql that contains only the resulting > filtered 'in' set. The problem is not hadoop specific though, so IMO it > should really be solved in cql not the hadoop integration code. > Most restrictions on cql syntax seem to exist to prevent unduly expensive > queries. This one seems to be doing the opposite. > Edit: on further thought and with reference to the code in > SelectStatement$RawStatement, it seems to me that token(k) and k should be > considered distinct entities for the purposes of processing restrictions. > That is, no restriction on the token should conflict with a restriction on > the raw key. That way any monolithic query in terms of k and be decomposed > into parallel chunks over the token range for the purposes of map/reduce > processing simply by appending a 'and where token(k)...' clause to the > exiting 'where k ...'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6572) Workload recording / playback
[ https://issues.apache.org/jira/browse/CASSANDRA-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-6572: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Workload recording / playback > - > > Key: CASSANDRA-6572 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6572 > Project: Cassandra > Issue Type: New Feature > Components: Core, Tools >Reporter: Jonathan Ellis >Assignee: Carl Yeksigian > Fix For: 2.1.3 > > Attachments: 6572-trunk.diff > > > "Write sample mode" gets us part way to testing new versions against a real > world workload, but we need an easy way to test the query side as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7688) Add data sizing to a system table
[ https://issues.apache.org/jira/browse/CASSANDRA-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7688: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Add data sizing to a system table > - > > Key: CASSANDRA-7688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7688 > Project: Cassandra > Issue Type: New Feature >Reporter: Jeremiah Jordan > Fix For: 2.1.3 > > > Currently you can't implement something similar to describe_splits_ex purely > from the a native protocol driver. > https://datastax-oss.atlassian.net/browse/JAVA-312 is open to expose easily > getting ownership information to a client in the java-driver. But you still > need the data sizing part to get splits of a given size. We should add the > sizing information to a system table so that native clients can get to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7190) Add schema to snapshot manifest
[ https://issues.apache.org/jira/browse/CASSANDRA-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7190: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Add schema to snapshot manifest > --- > > Key: CASSANDRA-7190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7190 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jonathan Ellis >Assignee: sankalp kohli >Priority: Minor > Fix For: 2.1.3 > > > followup from CASSANDRA-6326 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8085) Make PasswordAuthenticator number of hashing rounds configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8085: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Make PasswordAuthenticator number of hashing rounds configurable > > > Key: CASSANDRA-8085 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8085 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Tyler Hobbs >Assignee: Aleksey Yeschenko > Fix For: 2.1.3 > > > Running 2^10 rounds of bcrypt can take a while. In environments (like PHP) > where connections are not typically long-lived, authenticating can add > substantial overhead. On IRC, one user saw the time to connect, > authenticate, and execute a query jump from 5ms to 150ms with authentication > enabled ([debug logs|http://pastebin.com/bSUufbr0]). > CASSANDRA-7715 is a more complete fix for this, but in the meantime (and even > after 7715), this is a good option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7486) Compare CMS and G1 pause times
[ https://issues.apache.org/jira/browse/CASSANDRA-7486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7486: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Compare CMS and G1 pause times > -- > > Key: CASSANDRA-7486 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7486 > Project: Cassandra > Issue Type: Test > Components: Config >Reporter: Jonathan Ellis >Assignee: Shawn Kumar > Fix For: 2.1.3 > > > See > http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-7486gc-migration-to-expectations-and-advanced-tuning > and https://twitter.com/rbranson/status/482113561431265281 > May want to default 2.1 to G1. > 2.1 is a different animal from 2.0 after moving most of memtables off heap. > Suspect this will help G1 even more than CMS. (NB this is off by default but > needs to be part of the test.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8039) dh_pysupport -> dh_python2 debian packaging
[
https://issues.apache.org/jira/browse/CASSANDRA-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8039:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> dh_pysupport -> dh_python2 debian packaging
> ---
>
> Key: CASSANDRA-8039
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8039
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Shuler
>Priority: Minor
> Fix For: 2.1.3
>
>
> Noticed that dh_pysupport is deprecated in Jessie when I was building the deb:
> {noformat}
> dh_pysupport: This program is deprecated, you should use dh_python2 instead.
> Migration guide: http://deb.li/dhs2p
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7739) cassandra-stress: cannot handle "value-less" tables
[
https://issues.apache.org/jira/browse/CASSANDRA-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-7739:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> cassandra-stress: cannot handle "value-less" tables
> ---
>
> Key: CASSANDRA-7739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7739
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: T Jake Luciani
> Fix For: 2.1.3
>
>
> Given a table, that only has primary-key columns, cassandra-stress fails with
> this exception.
> The bug is, that
> https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/StressProfile.java#L281
> always adds the {{SET}} even if there are no "value columns" to update.
> {noformat}
> Exception in thread "main" java.lang.RuntimeException:
> InvalidRequestException(why:line 1:24 no viable alternative at input 'WHERE')
> at
> org.apache.cassandra.stress.StressProfile.getInsert(StressProfile.java:352)
> at
> org.apache.cassandra.stress.settings.SettingsCommandUser$1.get(SettingsCommandUser.java:66)
> at
> org.apache.cassandra.stress.settings.SettingsCommandUser$1.get(SettingsCommandUser.java:62)
> at
> org.apache.cassandra.stress.operations.SampledOpDistributionFactory$1.get(SampledOpDistributionFactory.java:76)
> at
> org.apache.cassandra.stress.StressAction$Consumer.(StressAction.java:248)
> at org.apache.cassandra.stress.StressAction.run(StressAction.java:188)
> at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:92)
> at org.apache.cassandra.stress.StressAction.run(StressAction.java:62)
> at org.apache.cassandra.stress.Stress.main(Stress.java:109)
> Caused by: InvalidRequestException(why:line 1:24 no viable alternative at
> input 'WHERE')
> at
> org.apache.cassandra.thrift.Cassandra$prepare_cql3_query_result$prepare_cql3_query_resultStandardScheme.read(Cassandra.java:52282)
> at
> org.apache.cassandra.thrift.Cassandra$prepare_cql3_query_result$prepare_cql3_query_resultStandardScheme.read(Cassandra.java:52259)
> at
> org.apache.cassandra.thrift.Cassandra$prepare_cql3_query_result.read(Cassandra.java:52198)
> at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
> at
> org.apache.cassandra.thrift.Cassandra$Client.recv_prepare_cql3_query(Cassandra.java:1797)
> at
> org.apache.cassandra.thrift.Cassandra$Client.prepare_cql3_query(Cassandra.java:1783)
> at
> org.apache.cassandra.stress.util.SimpleThriftClient.prepare_cql3_query(SimpleThriftClient.java:79)
> at
> org.apache.cassandra.stress.StressProfile.getInsert(StressProfile.java:348)
> ... 8 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7859) Extend freezing to collections
[
https://issues.apache.org/jira/browse/CASSANDRA-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-7859:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Extend freezing to collections
> --
>
> Key: CASSANDRA-7859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7859
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.1.3
>
> Attachments: 7859-v1.txt
>
>
> This is the follow-up to CASSANDRA-7857, to extend {{frozen}} to collections.
> This will allow things like {{map>>}} for
> instance, as well as allowing {{frozen}} collections in PK columns.
> Additionally (and that's alsmot a separate ticket but I figured we can start
> discussing it here), we could decide that tuple is a frozen type by default.
> This means that we would allow {{tuple}} without needing to add
> {{frozen}}, but we would require {{frozen}} for complex type inside tuple, so
> {{tuple>}} would be rejected, but not {{tuple frozen>>}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7926) Stress can OOM on merging of timing samples
[
https://issues.apache.org/jira/browse/CASSANDRA-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-7926:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Stress can OOM on merging of timing samples
> ---
>
> Key: CASSANDRA-7926
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7926
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Benedict
>Assignee: Benedict
>Priority: Minor
> Labels: tools
> Fix For: 2.1.3
>
>
> {noformat}
> Exception in thread "StressMetrics:2" java.lang.OutOfMemoryError: Java heap
> space
> at java.util.Arrays.copyOf(Arrays.java:2343)
> at
> org.apache.cassandra.stress.util.SampleOfLongs.merge(SampleOfLongs.java:76)
> at
> org.apache.cassandra.stress.util.TimingInterval.merge(TimingInterval.java:95)
> at
> org.apache.cassandra.stress.util.Timing.snapInterval(Timing.java:95)
> at
> org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:124)
> at
> org.apache.cassandra.stress.StressMetrics.access$200(StressMetrics.java:36)
> at
> org.apache.cassandra.stress.StressMetrics$1.run(StressMetrics.java:72)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
> This is partially down to recently increasing the per-thread sample size, but
> also because we allocate temporary space linear in size to total sample size
> in all threads during merge. This can easily be avoided. We should also scale
> per-thread sample size based on total number of threads, so we limit total
> memory use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8220) JDK bug prevents clean shutdown on OSX with Java 1.8.0_20
[
https://issues.apache.org/jira/browse/CASSANDRA-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8220:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> JDK bug prevents clean shutdown on OSX with Java 1.8.0_20
> -
>
> Key: CASSANDRA-8220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8220
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 2.1.3
>
> Attachments: jdk8050499.txt
>
>
> Clean shutdown on OSX with Java 1.8.0_20 does not work due to [JDK bug
> 8050499 fixed for Java 9|https://bugs.openjdk.java.net/browse/JDK-8050499].
> Supplied patch provides a (very dirty) workaround to (hopefully) allow
> shutdown.
> Exception during shutdown looks like this:
> {code}
> ERROR 22:23:15 Fatal exception in thread
> Thread[StorageServiceShutdownHook,5,main]
> java.io.IOError: java.io.IOException: Unknown error: 316
> at
> org.apache.cassandra.net.MessagingService.shutdown(MessagingService.java:721)
> ~[trunk/na]
> at
> org.apache.cassandra.service.StorageService$1.runMayThrow(StorageService.java:553)
> ~[trunk/na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[trunk/na]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_20]
> Caused by: java.io.IOException: Unknown error: 316
> at sun.nio.ch.NativeThread.signal(Native Method) ~[na:1.8.0_20]
> at
> sun.nio.ch.ServerSocketChannelImpl.implCloseSelectableChannel(ServerSocketChannelImpl.java:283)
> ~[na:1.8.0_20]
> at
> java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:234)
> ~[na:1.8.0_20]
> at
> java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:115)
> ~[na:1.8.0_20]
> at sun.nio.ch.ServerSocketAdaptor.close(ServerSocketAdaptor.java:137)
> ~[na:1.8.0_20]
> at
> org.apache.cassandra.net.MessagingService$SocketThread.close(MessagingService.java:958)
> ~[trunk/na]
> at
> org.apache.cassandra.net.MessagingService.shutdown(MessagingService.java:717)
> ~[trunk/na]
> ... 3 common frames omitted
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8223) Make comments/default paths in cassandra-env.ps1 more Windows-centric
[
https://issues.apache.org/jira/browse/CASSANDRA-8223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8223:
--
Fix Version/s: (was: 2.1.2)
2.1.3
> Make comments/default paths in cassandra-env.ps1 more Windows-centric
> -
>
> Key: CASSANDRA-8223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8223
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Joshua McKenzie
>Assignee: Joshua McKenzie
>Priority: Trivial
> Labels: Windows
> Fix For: 2.1.3
>
>
> When porting launch-script functionality over some of the disabled-by-default
> options in cassandra-env.ps1 weren't modified. They're decidedly non-Windows:
> {code}
># Configure the following for JEMallocAllocator and if jemalloc is not
> available in the system
> # library path (Example: /usr/local/lib/). Usually "make install" will do
> the right thing.
> {code}
> Trivial effort - just update those to reflect sane windows
> defaults/paths/ecosystem. Should have 0 effect on runtime defaults as
> they're all already Windows-ified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7662: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Priority: Minor > Fix For: 2.1.3 > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7731) Get max values for live/tombstone cells per slice
[ https://issues.apache.org/jira/browse/CASSANDRA-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7731: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Get max values for live/tombstone cells per slice > - > > Key: CASSANDRA-7731 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7731 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Cyril Scetbon >Assignee: Robert Stupp >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7731-2.0.txt, 7731-2.1.txt > > > I think you should not say that slice statistics are valid for the [last five > minutes > |https://github.com/apache/cassandra/blob/cassandra-2.0/src/java/org/apache/cassandra/tools/NodeCmd.java#L955-L956] > in CFSTATS command of nodetool. I've read the documentation from yammer for > Histograms and there is no way to force values to expire after x minutes > except by > [clearing|http://grepcode.com/file/repo1.maven.org/maven2/com.yammer.metrics/metrics-core/2.1.2/com/yammer/metrics/core/Histogram.java#96] > it . The only thing I can see is that the last snapshot used to provide the > median (or whatever you'd used instead) value is based on 1028 values. > I think we should also be able to detect that some requests are accessing a > lot of live/tombstone cells per query and that's not possible for now without > activating DEBUG for SliceQueryFilter for example and by tweaking the > threshold. Currently as nodetool cfstats returns the median if a low part of > the queries are scanning a lot of live/tombstone cells we miss it ! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7882) Memtable slab allocation should scale logarithmically to improve occupancy rate
[ https://issues.apache.org/jira/browse/CASSANDRA-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7882: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Memtable slab allocation should scale logarithmically to improve occupancy > rate > --- > > Key: CASSANDRA-7882 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7882 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jay Patel >Assignee: Jay Patel > Labels: performance > Fix For: 2.1.3 > > Attachments: trunk-7882.txt > > > CASSANDRA-5935 allows option to disable region-based allocation for on-heap > memtables but there is no option to disable it for off-heap memtables > (memtable_allocation_type: offheap_objects). > Disabling region-based allocation will allow us to pack more tables in the > schema since minimum of 1MB region won't be allocated per table. Downside can > be more fragmentation which should be controllable by using better allocator > like JEMalloc. > How about below option in yaml?: > memtable_allocation_type: unslabbed_offheap_objects > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7106) Retry multiple times before giving up on fetching splits
[ https://issues.apache.org/jira/browse/CASSANDRA-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7106: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Retry multiple times before giving up on fetching splits > > > Key: CASSANDRA-7106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7106 > Project: Cassandra > Issue Type: Improvement > Components: Hadoop >Reporter: Victor Igumnov >Priority: Minor > Fix For: 2.1.3 > > Attachments: retries-fix-iterator-bug.patch, retries-reworked.patch, > retry-splits.patch > > > See Github for patch: > https://github.com/victori/cassandra > What the patch does: > While I was evaluating Shark/Hive for analyzing Cassandra's data, I could not > get any of the queries to return reliably. Looking further into the issue I > noticed that if just a single fetch for a split fails the whole job is > aborted. So instead of giving up and failing out the whole job, retry > fetching the data a few times before completely giving up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8006) Add User defined type support to CQLSSTableWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8006: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Add User defined type support to CQLSSTableWriter > - > > Key: CASSANDRA-8006 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8006 > Project: Cassandra > Issue Type: Improvement >Reporter: Yuki Morishita >Priority: Minor > Fix For: 2.1.3 > > > Currently, CQLSSTableWriter does not support User-defined types. > We should add one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8112) nodetool compactionhistory can allocate memory unbounded
[ https://issues.apache.org/jira/browse/CASSANDRA-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8112: -- Fix Version/s: (was: 2.1.2) 2.1.3 > nodetool compactionhistory can allocate memory unbounded > > > Key: CASSANDRA-8112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8112 > Project: Cassandra > Issue Type: Bug >Reporter: T Jake Luciani >Priority: Minor > Labels: triaged > Fix For: 2.1.3 > > > nodetool compactionhistory keeps data for 1 week by default and creates a > table from the result set in memory. > For many systems a week can generate 10's of thousands of compactions in this > time (esp with LCS) we should guard against this command allocating too much > memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
