[jira] [Assigned] (CASSANDRA-6952) Cannot bind variables to USE statements
[
https://issues.apache.org/jira/browse/CASSANDRA-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-6952:
-
Assignee: Benjamin Lerer
> Cannot bind variables to USE statements
> ---
>
> Key: CASSANDRA-6952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6952
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Matt Stump
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql3
>
> Attempting to bind a variable for a USE query results in a syntax error.
> Example Invocation:
> {code}
> ResultSet result = session.execute("USE ?", "system");
> {code}
> Error:
> {code}
> ERROR SYNTAX_ERROR: line 1:4 no viable alternative at input '?', v=2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8306) exception in nodetool enablebinary
[
https://issues.apache.org/jira/browse/CASSANDRA-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214432#comment-14214432
]
Brandon Williams commented on CASSANDRA-8306:
-
Why not make step 4 before step 1?
> exception in nodetool enablebinary
> --
>
> Key: CASSANDRA-8306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8306
> Project: Cassandra
> Issue Type: Bug
>Reporter: Rafał Furmański
> Attachments: system.log.zip
>
>
> I was trying to add new node (db4) to existing cluster - with no luck. I
> can't see any errors in system.log. nodetool status shows, that node is
> joining into cluster (for many hours). Attaching error and cluster info:
> {code}
> root@db4:~# nodetool enablebinary
> error: Error starting native transport: null
> -- StackTrace --
> java.lang.RuntimeException: Error starting native transport: null
> at
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:350)
> 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.GeneratedMethodAccessor2.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
> 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
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code}
> root@db4:~# nodetool describecluster
> Cluster Information:
> Name: Production Cluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> b7e98bb9-717f-3f59-bac4-84bc19544e90: [10.195.15.163,
> 10.195.15.162, 10.195.15.167, 10.195.15.166]
> {code}
> {code}
> root@db4:~# nodetool status
> Datacenter: Ashburn
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens OwnsHost ID
> Rack
> UN 10.195.15.163 12.05 GB 256 ?
> 0a9f478c-80b5-4c15-8b2e-e27df6684c69 RAC1
> UN 10.195.15.162 12.8 GB256 ?
> c18d2218-ef84-4165
[jira] [Commented] (CASSANDRA-8306) exception in nodetool enablebinary
[
https://issues.apache.org/jira/browse/CASSANDRA-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214436#comment-14214436
]
Rafał Furmański commented on CASSANDRA-8306:
Because step 1 is creating all necessary folders like /etc/cassandra?
> exception in nodetool enablebinary
> --
>
> Key: CASSANDRA-8306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8306
> Project: Cassandra
> Issue Type: Bug
>Reporter: Rafał Furmański
> Attachments: system.log.zip
>
>
> I was trying to add new node (db4) to existing cluster - with no luck. I
> can't see any errors in system.log. nodetool status shows, that node is
> joining into cluster (for many hours). Attaching error and cluster info:
> {code}
> root@db4:~# nodetool enablebinary
> error: Error starting native transport: null
> -- StackTrace --
> java.lang.RuntimeException: Error starting native transport: null
> at
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:350)
> 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.GeneratedMethodAccessor2.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
> 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
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code}
> root@db4:~# nodetool describecluster
> Cluster Information:
> Name: Production Cluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> b7e98bb9-717f-3f59-bac4-84bc19544e90: [10.195.15.163,
> 10.195.15.162, 10.195.15.167, 10.195.15.166]
> {code}
> {code}
> root@db4:~# nodetool status
> Datacenter: Ashburn
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens OwnsHost ID
> Rack
> UN 10.195.15.163 12.05 GB 256 ?
> 0a9f478c-80b5-4c15-8b2e-e27df6684c69 RAC1
> UN 10.195.15.162 12.8 GB256
[jira] [Commented] (CASSANDRA-8306) exception in nodetool enablebinary
[
https://issues.apache.org/jira/browse/CASSANDRA-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214449#comment-14214449
]
Brandon Williams commented on CASSANDRA-8306:
-
That's too difficult?
> exception in nodetool enablebinary
> --
>
> Key: CASSANDRA-8306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8306
> Project: Cassandra
> Issue Type: Bug
>Reporter: Rafał Furmański
> Attachments: system.log.zip
>
>
> I was trying to add new node (db4) to existing cluster - with no luck. I
> can't see any errors in system.log. nodetool status shows, that node is
> joining into cluster (for many hours). Attaching error and cluster info:
> {code}
> root@db4:~# nodetool enablebinary
> error: Error starting native transport: null
> -- StackTrace --
> java.lang.RuntimeException: Error starting native transport: null
> at
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:350)
> 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.GeneratedMethodAccessor2.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
> 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
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code}
> root@db4:~# nodetool describecluster
> Cluster Information:
> Name: Production Cluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> b7e98bb9-717f-3f59-bac4-84bc19544e90: [10.195.15.163,
> 10.195.15.162, 10.195.15.167, 10.195.15.166]
> {code}
> {code}
> root@db4:~# nodetool status
> Datacenter: Ashburn
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens OwnsHost ID
> Rack
> UN 10.195.15.163 12.05 GB 256 ?
> 0a9f478c-80b5-4c15-8b2e-e27df6684c69 RAC1
> UN 10.195.15.162 12.8 GB256 ?
> c18d2218-ef84-4165-9c3a-05f592f
[jira] [Commented] (CASSANDRA-8306) exception in nodetool enablebinary
[
https://issues.apache.org/jira/browse/CASSANDRA-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214451#comment-14214451
]
Rafał Furmański commented on CASSANDRA-8306:
Of course not. I was just following documentation.
> exception in nodetool enablebinary
> --
>
> Key: CASSANDRA-8306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8306
> Project: Cassandra
> Issue Type: Bug
>Reporter: Rafał Furmański
> Attachments: system.log.zip
>
>
> I was trying to add new node (db4) to existing cluster - with no luck. I
> can't see any errors in system.log. nodetool status shows, that node is
> joining into cluster (for many hours). Attaching error and cluster info:
> {code}
> root@db4:~# nodetool enablebinary
> error: Error starting native transport: null
> -- StackTrace --
> java.lang.RuntimeException: Error starting native transport: null
> at
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:350)
> 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.GeneratedMethodAccessor2.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
> 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
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code}
> root@db4:~# nodetool describecluster
> Cluster Information:
> Name: Production Cluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> b7e98bb9-717f-3f59-bac4-84bc19544e90: [10.195.15.163,
> 10.195.15.162, 10.195.15.167, 10.195.15.166]
> {code}
> {code}
> root@db4:~# nodetool status
> Datacenter: Ashburn
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens OwnsHost ID
> Rack
> UN 10.195.15.163 12.05 GB 256 ?
> 0a9f478c-80b5-4c15-8b2e-e27df6684c69 RAC1
> UN 10.195.15.162 12.8 GB256 ?
> c18d
[jira] [Commented] (CASSANDRA-7981) Refactor SelectStatement
[
https://issues.apache.org/jira/browse/CASSANDRA-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214469#comment-14214469
]
Benjamin Lerer commented on CASSANDRA-7981:
---
I updated the
[branch|https://github.com/blerer/cassandra/compare/CASSANDRA-7981].
The patch address most of the review comments.
{quote}The restriction class hierarchy is confusing, but I don't see an obvious
way to simplify it{quote}
Did not found a way to simplify it but I am also not fully sure about what it
is making it confusing. I probably have worked already too much with it. May be
[~slebresne] will have an idea of how we can improve the things.
{quote}There seems to be a conflict between the {mergeWith(Restriction)}
signatures in {{Restriction}} and {{Restrictions}}.{quote}
It is due to the fact that {{PrimaryKeyRestrictions}} is a composite of
{{Restriction}}.
The problem with such a big refactoring is that in the end you lost a part of
your ability to see if the changes that you have made improve really the
readability of the code compare to the original version.
> Refactor SelectStatement
>
>
> Key: CASSANDRA-7981
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7981
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.0
>
>
> The current state of the code of SelectStatement make fixing some issues or
> adding new functionnalities really hard. It also contains some
> functionnalities that we would like to reuse in ModificationStatement but
> cannot for the moment.
> Ideally I would like to:
> * Perform as much validation as possible on Relations instead of performing
> it on Restrictions as it will help for problem like the one of
> #CASSANDRA-6075 (I believe that by clearly separating validation and
> Restrictions building we will also make the code a lot clearer)
> * Provide a way to easily merge restrictions on the same columns as needed
> for #CASSANDRA-7016
> * Have a preparation logic (validation + pre-processing) that we can easily
> reuse for Delete statement #CASSANDRA-6237
> * Make the code much easier to read and safer to modify.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7981) Refactor SelectStatement
[ https://issues.apache.org/jira/browse/CASSANDRA-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214473#comment-14214473 ] Benjamin Lerer commented on CASSANDRA-7981: --- Fogot to mention one important thing: The refactoring break the IN ordering. The results are now returned ordered in the normal order not in the order specified in the IN condition. > Refactor SelectStatement > > > Key: CASSANDRA-7981 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7981 > Project: Cassandra > Issue Type: Bug >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer > Fix For: 3.0 > > > The current state of the code of SelectStatement make fixing some issues or > adding new functionnalities really hard. It also contains some > functionnalities that we would like to reuse in ModificationStatement but > cannot for the moment. > Ideally I would like to: > * Perform as much validation as possible on Relations instead of performing > it on Restrictions as it will help for problem like the one of > #CASSANDRA-6075 (I believe that by clearly separating validation and > Restrictions building we will also make the code a lot clearer) > * Provide a way to easily merge restrictions on the same columns as needed > for #CASSANDRA-7016 > * Have a preparation logic (validation + pre-processing) that we can easily > reuse for Delete statement #CASSANDRA-6237 > * Make the code much easier to read and safer to modify. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6952) Cannot bind variables to USE statements
[
https://issues.apache.org/jira/browse/CASSANDRA-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214483#comment-14214483
]
Aleksey Yeschenko commented on CASSANDRA-6952:
--
FWIW I still think it's a bad idea, consistency-wise, to implement this, and we
shouldn't do so.
> Cannot bind variables to USE statements
> ---
>
> Key: CASSANDRA-6952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6952
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Matt Stump
>Assignee: Benjamin Lerer
>Priority: Minor
> Labels: cql3
>
> Attempting to bind a variable for a USE query results in a syntax error.
> Example Invocation:
> {code}
> ResultSet result = session.execute("USE ?", "system");
> {code}
> Error:
> {code}
> ERROR SYNTAX_ERROR: line 1:4 no viable alternative at input '?', v=2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
Leonid Shalupov created CASSANDRA-8325:
--
Summary: Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
Key: CASSANDRA-8325
URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
Project: Cassandra
Issue Type: Bug
Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
Server VM
Reporter: Leonid Shalupov
Attachments: hs_err_pid1856.log
See attached error file after JVM crash
{quote}
FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan
16 22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC
amd64
{quote}
{quote}
% java -version
openjdk version "1.7.0_71"
OpenJDK Runtime Environment (build 1.7.0_71-b14)
OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214527#comment-14214527
]
Leonid Shalupov commented on CASSANDRA-8325:
Related thread in FreeBSD mailing list:
http://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080834.html
{quote}
Looks like it might be cassandra bug, as it's calling
sun.misc.Unsafe.getByte() which can crash the JVM with bad addresses.
{quote}
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
>Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonid Shalupov updated CASSANDRA-8325:
---
Attachment: system.log
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
>Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log, system.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214543#comment-14214543
]
Leonid Shalupov edited comment on CASSANDRA-8325 at 11/17/14 11:09 AM:
---
STR:
1. Get FreeBSD 10.0, install openjdk via pkg install openjdk 7
2. Download and unpack apache-cassandra-2.1.2-bin.tar.gz
3. Run ./cassandra in apache-cassandra-2.1.2/bin
4. In couple of seconds Cassandra will crash
was (Author: shalupov):
STR:
1. Get FreeBSD 10.1, install openjdk via pkg install openjdk 7
2. Download and unpack apache-cassandra-2.1.2-bin.tar.gz
3. Run ./cassandra in apache-cassandra-2.1.2/bin
4. In couple of seconds Cassandra will crash
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
>Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log, system.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214543#comment-14214543
]
Leonid Shalupov commented on CASSANDRA-8325:
STR:
1. Get FreeBSD 10.1, install openjdk via pkg install openjdk 7
2. Download and unpack apache-cassandra-2.1.2-bin.tar.gz
3. Run ./cassandra in apache-cassandra-2.1.2/bin
4. In couple of seconds Cassandra will crash
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
>Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log, system.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7563) UserType, TupleType and collections in UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7563:
Attachment: 7563v4.txt
> UserType, TupleType and collections in UDFs
> ---
>
> Key: CASSANDRA-7563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7563
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.0
>
> Attachments: 7563-7740.txt, 7563.txt, 7563v2.txt, 7563v3.txt,
> 7563v4.txt
>
>
> * is Java Driver as a dependency required ?
> * is it possible to extract parts of the Java Driver for UDT/TT/coll support ?
> * CQL {{DROP TYPE}} must check UDFs
> * must check keyspace access permissions (if those exist)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7563) UserType, TupleType and collections in UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214609#comment-14214609
]
Robert Stupp commented on CASSANDRA-7563:
-
Attached v4 of the patch.
The protocol version stuff got a bit bigger than I expected. But the new tests
in UFTest pass. These test execution using {{executeInternal}} and using
protocol version 2 + 3 via the Java Driver.
Calling a UDF with a null value in a collection does not work - the Java Driver
does not support that. Added a test for that (but with {{@Ignore}} annotation.
I tried to make the new tests a bit more readable - hope it looks better now.
Also added support in CQLTester to create UDFs (createFunction,
createFunctionOverload).
> UserType, TupleType and collections in UDFs
> ---
>
> Key: CASSANDRA-7563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7563
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.0
>
> Attachments: 7563-7740.txt, 7563.txt, 7563v2.txt, 7563v3.txt,
> 7563v4.txt
>
>
> * is Java Driver as a dependency required ?
> * is it possible to extract parts of the Java Driver for UDT/TT/coll support ?
> * CQL {{DROP TYPE}} must check UDFs
> * must check keyspace access permissions (if those exist)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8317) ExtendedFilter countCQL3Rows should be exposed to isCQLCount()
[
https://issues.apache.org/jira/browse/CASSANDRA-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-8317.
-
Resolution: Invalid
You're misunderstanding what {{countCQL3Rows}} is. It does not indicate that
it's a count operation. It's only a flag to inform the storage engine if it
should group cells when counting them for the sake of the query limit.
> ExtendedFilter countCQL3Rows should be exposed to isCQLCount()
> --
>
> Key: CASSANDRA-8317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8317
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jacques-Henri Berthemet
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> ExtendedFilter countCQL3Rows should be exposed to isCQLCount(). The goal is
> that a SecondaryIndexSearcher implementation knowns that it just needs to
> count rows, not load them.
> something like:
> public boolean isCQLCount() {
> return countCQL3Rows;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8317) ExtendedFilter countCQL3Rows should be exposed to isCQLCount()
[
https://issues.apache.org/jira/browse/CASSANDRA-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214630#comment-14214630
]
Jacques-Henri Berthemet commented on CASSANDRA-8317:
I see thanks for the info.
> ExtendedFilter countCQL3Rows should be exposed to isCQLCount()
> --
>
> Key: CASSANDRA-8317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8317
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jacques-Henri Berthemet
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> ExtendedFilter countCQL3Rows should be exposed to isCQLCount(). The goal is
> that a SecondaryIndexSearcher implementation knowns that it just needs to
> count rows, not load them.
> something like:
> public boolean isCQLCount() {
> return countCQL3Rows;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8280) Cassandra crashing on inserting data over 64K into indexed strings
[
https://issues.apache.org/jira/browse/CASSANDRA-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214634#comment-14214634
]
Sam Tunnicliffe commented on CASSANDRA-8280:
There is already validation for this on the thrift path (from CASSANDRA-3057),
but it appears to have been overlooked for CQL.
Attaching separate patches for 2.0 & 2.1, mainly because CQLTester in 2.1 makes
the unit test simpler but not easily mergeable.
> Cassandra crashing on inserting data over 64K into indexed strings
> --
>
> Key: CASSANDRA-8280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8280
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 7, Cassandra 2.1.1, java 1.7.0_60
>Reporter: Cristian Marinescu
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 2.1.3
>
>
> An attemtp to instert 65536 bytes in a field that is a primary index throws
> (correctly?) the cassandra.InvalidRequest exception. However, inserting the
> same data *in a indexed field that is not a primary index* works just fine.
> However, Cassandra will crash on next commit and never recover. So I rated it
> as Critical as it can be used for DoS attacks.
> Reproduce: see the snippet below:
> {code}
> import uuid
> from cassandra import ConsistencyLevel
> from cassandra import InvalidRequest
> from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> from cassandra.policies import ConstantReconnectionPolicy
> from cassandra.cqltypes import UUID
>
> # DROP KEYSPACE IF EXISTS cs;
> # CREATE KEYSPACE cs WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # USE cs;
> # CREATE TABLE test3 (name text, value uuid, sentinel text, PRIMARY KEY
> (name));
> # CREATE INDEX test3_sentinels ON test3(sentinel);
>
> class CassandraDemo(object):
>
> def __init__(self):
> ips = ["127.0.0.1"]
> ap = PlainTextAuthProvider(username="cs", password="cs")
> reconnection_policy = ConstantReconnectionPolicy(20.0,
> max_attempts=100)
> cluster = Cluster(ips, auth_provider=ap, protocol_version=3,
> reconnection_policy=reconnection_policy)
> self.session = cluster.connect("cs")
>
> def exec_query(self, query, args):
> prepared_statement = self.session.prepare(query)
> prepared_statement.consistency_level = ConsistencyLevel.LOCAL_QUORUM
> self.session.execute(prepared_statement, args)
>
> def bug(self):
> k1 = UUID( str(uuid.uuid4()) )
> long_string = "X" * 65536
> query = "INSERT INTO test3 (name, value, sentinel) VALUES (?, ?, ?);"
> args = ("foo", k1, long_string)
>
> self.exec_query(query, args)
> self.session.execute("DROP KEYSPACE IF EXISTS cs_test", timeout=30)
> self.session.execute("CREATE KEYSPACE cs_test WITH replication =
> {'class': 'SimpleStrategy', 'replication_factor': 1}")
>
> c = CassandraDemo()
> #first run
> c.bug()
> #second run, Cassandra crashes with java.lang.AssertionError
> c.bug()
> {code}
> And here is the cassandra log:
> {code}
> ERROR [MemtableFlushWriter:3] 2014-11-06 16:44:49,263
> CassandraDaemon.java:153 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> java.lang.AssertionError: 65536
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.maybeWriteRowHeader(ColumnIndex.java:214)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:201)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:142)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:233)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:218)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:354)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:312)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorS
[jira] [Updated] (CASSANDRA-8280) Cassandra crashing on inserting data over 64K into indexed strings
[
https://issues.apache.org/jira/browse/CASSANDRA-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8280:
---
Attachment: 8280-2.1.txt
8280-2.0.txt
> Cassandra crashing on inserting data over 64K into indexed strings
> --
>
> Key: CASSANDRA-8280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8280
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 7, Cassandra 2.1.1, java 1.7.0_60
>Reporter: Cristian Marinescu
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: 8280-2.0.txt, 8280-2.1.txt
>
>
> An attemtp to instert 65536 bytes in a field that is a primary index throws
> (correctly?) the cassandra.InvalidRequest exception. However, inserting the
> same data *in a indexed field that is not a primary index* works just fine.
> However, Cassandra will crash on next commit and never recover. So I rated it
> as Critical as it can be used for DoS attacks.
> Reproduce: see the snippet below:
> {code}
> import uuid
> from cassandra import ConsistencyLevel
> from cassandra import InvalidRequest
> from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> from cassandra.policies import ConstantReconnectionPolicy
> from cassandra.cqltypes import UUID
>
> # DROP KEYSPACE IF EXISTS cs;
> # CREATE KEYSPACE cs WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # USE cs;
> # CREATE TABLE test3 (name text, value uuid, sentinel text, PRIMARY KEY
> (name));
> # CREATE INDEX test3_sentinels ON test3(sentinel);
>
> class CassandraDemo(object):
>
> def __init__(self):
> ips = ["127.0.0.1"]
> ap = PlainTextAuthProvider(username="cs", password="cs")
> reconnection_policy = ConstantReconnectionPolicy(20.0,
> max_attempts=100)
> cluster = Cluster(ips, auth_provider=ap, protocol_version=3,
> reconnection_policy=reconnection_policy)
> self.session = cluster.connect("cs")
>
> def exec_query(self, query, args):
> prepared_statement = self.session.prepare(query)
> prepared_statement.consistency_level = ConsistencyLevel.LOCAL_QUORUM
> self.session.execute(prepared_statement, args)
>
> def bug(self):
> k1 = UUID( str(uuid.uuid4()) )
> long_string = "X" * 65536
> query = "INSERT INTO test3 (name, value, sentinel) VALUES (?, ?, ?);"
> args = ("foo", k1, long_string)
>
> self.exec_query(query, args)
> self.session.execute("DROP KEYSPACE IF EXISTS cs_test", timeout=30)
> self.session.execute("CREATE KEYSPACE cs_test WITH replication =
> {'class': 'SimpleStrategy', 'replication_factor': 1}")
>
> c = CassandraDemo()
> #first run
> c.bug()
> #second run, Cassandra crashes with java.lang.AssertionError
> c.bug()
> {code}
> And here is the cassandra log:
> {code}
> ERROR [MemtableFlushWriter:3] 2014-11-06 16:44:49,263
> CassandraDaemon.java:153 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> java.lang.AssertionError: 65536
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.maybeWriteRowHeader(ColumnIndex.java:214)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:201)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:142)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:233)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:218)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:354)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:312)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1053)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
>
[jira] [Commented] (CASSANDRA-8245) Cassandra nodes periodically die in 2-DC configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214638#comment-14214638 ] Oleg Poleshuk commented on CASSANDRA-8245: -- There are 6 nodes total: 3 per DC. Time difference is 2 seconds between 2 DCs. Within one DC it's <1 second. Anyway, upgraded to 2.1 and the error is gone. I would recommend to add an additional debug info to FailureDetector, hostname should be very useful that just "Ignoring interval time " > Cassandra nodes periodically die in 2-DC configuration > -- > > Key: CASSANDRA-8245 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8245 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Scientific Linux release 6.5 > java version "1.7.0_51" > Cassandra 2.0.9 >Reporter: Oleg Poleshuk >Assignee: Brandon Williams >Priority: Minor > Attachments: stack1.txt, stack2.txt, stack3.txt, stack4.txt, > stack5.txt > > > We have 2 DCs with 3 nodes in each. > Second DC periodically has 1-2 nodes down. > Looks like it looses connectivity with another nodes and then Gossiper starts > to accumulate tasks until Cassandra dies with OOM. > WARN [MemoryMeter:1] 2014-08-12 14:34:59,803 Memtable.java (line 470) setting > live ratio to maximum of 64.0 instead of Infinity > WARN [GossipTasks:1] 2014-08-12 14:44:34,866 Gossiper.java (line 637) Gossip > stage has 1 pending tasks; skipping status check (no nodes will be marked > down) > WARN [GossipTasks:1] 2014-08-12 14:44:35,968 Gossiper.java (line 637) Gossip > stage has 4 pending tasks; skipping status check (no nodes will be marked > down) > WARN [GossipTasks:1] 2014-08-12 14:44:37,070 Gossiper.java (line 637) Gossip > stage has 8 pending tasks; skipping status check (no nodes will be marked > down) > WARN [GossipTasks:1] 2014-08-12 14:44:38,171 Gossiper.java (line 637) Gossip > stage has 11 pending tasks; skipping status check (no nodes will be marked > down) > ... > WARN [GossipTasks:1] 2014-10-06 21:42:51,575 Gossiper.java (line 637) Gossip > stage has 1014764 pending tasks; skipping status check (no nodes will be > marked down) > WARN [New I/O worker #13] 2014-10-06 21:54:27,010 Slf4JLogger.java (line 76) > Unexpected exception in the selector loop. > java.lang.OutOfMemoryError: Java heap space > Also those lines but not sure it is relevant: > DEBUG [GossipStage:1] 2014-08-12 11:33:18,801 FailureDetector.java (line 338) > Ignoring interval time of 2085963047 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8280) Cassandra crashing on inserting data over 64K into indexed strings
[
https://issues.apache.org/jira/browse/CASSANDRA-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8280:
---
Attachment: (was: 8280-2.0.txt)
> Cassandra crashing on inserting data over 64K into indexed strings
> --
>
> Key: CASSANDRA-8280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8280
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 7, Cassandra 2.1.1, java 1.7.0_60
>Reporter: Cristian Marinescu
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: 8280-2.1.txt
>
>
> An attemtp to instert 65536 bytes in a field that is a primary index throws
> (correctly?) the cassandra.InvalidRequest exception. However, inserting the
> same data *in a indexed field that is not a primary index* works just fine.
> However, Cassandra will crash on next commit and never recover. So I rated it
> as Critical as it can be used for DoS attacks.
> Reproduce: see the snippet below:
> {code}
> import uuid
> from cassandra import ConsistencyLevel
> from cassandra import InvalidRequest
> from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> from cassandra.policies import ConstantReconnectionPolicy
> from cassandra.cqltypes import UUID
>
> # DROP KEYSPACE IF EXISTS cs;
> # CREATE KEYSPACE cs WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # USE cs;
> # CREATE TABLE test3 (name text, value uuid, sentinel text, PRIMARY KEY
> (name));
> # CREATE INDEX test3_sentinels ON test3(sentinel);
>
> class CassandraDemo(object):
>
> def __init__(self):
> ips = ["127.0.0.1"]
> ap = PlainTextAuthProvider(username="cs", password="cs")
> reconnection_policy = ConstantReconnectionPolicy(20.0,
> max_attempts=100)
> cluster = Cluster(ips, auth_provider=ap, protocol_version=3,
> reconnection_policy=reconnection_policy)
> self.session = cluster.connect("cs")
>
> def exec_query(self, query, args):
> prepared_statement = self.session.prepare(query)
> prepared_statement.consistency_level = ConsistencyLevel.LOCAL_QUORUM
> self.session.execute(prepared_statement, args)
>
> def bug(self):
> k1 = UUID( str(uuid.uuid4()) )
> long_string = "X" * 65536
> query = "INSERT INTO test3 (name, value, sentinel) VALUES (?, ?, ?);"
> args = ("foo", k1, long_string)
>
> self.exec_query(query, args)
> self.session.execute("DROP KEYSPACE IF EXISTS cs_test", timeout=30)
> self.session.execute("CREATE KEYSPACE cs_test WITH replication =
> {'class': 'SimpleStrategy', 'replication_factor': 1}")
>
> c = CassandraDemo()
> #first run
> c.bug()
> #second run, Cassandra crashes with java.lang.AssertionError
> c.bug()
> {code}
> And here is the cassandra log:
> {code}
> ERROR [MemtableFlushWriter:3] 2014-11-06 16:44:49,263
> CassandraDaemon.java:153 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> java.lang.AssertionError: 65536
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.maybeWriteRowHeader(ColumnIndex.java:214)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:201)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:142)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:233)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:218)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:354)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:312)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1053)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.Th
[jira] [Updated] (CASSANDRA-8280) Cassandra crashing on inserting data over 64K into indexed strings
[
https://issues.apache.org/jira/browse/CASSANDRA-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8280:
---
Attachment: 8280-2.1.txt
8280-2.0.txt
> Cassandra crashing on inserting data over 64K into indexed strings
> --
>
> Key: CASSANDRA-8280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8280
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 7, Cassandra 2.1.1, java 1.7.0_60
>Reporter: Cristian Marinescu
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: 8280-2.0.txt, 8280-2.1.txt
>
>
> An attemtp to instert 65536 bytes in a field that is a primary index throws
> (correctly?) the cassandra.InvalidRequest exception. However, inserting the
> same data *in a indexed field that is not a primary index* works just fine.
> However, Cassandra will crash on next commit and never recover. So I rated it
> as Critical as it can be used for DoS attacks.
> Reproduce: see the snippet below:
> {code}
> import uuid
> from cassandra import ConsistencyLevel
> from cassandra import InvalidRequest
> from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> from cassandra.policies import ConstantReconnectionPolicy
> from cassandra.cqltypes import UUID
>
> # DROP KEYSPACE IF EXISTS cs;
> # CREATE KEYSPACE cs WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # USE cs;
> # CREATE TABLE test3 (name text, value uuid, sentinel text, PRIMARY KEY
> (name));
> # CREATE INDEX test3_sentinels ON test3(sentinel);
>
> class CassandraDemo(object):
>
> def __init__(self):
> ips = ["127.0.0.1"]
> ap = PlainTextAuthProvider(username="cs", password="cs")
> reconnection_policy = ConstantReconnectionPolicy(20.0,
> max_attempts=100)
> cluster = Cluster(ips, auth_provider=ap, protocol_version=3,
> reconnection_policy=reconnection_policy)
> self.session = cluster.connect("cs")
>
> def exec_query(self, query, args):
> prepared_statement = self.session.prepare(query)
> prepared_statement.consistency_level = ConsistencyLevel.LOCAL_QUORUM
> self.session.execute(prepared_statement, args)
>
> def bug(self):
> k1 = UUID( str(uuid.uuid4()) )
> long_string = "X" * 65536
> query = "INSERT INTO test3 (name, value, sentinel) VALUES (?, ?, ?);"
> args = ("foo", k1, long_string)
>
> self.exec_query(query, args)
> self.session.execute("DROP KEYSPACE IF EXISTS cs_test", timeout=30)
> self.session.execute("CREATE KEYSPACE cs_test WITH replication =
> {'class': 'SimpleStrategy', 'replication_factor': 1}")
>
> c = CassandraDemo()
> #first run
> c.bug()
> #second run, Cassandra crashes with java.lang.AssertionError
> c.bug()
> {code}
> And here is the cassandra log:
> {code}
> ERROR [MemtableFlushWriter:3] 2014-11-06 16:44:49,263
> CassandraDaemon.java:153 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> java.lang.AssertionError: 65536
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.maybeWriteRowHeader(ColumnIndex.java:214)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:201)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:142)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:233)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:218)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:354)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:312)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1053)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
>
[jira] [Updated] (CASSANDRA-8280) Cassandra crashing on inserting data over 64K into indexed strings
[
https://issues.apache.org/jira/browse/CASSANDRA-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8280:
---
Attachment: (was: 8280-2.1.txt)
> Cassandra crashing on inserting data over 64K into indexed strings
> --
>
> Key: CASSANDRA-8280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8280
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 7, Cassandra 2.1.1, java 1.7.0_60
>Reporter: Cristian Marinescu
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: 8280-2.0.txt, 8280-2.1.txt
>
>
> An attemtp to instert 65536 bytes in a field that is a primary index throws
> (correctly?) the cassandra.InvalidRequest exception. However, inserting the
> same data *in a indexed field that is not a primary index* works just fine.
> However, Cassandra will crash on next commit and never recover. So I rated it
> as Critical as it can be used for DoS attacks.
> Reproduce: see the snippet below:
> {code}
> import uuid
> from cassandra import ConsistencyLevel
> from cassandra import InvalidRequest
> from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> from cassandra.policies import ConstantReconnectionPolicy
> from cassandra.cqltypes import UUID
>
> # DROP KEYSPACE IF EXISTS cs;
> # CREATE KEYSPACE cs WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # USE cs;
> # CREATE TABLE test3 (name text, value uuid, sentinel text, PRIMARY KEY
> (name));
> # CREATE INDEX test3_sentinels ON test3(sentinel);
>
> class CassandraDemo(object):
>
> def __init__(self):
> ips = ["127.0.0.1"]
> ap = PlainTextAuthProvider(username="cs", password="cs")
> reconnection_policy = ConstantReconnectionPolicy(20.0,
> max_attempts=100)
> cluster = Cluster(ips, auth_provider=ap, protocol_version=3,
> reconnection_policy=reconnection_policy)
> self.session = cluster.connect("cs")
>
> def exec_query(self, query, args):
> prepared_statement = self.session.prepare(query)
> prepared_statement.consistency_level = ConsistencyLevel.LOCAL_QUORUM
> self.session.execute(prepared_statement, args)
>
> def bug(self):
> k1 = UUID( str(uuid.uuid4()) )
> long_string = "X" * 65536
> query = "INSERT INTO test3 (name, value, sentinel) VALUES (?, ?, ?);"
> args = ("foo", k1, long_string)
>
> self.exec_query(query, args)
> self.session.execute("DROP KEYSPACE IF EXISTS cs_test", timeout=30)
> self.session.execute("CREATE KEYSPACE cs_test WITH replication =
> {'class': 'SimpleStrategy', 'replication_factor': 1}")
>
> c = CassandraDemo()
> #first run
> c.bug()
> #second run, Cassandra crashes with java.lang.AssertionError
> c.bug()
> {code}
> And here is the cassandra log:
> {code}
> ERROR [MemtableFlushWriter:3] 2014-11-06 16:44:49,263
> CassandraDaemon.java:153 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> java.lang.AssertionError: 65536
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.maybeWriteRowHeader(ColumnIndex.java:214)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:201)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:142)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:233)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:218)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:354)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:312)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1053)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util
[jira] [Updated] (CASSANDRA-8280) Cassandra crashing on inserting data over 64K into indexed strings
[
https://issues.apache.org/jira/browse/CASSANDRA-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8280:
---
Attachment: (was: 8280-2.1.txt)
> Cassandra crashing on inserting data over 64K into indexed strings
> --
>
> Key: CASSANDRA-8280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8280
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 7, Cassandra 2.1.1, java 1.7.0_60
>Reporter: Cristian Marinescu
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 2.1.3
>
>
> An attemtp to instert 65536 bytes in a field that is a primary index throws
> (correctly?) the cassandra.InvalidRequest exception. However, inserting the
> same data *in a indexed field that is not a primary index* works just fine.
> However, Cassandra will crash on next commit and never recover. So I rated it
> as Critical as it can be used for DoS attacks.
> Reproduce: see the snippet below:
> {code}
> import uuid
> from cassandra import ConsistencyLevel
> from cassandra import InvalidRequest
> from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> from cassandra.policies import ConstantReconnectionPolicy
> from cassandra.cqltypes import UUID
>
> # DROP KEYSPACE IF EXISTS cs;
> # CREATE KEYSPACE cs WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # USE cs;
> # CREATE TABLE test3 (name text, value uuid, sentinel text, PRIMARY KEY
> (name));
> # CREATE INDEX test3_sentinels ON test3(sentinel);
>
> class CassandraDemo(object):
>
> def __init__(self):
> ips = ["127.0.0.1"]
> ap = PlainTextAuthProvider(username="cs", password="cs")
> reconnection_policy = ConstantReconnectionPolicy(20.0,
> max_attempts=100)
> cluster = Cluster(ips, auth_provider=ap, protocol_version=3,
> reconnection_policy=reconnection_policy)
> self.session = cluster.connect("cs")
>
> def exec_query(self, query, args):
> prepared_statement = self.session.prepare(query)
> prepared_statement.consistency_level = ConsistencyLevel.LOCAL_QUORUM
> self.session.execute(prepared_statement, args)
>
> def bug(self):
> k1 = UUID( str(uuid.uuid4()) )
> long_string = "X" * 65536
> query = "INSERT INTO test3 (name, value, sentinel) VALUES (?, ?, ?);"
> args = ("foo", k1, long_string)
>
> self.exec_query(query, args)
> self.session.execute("DROP KEYSPACE IF EXISTS cs_test", timeout=30)
> self.session.execute("CREATE KEYSPACE cs_test WITH replication =
> {'class': 'SimpleStrategy', 'replication_factor': 1}")
>
> c = CassandraDemo()
> #first run
> c.bug()
> #second run, Cassandra crashes with java.lang.AssertionError
> c.bug()
> {code}
> And here is the cassandra log:
> {code}
> ERROR [MemtableFlushWriter:3] 2014-11-06 16:44:49,263
> CassandraDaemon.java:153 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> java.lang.AssertionError: 65536
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.maybeWriteRowHeader(ColumnIndex.java:214)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:201)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:142)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:233)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:218)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:354)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:312)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1053)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolE
[jira] [Updated] (CASSANDRA-8280) Cassandra crashing on inserting data over 64K into indexed strings
[
https://issues.apache.org/jira/browse/CASSANDRA-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8280:
---
Attachment: (was: 8280-2.0.txt)
> Cassandra crashing on inserting data over 64K into indexed strings
> --
>
> Key: CASSANDRA-8280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8280
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 7, Cassandra 2.1.1, java 1.7.0_60
>Reporter: Cristian Marinescu
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 2.1.3
>
>
> An attemtp to instert 65536 bytes in a field that is a primary index throws
> (correctly?) the cassandra.InvalidRequest exception. However, inserting the
> same data *in a indexed field that is not a primary index* works just fine.
> However, Cassandra will crash on next commit and never recover. So I rated it
> as Critical as it can be used for DoS attacks.
> Reproduce: see the snippet below:
> {code}
> import uuid
> from cassandra import ConsistencyLevel
> from cassandra import InvalidRequest
> from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> from cassandra.policies import ConstantReconnectionPolicy
> from cassandra.cqltypes import UUID
>
> # DROP KEYSPACE IF EXISTS cs;
> # CREATE KEYSPACE cs WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # USE cs;
> # CREATE TABLE test3 (name text, value uuid, sentinel text, PRIMARY KEY
> (name));
> # CREATE INDEX test3_sentinels ON test3(sentinel);
>
> class CassandraDemo(object):
>
> def __init__(self):
> ips = ["127.0.0.1"]
> ap = PlainTextAuthProvider(username="cs", password="cs")
> reconnection_policy = ConstantReconnectionPolicy(20.0,
> max_attempts=100)
> cluster = Cluster(ips, auth_provider=ap, protocol_version=3,
> reconnection_policy=reconnection_policy)
> self.session = cluster.connect("cs")
>
> def exec_query(self, query, args):
> prepared_statement = self.session.prepare(query)
> prepared_statement.consistency_level = ConsistencyLevel.LOCAL_QUORUM
> self.session.execute(prepared_statement, args)
>
> def bug(self):
> k1 = UUID( str(uuid.uuid4()) )
> long_string = "X" * 65536
> query = "INSERT INTO test3 (name, value, sentinel) VALUES (?, ?, ?);"
> args = ("foo", k1, long_string)
>
> self.exec_query(query, args)
> self.session.execute("DROP KEYSPACE IF EXISTS cs_test", timeout=30)
> self.session.execute("CREATE KEYSPACE cs_test WITH replication =
> {'class': 'SimpleStrategy', 'replication_factor': 1}")
>
> c = CassandraDemo()
> #first run
> c.bug()
> #second run, Cassandra crashes with java.lang.AssertionError
> c.bug()
> {code}
> And here is the cassandra log:
> {code}
> ERROR [MemtableFlushWriter:3] 2014-11-06 16:44:49,263
> CassandraDaemon.java:153 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> java.lang.AssertionError: 65536
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.maybeWriteRowHeader(ColumnIndex.java:214)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:201)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:142)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:233)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:218)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:354)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:312)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1053)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolE
[jira] [Updated] (CASSANDRA-8280) Cassandra crashing on inserting data over 64K into indexed strings
[
https://issues.apache.org/jira/browse/CASSANDRA-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8280:
---
Attachment: 8280-2.1.txt
8280-2.0.txt
> Cassandra crashing on inserting data over 64K into indexed strings
> --
>
> Key: CASSANDRA-8280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8280
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 7, Cassandra 2.1.1, java 1.7.0_60
>Reporter: Cristian Marinescu
>Assignee: Sam Tunnicliffe
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: 8280-2.0.txt, 8280-2.1.txt
>
>
> An attemtp to instert 65536 bytes in a field that is a primary index throws
> (correctly?) the cassandra.InvalidRequest exception. However, inserting the
> same data *in a indexed field that is not a primary index* works just fine.
> However, Cassandra will crash on next commit and never recover. So I rated it
> as Critical as it can be used for DoS attacks.
> Reproduce: see the snippet below:
> {code}
> import uuid
> from cassandra import ConsistencyLevel
> from cassandra import InvalidRequest
> from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> from cassandra.policies import ConstantReconnectionPolicy
> from cassandra.cqltypes import UUID
>
> # DROP KEYSPACE IF EXISTS cs;
> # CREATE KEYSPACE cs WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # USE cs;
> # CREATE TABLE test3 (name text, value uuid, sentinel text, PRIMARY KEY
> (name));
> # CREATE INDEX test3_sentinels ON test3(sentinel);
>
> class CassandraDemo(object):
>
> def __init__(self):
> ips = ["127.0.0.1"]
> ap = PlainTextAuthProvider(username="cs", password="cs")
> reconnection_policy = ConstantReconnectionPolicy(20.0,
> max_attempts=100)
> cluster = Cluster(ips, auth_provider=ap, protocol_version=3,
> reconnection_policy=reconnection_policy)
> self.session = cluster.connect("cs")
>
> def exec_query(self, query, args):
> prepared_statement = self.session.prepare(query)
> prepared_statement.consistency_level = ConsistencyLevel.LOCAL_QUORUM
> self.session.execute(prepared_statement, args)
>
> def bug(self):
> k1 = UUID( str(uuid.uuid4()) )
> long_string = "X" * 65536
> query = "INSERT INTO test3 (name, value, sentinel) VALUES (?, ?, ?);"
> args = ("foo", k1, long_string)
>
> self.exec_query(query, args)
> self.session.execute("DROP KEYSPACE IF EXISTS cs_test", timeout=30)
> self.session.execute("CREATE KEYSPACE cs_test WITH replication =
> {'class': 'SimpleStrategy', 'replication_factor': 1}")
>
> c = CassandraDemo()
> #first run
> c.bug()
> #second run, Cassandra crashes with java.lang.AssertionError
> c.bug()
> {code}
> And here is the cassandra log:
> {code}
> ERROR [MemtableFlushWriter:3] 2014-11-06 16:44:49,263
> CassandraDaemon.java:153 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> java.lang.AssertionError: 65536
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.maybeWriteRowHeader(ColumnIndex.java:214)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:201)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:142)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:233)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:218)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:354)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:312)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1053)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
>
[jira] [Commented] (CASSANDRA-8326) Cqlsh cannot connect in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214814#comment-14214814
]
Philip Thompson commented on CASSANDRA-8326:
See https://datastax-oss.atlassian.net/browse/PYTHON-185
> Cqlsh cannot connect in trunk
> -
>
> Key: CASSANDRA-8326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8326
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Fix For: 3.0
>
>
> Cqlsh errors with {code}Unable to connect to any servers', {'127.0.0.1':
> KeyError('column_aliases',)}{code}. To fix, we need to pull in a newer
> version of the python driver that doesn't assume certain metadata exists.
> This was broken by the cassandra commit
> {{cbbc1191ce1656a92354a4fa3859626cb10083e5}}. A fix should be in version
> 2.1.3 of the driver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8326) Cqlsh cannot connect in trunk
Philip Thompson created CASSANDRA-8326:
--
Summary: Cqlsh cannot connect in trunk
Key: CASSANDRA-8326
URL: https://issues.apache.org/jira/browse/CASSANDRA-8326
Project: Cassandra
Issue Type: Bug
Reporter: Philip Thompson
Assignee: Tyler Hobbs
Fix For: 3.0
Cqlsh errors with {code}Unable to connect to any servers', {'127.0.0.1':
KeyError('column_aliases',)}{code}. To fix, we need to pull in a newer version
of the python driver that doesn't assume certain metadata exists. This was
broken by the cassandra commit {{cbbc1191ce1656a92354a4fa3859626cb10083e5}}. A
fix should be in version 2.1.3 of the driver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8326) Cqlsh cannot connect in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214821#comment-14214821
]
Robert Stupp commented on CASSANDRA-8326:
-
Issue introduced by CASSANDRA-8261 (currently ongoing schema table refactoring)
> Cqlsh cannot connect in trunk
> -
>
> Key: CASSANDRA-8326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8326
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Fix For: 3.0
>
>
> Cqlsh errors with {code}Unable to connect to any servers', {'127.0.0.1':
> KeyError('column_aliases',)}{code}. To fix, we need to pull in a newer
> version of the python driver that doesn't assume certain metadata exists.
> This was broken by the cassandra commit
> {{cbbc1191ce1656a92354a4fa3859626cb10083e5}}. A fix should be in version
> 2.1.3 of the driver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8228) Log malfunctioning host on prepareForRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214822#comment-14214822 ] Yuki Morishita commented on CASSANDRA-8228: --- There can be multiple nodes failing, so you should use concurrent Set. > Log malfunctioning host on prepareForRepair > --- > > Key: CASSANDRA-8228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8228 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Juho Mäkinen >Assignee: Rajanarayanan Thottuvaikkatumana >Priority: Trivial > Labels: lhf > Attachments: cassandra-trunk-8228.txt > > > Repair startup goes thru ActiveRepairService.prepareForRepair() which might > result with "Repair failed with error Did not get positive replies from all > endpoints." error, but there's no other logging regarding to this error. > It seems that it would be trivial to modify the prepareForRepair() to log the > host address which caused the error, thus ease the debugging effort. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8228) Log malfunctioning host on prepareForRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajanarayanan Thottuvaikkatumana updated CASSANDRA-8228: Attachment: (was: cassandra-trunk-8228.txt) > Log malfunctioning host on prepareForRepair > --- > > Key: CASSANDRA-8228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8228 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Juho Mäkinen >Assignee: Rajanarayanan Thottuvaikkatumana >Priority: Trivial > Labels: lhf > > Repair startup goes thru ActiveRepairService.prepareForRepair() which might > result with "Repair failed with error Did not get positive replies from all > endpoints." error, but there's no other logging regarding to this error. > It seems that it would be trivial to modify the prepareForRepair() to log the > host address which caused the error, thus ease the debugging effort. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8228) Log malfunctioning host on prepareForRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajanarayanan Thottuvaikkatumana updated CASSANDRA-8228: Attachment: cassandra-trunk-8228.txt Latest Patch for CASSANDRA-8228 in the trunk. > Log malfunctioning host on prepareForRepair > --- > > Key: CASSANDRA-8228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8228 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Juho Mäkinen >Assignee: Rajanarayanan Thottuvaikkatumana >Priority: Trivial > Labels: lhf > Attachments: cassandra-trunk-8228.txt > > > Repair startup goes thru ActiveRepairService.prepareForRepair() which might > result with "Repair failed with error Did not get positive replies from all > endpoints." error, but there's no other logging regarding to this error. > It seems that it would be trivial to modify the prepareForRepair() to log the > host address which caused the error, thus ease the debugging effort. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8228) Log malfunctioning host on prepareForRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214907#comment-14214907 ] Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-8228: - [~yukim], The latest patch with the changes as per your suggestions have been uploaded. Please have a look at it. Thanks > Log malfunctioning host on prepareForRepair > --- > > Key: CASSANDRA-8228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8228 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Juho Mäkinen >Assignee: Rajanarayanan Thottuvaikkatumana >Priority: Trivial > Labels: lhf > Attachments: cassandra-trunk-8228.txt > > > Repair startup goes thru ActiveRepairService.prepareForRepair() which might > result with "Repair failed with error Did not get positive replies from all > endpoints." error, but there's no other logging regarding to this error. > It seems that it would be trivial to modify the prepareForRepair() to log the > host address which caused the error, thus ease the debugging effort. -- 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=14214917#comment-14214917
]
Benjamin Lerer commented on CASSANDRA-8286:
---
Just a few nits:
* The patch for 2.0 does not compile as ModificationStatement need to be
modified
* I can understand why you used {{processSelection}} and
{{selectionsNeedProcessing}} but as everything else is about functions I find
it a bit confusing.
* Renaming {{SelectionWithFunctions}} to {{SelectionWithProcessing}} only in
version 2.1 is not really consistent
* It will be good if you can add also some unit tests to test the ordering
behavior with functions
> 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
>
> Attachments: 8286-2.0.txt, 8286-2.1.txt, 8286-trunk.txt
>
>
> 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] [Created] (CASSANDRA-8327) snapshots taken before repair are not cleared if snapshot fails
MASSIMO CELLI created CASSANDRA-8327: Summary: snapshots taken before repair are not cleared if snapshot fails Key: CASSANDRA-8327 URL: https://issues.apache.org/jira/browse/CASSANDRA-8327 Project: Cassandra Issue Type: Bug Components: Core Environment: cassandra 2.0.10.71 Reporter: MASSIMO CELLI Priority: Minor Fix For: 2.0.12 running repair service the following directory was created for the snapshots: drwxr-xr-x 2 cassandra cassandra 36864 Nov 5 07:47 073d16e0-64c0-11e4-8e9a-7b3d4674c508 but the system.log reports the following error which suggests the snapshot failed: ERROR [RMI TCP Connection(3251)-10.150.27.78] 2014-11-05 07:47:55,734 StorageService.java (line 2599) Repair session 073d16e0-64c0-11e4-8e9a-7b3d4674c508 for range (7530018576963469312,7566047373982433280] failed with error java.io.IOException: Failed during snapshot creation. java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.io.IOException: Failed during snapshot creation. ERROR [AntiEntropySessions:3312] 2014-11-05 07:47:55,731 RepairSession.java (line 288) [repair #073d16e0-64c0-11e4-8e9a-7b3d4674c508] session completed with the following error java.io.IOException: Failed during snapshot creation. the problem is that the directory for the snapshots that fail are just left on the disk and don't get cleaned up. They must be removed manually, which is not ideal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8327) snapshots taken before repair are not cleared if snapshot fails
[ https://issues.apache.org/jira/browse/CASSANDRA-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] MASSIMO CELLI updated CASSANDRA-8327: - Fix Version/s: (was: 2.0.12) > snapshots taken before repair are not cleared if snapshot fails > --- > > Key: CASSANDRA-8327 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8327 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: cassandra 2.0.10.71 >Reporter: MASSIMO CELLI >Priority: Minor > > running repair service the following directory was created for the snapshots: > drwxr-xr-x 2 cassandra cassandra 36864 Nov 5 07:47 > 073d16e0-64c0-11e4-8e9a-7b3d4674c508 > but the system.log reports the following error which suggests the snapshot > failed: > ERROR [RMI TCP Connection(3251)-10.150.27.78] 2014-11-05 07:47:55,734 > StorageService.java (line 2599) Repair session > 073d16e0-64c0-11e4-8e9a-7b3d4674c508 for range > (7530018576963469312,7566047373982433280] failed with error > java.io.IOException: Failed during snapshot creation. > java.util.concurrent.ExecutionException: java.lang.RuntimeException: > java.io.IOException: Failed during snapshot creation. ERROR > [AntiEntropySessions:3312] 2014-11-05 07:47:55,731 RepairSession.java (line > 288) [repair #073d16e0-64c0-11e4-8e9a-7b3d4674c508] session completed with > the following error java.io.IOException: Failed during snapshot creation. > the problem is that the directory for the snapshots that fail are just left > on the disk and don't get cleaned up. They must be removed manually, which is > not ideal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8327) snapshots taken before repair are not cleared if snapshot fails
[ https://issues.apache.org/jira/browse/CASSANDRA-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214947#comment-14214947 ] Nick Bailey commented on CASSANDRA-8327: I think that ideally, c* would be using a specific directory for snapshots created by repair. In addition to cleaning up after the snapshot fails for some reason, c* can be restarted while a repair is ongoing and leave these directories behind. By using a specific directory, the c* process can also simply clean up this directory when the process starts. > snapshots taken before repair are not cleared if snapshot fails > --- > > Key: CASSANDRA-8327 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8327 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: cassandra 2.0.10.71 >Reporter: MASSIMO CELLI >Priority: Minor > > running repair service the following directory was created for the snapshots: > drwxr-xr-x 2 cassandra cassandra 36864 Nov 5 07:47 > 073d16e0-64c0-11e4-8e9a-7b3d4674c508 > but the system.log reports the following error which suggests the snapshot > failed: > ERROR [RMI TCP Connection(3251)-10.150.27.78] 2014-11-05 07:47:55,734 > StorageService.java (line 2599) Repair session > 073d16e0-64c0-11e4-8e9a-7b3d4674c508 for range > (7530018576963469312,7566047373982433280] failed with error > java.io.IOException: Failed during snapshot creation. > java.util.concurrent.ExecutionException: java.lang.RuntimeException: > java.io.IOException: Failed during snapshot creation. ERROR > [AntiEntropySessions:3312] 2014-11-05 07:47:55,731 RepairSession.java (line > 288) [repair #073d16e0-64c0-11e4-8e9a-7b3d4674c508] session completed with > the following error java.io.IOException: Failed during snapshot creation. > the problem is that the directory for the snapshots that fail are just left > on the disk and don't get cleaned up. They must be removed manually, which is > not ideal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8248) Possible memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214961#comment-14214961
]
Shawn Kumar commented on CASSANDRA-8248:
Alex, have you determined the issue with resident being larger, and are you
still seeing this problem? If there are any further details you can provide
(are you carrying out incremental repairs? do compactions have any affect?),
they would be much appreciated.
> Possible memory leak
> -
>
> Key: CASSANDRA-8248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8248
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alexander Sterligov
>Assignee: Shawn Kumar
> Attachments: thread_dump
>
>
> Sometimes during repair cassandra starts to consume more memory than expected.
> Total amount of data on node is about 20GB.
> Size of the data directory is 66GC because of snapshots.
> Top reports:
> {noformat}
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 15724 loadbase 20 0 493g 55g 44g S 28 44.2 4043:24 java
> {noformat}
> At the /proc/15724/maps there are a lot of deleted file maps
> {quote}
> 7f63a6102000-7f63a6332000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6332000-7f63a6562000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6562000-7f63a6792000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6792000-7f63a69c2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a69c2000-7f63a6bf2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6bf2000-7f63a6e22000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6e22000-7f63a7052000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7052000-7f63a7282000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7282000-7f63a74b2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a74b2000-7f63a76e2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a76e2000-7f63a7912000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7912000-7f63a7b42000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7b42000-7f63a7d72000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7d72000-7f63a7fa2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7fa2000-7f63a81d2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a81d2000-7f63a8402000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a8402000-7f63a8622000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a8622000-7f63a8842000 r--s 08:21 9442763
[jira] [Created] (CASSANDRA-8328) Expose Thread Pool maximum pool size in metrics
Chris Lohfink created CASSANDRA-8328: Summary: Expose Thread Pool maximum pool size in metrics Key: CASSANDRA-8328 URL: https://issues.apache.org/jira/browse/CASSANDRA-8328 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Chris Lohfink Priority: Trivial The max pool size is exposed in the original (o.a.c.internal/request/transport) metrics from CASSANDRA-5044, but they are not available in the o.a.c.metrics beans. Pretty minor change to also expose this there, which gives context to the maximum number of active tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8328) Expose Thread Pool maximum pool size in metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-8328: - Attachment: 0001-add-max-pool-size-metrics-for-CASSANDRA-8328.patch > Expose Thread Pool maximum pool size in metrics > --- > > Key: CASSANDRA-8328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8328 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Priority: Trivial > Labels: metrics > Attachments: 0001-add-max-pool-size-metrics-for-CASSANDRA-8328.patch > > > The max pool size is exposed in the original > (o.a.c.internal/request/transport) metrics from CASSANDRA-5044, but they are > not available in the o.a.c.metrics beans. Pretty minor change to also expose > this there, which gives context to the maximum number of active tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8326) Cqlsh cannot connect in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215055#comment-14215055
]
Philip Thompson commented on CASSANDRA-8326:
This python driver issue is also breaking 90% of dtests on trunk, which will
also be fixed once a 2.1.3 python driver release is out.
> Cqlsh cannot connect in trunk
> -
>
> Key: CASSANDRA-8326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8326
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Fix For: 3.0
>
>
> Cqlsh errors with {code}Unable to connect to any servers', {'127.0.0.1':
> KeyError('column_aliases',)}{code}. To fix, we need to pull in a newer
> version of the python driver that doesn't assume certain metadata exists.
> This was broken by the cassandra commit
> {{cbbc1191ce1656a92354a4fa3859626cb10083e5}}. A fix should be in version
> 2.1.3 of the driver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7830) Decommissioning fails on a live node
[
https://issues.apache.org/jira/browse/CASSANDRA-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215093#comment-14215093
]
Donald Smith commented on CASSANDRA-7830:
-
Yes, I'm seeing this with 2.0.11:
{noformat}
Exception in thread "main" java.lang.UnsupportedOperationException: data is
currently moving to this node; unable to leave the ring
at
org.apache.cassandra.service.StorageService.decommission(StorageService.java:2912)
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)
...
{noformat}
And *nodetool netstats* shows:
{noformat}
dc1-cassandra13.dc01 ~> nodetool netstats
Mode: NORMAL
Restore replica count d7efb410-6c58-11e4-896c-a1382b792927
Read Repair Statistics:
Attempted: 1123
Mismatch (Blocking): 0
Mismatch (Background): 540
Pool NameActive Pending Completed
Commandsn/a 0 1494743209
Responses n/a 1 1651558975
{noformat}
> Decommissioning fails on a live node
>
>
> Key: CASSANDRA-7830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ananthkumar K S
>
> Exception in thread "main" java.lang.UnsupportedOperationException: data is
> currently moving to this node; unable to leave the ring at
> org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629)
> 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:601) at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at
> com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
> at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601) 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> I got the following exception when i was trying to decommission a live node.
> There is no reference in the manual saying that i need to stop the data
> coming into this node. Even then, decommissioning is specified for live nodes.
> Can anyone let me know if am doing something wrong or if this is a bug on
> cassandra part?
> Cassandra Version Used : 2.0.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CASSANDRA-7830) Decommissioning fails on a live node
[ https://issues.apache.org/jira/browse/CASSANDRA-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson reopened CASSANDRA-7830: > Decommissioning fails on a live node > > > Key: CASSANDRA-7830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7830 > Project: Cassandra > Issue Type: Bug >Reporter: Ananthkumar K S > > Exception in thread "main" java.lang.UnsupportedOperationException: data is > currently moving to this node; unable to leave the ring at > org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629) > 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:601) at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45) > at > com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at > com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at > javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486) > at > javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96) > at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327) > at > javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419) > at > javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847) > at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) 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 > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > I got the following exception when i was trying to decommission a live node. > There is no reference in the manual saying that i need to stop the data > coming into this node. Even then, decommissioning is specified for live nodes. > Can anyone let me know if am doing something wrong or if this is a bug on > cassandra part? > Cassandra Version Used : 2.0.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7830) Decommissioning fails on a live node
[
https://issues.apache.org/jira/browse/CASSANDRA-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-7830:
---
Reproduced In: 2.0.11, 2.0.3 (was: 2.0.3)
Description:
{code}Exception in thread "main" java.lang.UnsupportedOperationException: data
is currently moving to this node; unable to leave the ring at
org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629)
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:601) at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at
com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601) 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
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722){code}
I got the following exception when i was trying to decommission a live node.
There is no reference in the manual saying that i need to stop the data coming
into this node. Even then, decommissioning is specified for live nodes.
Can anyone let me know if am doing something wrong or if this is a bug on
cassandra part?
Cassandra Version Used : 2.0.3
was:
Exception in thread "main" java.lang.UnsupportedOperationException: data is
currently moving to this node; unable to leave the ring at
org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629)
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:601) at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at
com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Me
[jira] [Commented] (CASSANDRA-7830) Decommissioning fails on a live node
[
https://issues.apache.org/jira/browse/CASSANDRA-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215101#comment-14215101
]
Donald Smith commented on CASSANDRA-7830:
-
Stopping and restarting the cassandra process did not help.
> Decommissioning fails on a live node
>
>
> Key: CASSANDRA-7830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ananthkumar K S
>
> {code}Exception in thread "main" java.lang.UnsupportedOperationException:
> data is currently moving to this node; unable to leave the ring at
> org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629)
> 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:601) at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at
> com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
> at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601) 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722){code}
> I got the following exception when i was trying to decommission a live node.
> There is no reference in the manual saying that i need to stop the data
> coming into this node. Even then, decommissioning is specified for live nodes.
> Can anyone let me know if am doing something wrong or if this is a bug on
> cassandra part?
> Cassandra Version Used : 2.0.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8061) tmplink files are not removed
[
https://issues.apache.org/jira/browse/CASSANDRA-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215107#comment-14215107
]
Michael Shuler commented on CASSANDRA-8061:
---
Linking 7803, and I also found 8157 when searching jira for recent "tmplink"
tickets - 8248 looks similar, too.
> tmplink files are not removed
> -
>
> Key: CASSANDRA-8061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8061
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux
>Reporter: Gianluca Borello
>Assignee: Shawn Kumar
> Fix For: 2.1.3
>
>
> After installing 2.1.0, I'm experiencing a bunch of tmplink files that are
> filling my disk. I found https://issues.apache.org/jira/browse/CASSANDRA-7803
> and that is very similar, and I confirm it happens both on 2.1.0 as well as
> from the latest commit on the cassandra-2.1 branch
> (https://github.com/apache/cassandra/commit/aca80da38c3d86a40cc63d9a122f7d45258e4685
> from the cassandra-2.1)
> Even starting with a clean keyspace, after a few hours I get:
> {noformat}
> $ sudo find /raid0 | grep tmplink | xargs du -hs
> 2.7G
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Data.db
> 13M
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Index.db
> 1.8G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Data.db
> 12M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Index.db
> 5.2M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Index.db
> 822M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Data.db
> 7.3M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Index.db
> 1.2G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Data.db
> 6.7M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Index.db
> 1.1G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Data.db
> 11M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Index.db
> 1.7G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Data.db
> 812K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Index.db
> 122M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-208-Data.db
> 744K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-739-Index.db
> 660K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Index.db
> 796K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Index.db
> 137M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Data.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Data.db
> 139M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Data.db
> 940K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Index.db
> 936K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Index.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Data.db
> 672K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-197-Index.db
> 113M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Data.db
> 116M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_
[jira] [Updated] (CASSANDRA-8061) tmplink files are not removed
[
https://issues.apache.org/jira/browse/CASSANDRA-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-8061:
--
Priority: Critical (was: Major)
> tmplink files are not removed
> -
>
> Key: CASSANDRA-8061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8061
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux
>Reporter: Gianluca Borello
>Assignee: Shawn Kumar
>Priority: Critical
> Fix For: 2.1.3
>
>
> After installing 2.1.0, I'm experiencing a bunch of tmplink files that are
> filling my disk. I found https://issues.apache.org/jira/browse/CASSANDRA-7803
> and that is very similar, and I confirm it happens both on 2.1.0 as well as
> from the latest commit on the cassandra-2.1 branch
> (https://github.com/apache/cassandra/commit/aca80da38c3d86a40cc63d9a122f7d45258e4685
> from the cassandra-2.1)
> Even starting with a clean keyspace, after a few hours I get:
> {noformat}
> $ sudo find /raid0 | grep tmplink | xargs du -hs
> 2.7G
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Data.db
> 13M
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Index.db
> 1.8G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Data.db
> 12M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Index.db
> 5.2M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Index.db
> 822M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Data.db
> 7.3M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Index.db
> 1.2G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Data.db
> 6.7M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Index.db
> 1.1G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Data.db
> 11M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Index.db
> 1.7G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Data.db
> 812K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Index.db
> 122M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-208-Data.db
> 744K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-739-Index.db
> 660K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Index.db
> 796K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Index.db
> 137M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Data.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Data.db
> 139M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Data.db
> 940K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Index.db
> 936K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Index.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Data.db
> 672K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-197-Index.db
> 113M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Data.db
> 116M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-197-Data.db
> 712K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e30
[jira] [Comment Edited] (CASSANDRA-7830) Decommissioning fails on a live node
[
https://issues.apache.org/jira/browse/CASSANDRA-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215101#comment-14215101
]
Donald Smith edited comment on CASSANDRA-7830 at 11/17/14 8:29 PM:
---
Stopping and restarting the cassandra process did not help.
Also, I tried it on two other nodes and it didn't work there either, even when
I first stopped the process.
was (Author: thinkerfeeler):
Stopping and restarting the cassandra process did not help.
> Decommissioning fails on a live node
>
>
> Key: CASSANDRA-7830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ananthkumar K S
>
> {code}Exception in thread "main" java.lang.UnsupportedOperationException:
> data is currently moving to this node; unable to leave the ring at
> org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629)
> 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:601) at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at
> com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
> at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601) 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722){code}
> I got the following exception when i was trying to decommission a live node.
> There is no reference in the manual saying that i need to stop the data
> coming into this node. Even then, decommissioning is specified for live nodes.
> Can anyone let me know if am doing something wrong or if this is a bug on
> cassandra part?
> Cassandra Version Used : 2.0.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7830) Decommissioning fails on a live node
[
https://issues.apache.org/jira/browse/CASSANDRA-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215101#comment-14215101
]
Donald Smith edited comment on CASSANDRA-7830 at 11/17/14 8:30 PM:
---
Stopping and restarting the cassandra process did not help.
Also, I tried it on two other nodes and it didn't work there either, even when
I first stopped and restarted the process.
was (Author: thinkerfeeler):
Stopping and restarting the cassandra process did not help.
Also, I tried it on two other nodes and it didn't work there either, even when
I first stopped the process.
> Decommissioning fails on a live node
>
>
> Key: CASSANDRA-7830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ananthkumar K S
>
> {code}Exception in thread "main" java.lang.UnsupportedOperationException:
> data is currently moving to this node; unable to leave the ring at
> org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629)
> 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:601) at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at
> com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
> at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601) 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722){code}
> I got the following exception when i was trying to decommission a live node.
> There is no reference in the manual saying that i need to stop the data
> coming into this node. Even then, decommissioning is specified for live nodes.
> Can anyone let me know if am doing something wrong or if this is a bug on
> cassandra part?
> Cassandra Version Used : 2.0.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8061) tmplink files are not removed
[
https://issues.apache.org/jira/browse/CASSANDRA-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-8061:
--
Assignee: Marcus Eriksson (was: Shawn Kumar)
> tmplink files are not removed
> -
>
> Key: CASSANDRA-8061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8061
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux
>Reporter: Gianluca Borello
>Assignee: Marcus Eriksson
>Priority: Critical
> Fix For: 2.1.3
>
>
> After installing 2.1.0, I'm experiencing a bunch of tmplink files that are
> filling my disk. I found https://issues.apache.org/jira/browse/CASSANDRA-7803
> and that is very similar, and I confirm it happens both on 2.1.0 as well as
> from the latest commit on the cassandra-2.1 branch
> (https://github.com/apache/cassandra/commit/aca80da38c3d86a40cc63d9a122f7d45258e4685
> from the cassandra-2.1)
> Even starting with a clean keyspace, after a few hours I get:
> {noformat}
> $ sudo find /raid0 | grep tmplink | xargs du -hs
> 2.7G
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Data.db
> 13M
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Index.db
> 1.8G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Data.db
> 12M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Index.db
> 5.2M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Index.db
> 822M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Data.db
> 7.3M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Index.db
> 1.2G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Data.db
> 6.7M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Index.db
> 1.1G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Data.db
> 11M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Index.db
> 1.7G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Data.db
> 812K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Index.db
> 122M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-208-Data.db
> 744K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-739-Index.db
> 660K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Index.db
> 796K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Index.db
> 137M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Data.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Data.db
> 139M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Data.db
> 940K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Index.db
> 936K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Index.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Data.db
> 672K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-197-Index.db
> 113M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Data.db
> 116M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-197-Data.db
> 712K
> /raid0/cassandra/data/draios/mounted_fs_b
[jira] [Commented] (CASSANDRA-7830) Decommissioning fails on a live node
[
https://issues.apache.org/jira/browse/CASSANDRA-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215136#comment-14215136
]
Donald Smith commented on CASSANDRA-7830:
-
Following the advice in
http://comments.gmane.org/gmane.comp.db.cassandra.user/5554, I stopped all
nodes and restarted. Now the decommission is working. So this is a workaround.
> Decommissioning fails on a live node
>
>
> Key: CASSANDRA-7830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ananthkumar K S
>
> {code}Exception in thread "main" java.lang.UnsupportedOperationException:
> data is currently moving to this node; unable to leave the ring at
> org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629)
> 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:601) at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at
> com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
> at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601) 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722){code}
> I got the following exception when i was trying to decommission a live node.
> There is no reference in the manual saying that i need to stop the data
> coming into this node. Even then, decommissioning is specified for live nodes.
> Can anyone let me know if am doing something wrong or if this is a bug on
> cassandra part?
> Cassandra Version Used : 2.0.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8061) tmplink files are not removed
[
https://issues.apache.org/jira/browse/CASSANDRA-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215144#comment-14215144
]
Michael Shuler commented on CASSANDRA-8061:
---
The unit test SSTableRewriterTest.testNumberOfFilesAndSizes looks that we've
deleted tmplink and tmp files, but since it does not keep c* running, the DEL
files from lsof are never tested (nor am I sure how a unit test can look for
open deleted files).
To just see what's going on, I bumped the sleep in that test and looked at lsof
in another term, and I do see DEL state tmplink files.
{noformat}
diff --git a/build.xml b/build.xml
index 43fa531..a5fd82a 100644
--- a/build.xml
+++ b/build.xml
@@ -90,7 +90,7 @@
https://repository.apache.org/content/repositories/snapshots"/>
-
+
diff --git a/test/unit/org/apache/cassandra/io/sstable/SSTableRewriterTest.java
b/test/unit/org/apache/cassandra/io/sstable/SSTableRewriterTest.java
index 8a494a6..e2cce41 100644
--- a/test/unit/org/apache/cassandra/io/sstable/SSTableRewriterTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/SSTableRewriterTest.java
@@ -187,7 +187,7 @@ public class SSTableRewriterTest extends SchemaLoader
assertEquals(startStorageMetricsLoad - s.bytesOnDisk() + sum,
StorageMetrics.load.count());
assertEquals(files, sstables.size());
assertEquals(files, cfs.getSSTables().size());
-Thread.sleep(1000);
+Thread.sleep(10);
// tmplink and tmp files should be gone:
assertEquals(sum, cfs.metric.totalDiskSpaceUsed.count());
assertFileCounts(s.descriptor.directory.list(), 0, 0);
{noformat}
> tmplink files are not removed
> -
>
> Key: CASSANDRA-8061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8061
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux
>Reporter: Gianluca Borello
>Assignee: Marcus Eriksson
>Priority: Critical
> Fix For: 2.1.3
>
>
> After installing 2.1.0, I'm experiencing a bunch of tmplink files that are
> filling my disk. I found https://issues.apache.org/jira/browse/CASSANDRA-7803
> and that is very similar, and I confirm it happens both on 2.1.0 as well as
> from the latest commit on the cassandra-2.1 branch
> (https://github.com/apache/cassandra/commit/aca80da38c3d86a40cc63d9a122f7d45258e4685
> from the cassandra-2.1)
> Even starting with a clean keyspace, after a few hours I get:
> {noformat}
> $ sudo find /raid0 | grep tmplink | xargs du -hs
> 2.7G
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Data.db
> 13M
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Index.db
> 1.8G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Data.db
> 12M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Index.db
> 5.2M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Index.db
> 822M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Data.db
> 7.3M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Index.db
> 1.2G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Data.db
> 6.7M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Index.db
> 1.1G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Data.db
> 11M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Index.db
> 1.7G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Data.db
> 812K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Index.db
> 122M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-208-Data.db
> 744K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-739-Index.db
> 660K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Index.db
> 796K
> /raid0/c
[jira] [Resolved] (CASSANDRA-8248) Possible memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler resolved CASSANDRA-8248.
---
Resolution: Duplicate
Just so we don't have two conversations on the same topic, please add
comments/notes to CASSANDRA-8061 - these tickets have been linked, and that
ticket has a bit more info. I'm going to add the thread dump from here to 8061
as well. Thanks!
> Possible memory leak
> -
>
> Key: CASSANDRA-8248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8248
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alexander Sterligov
>Assignee: Shawn Kumar
> Attachments: thread_dump
>
>
> Sometimes during repair cassandra starts to consume more memory than expected.
> Total amount of data on node is about 20GB.
> Size of the data directory is 66GC because of snapshots.
> Top reports:
> {noformat}
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 15724 loadbase 20 0 493g 55g 44g S 28 44.2 4043:24 java
> {noformat}
> At the /proc/15724/maps there are a lot of deleted file maps
> {quote}
> 7f63a6102000-7f63a6332000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6332000-7f63a6562000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6562000-7f63a6792000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6792000-7f63a69c2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a69c2000-7f63a6bf2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6bf2000-7f63a6e22000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6e22000-7f63a7052000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7052000-7f63a7282000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7282000-7f63a74b2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a74b2000-7f63a76e2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a76e2000-7f63a7912000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7912000-7f63a7b42000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7b42000-7f63a7d72000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7d72000-7f63a7fa2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7fa2000-7f63a81d2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a81d2000-7f63a8402000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a8402000-7f63a8622000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a8622000-7f63a8842000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback
[jira] [Updated] (CASSANDRA-8061) tmplink files are not removed
[
https://issues.apache.org/jira/browse/CASSANDRA-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-8061:
--
Attachment: 8248-thread_dump.txt
(Adding the thread_dump from 8248 here)
> tmplink files are not removed
> -
>
> Key: CASSANDRA-8061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8061
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux
>Reporter: Gianluca Borello
>Assignee: Marcus Eriksson
>Priority: Critical
> Fix For: 2.1.3
>
> Attachments: 8248-thread_dump.txt
>
>
> After installing 2.1.0, I'm experiencing a bunch of tmplink files that are
> filling my disk. I found https://issues.apache.org/jira/browse/CASSANDRA-7803
> and that is very similar, and I confirm it happens both on 2.1.0 as well as
> from the latest commit on the cassandra-2.1 branch
> (https://github.com/apache/cassandra/commit/aca80da38c3d86a40cc63d9a122f7d45258e4685
> from the cassandra-2.1)
> Even starting with a clean keyspace, after a few hours I get:
> {noformat}
> $ sudo find /raid0 | grep tmplink | xargs du -hs
> 2.7G
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Data.db
> 13M
> /raid0/cassandra/data/draios/protobuf1-ccc6dce04beb11e4abf997b38fbf920b/draios-protobuf1-tmplink-ka-4515-Index.db
> 1.8G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Data.db
> 12M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-1788-Index.db
> 5.2M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Index.db
> 822M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-2678-Data.db
> 7.3M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Index.db
> 1.2G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3283-Data.db
> 6.7M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Index.db
> 1.1G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-3951-Data.db
> 11M
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Index.db
> 1.7G
> /raid0/cassandra/data/draios/protobuf_by_agent1-cd071a304beb11e4abf997b38fbf920b/draios-protobuf_by_agent1-tmplink-ka-4799-Data.db
> 812K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Index.db
> 122M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-208-Data.db
> 744K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-739-Index.db
> 660K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Index.db
> 796K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Index.db
> 137M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-230-Data.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Data.db
> 139M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-234-Data.db
> 940K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Index.db
> 936K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-269-Index.db
> 161M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-786-Data.db
> 672K
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-197-Index.db
> 113M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-tmplink-ka-193-Data.db
> 116M
> /raid0/cassandra/data/draios/mounted_fs_by_agent1-d7bf3e304beb11e4abf997b38fbf920b/draios-mounted_fs_by_agent1-t
[jira] [Created] (CASSANDRA-8329) LeveledCompactionStrategy should split large files across data directories when compacting
J.B. Langston created CASSANDRA-8329: Summary: LeveledCompactionStrategy should split large files across data directories when compacting Key: CASSANDRA-8329 URL: https://issues.apache.org/jira/browse/CASSANDRA-8329 Project: Cassandra Issue Type: Bug Reporter: J.B. Langston Because we fall back to STCS for L0 when LCS gets behind, the sstables in L0 can get quite large during sustained periods of heavy writes. This can result in large imbalances between data volumes when using JBOD support. Eventually these large files get broken up as L0 sstables are moved up into higher levels; however, because LCS only chooses a single volume on which to write all of the sstables created during a single compaction, the imbalance is persisted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14215273#comment-14215273 ] Michael Shuler commented on CASSANDRA-8279: --- Thanks for the update, [~Akhtar_ecil] - I'm glad that worked out for you. > 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 > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670) > 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:744) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8306) exception in nodetool enablebinary
[
https://issues.apache.org/jira/browse/CASSANDRA-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler resolved CASSANDRA-8306.
---
Resolution: Incomplete
So it sounds like bootstrapping failed for some reason, previously, and
starting a fresh bootstrap completed successfully. This can happen for various
reasons, and when it does, the standard procedure is to start the bootstrap
over. Without the failed bootstrap logs to look at, it's difficult to guess.
I'm glad that you were able to work through the problem!
> exception in nodetool enablebinary
> --
>
> Key: CASSANDRA-8306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8306
> Project: Cassandra
> Issue Type: Bug
>Reporter: Rafał Furmański
> Attachments: system.log.zip
>
>
> I was trying to add new node (db4) to existing cluster - with no luck. I
> can't see any errors in system.log. nodetool status shows, that node is
> joining into cluster (for many hours). Attaching error and cluster info:
> {code}
> root@db4:~# nodetool enablebinary
> error: Error starting native transport: null
> -- StackTrace --
> java.lang.RuntimeException: Error starting native transport: null
> at
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:350)
> 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.GeneratedMethodAccessor2.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
> 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
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code}
> root@db4:~# nodetool describecluster
> Cluster Information:
> Name: Production Cluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> b7e98bb9-717f-3f59-bac4-84bc19544e90: [10.195.15.163,
> 10.195.15.162, 10.195.15.167, 10.195.15.166]
> {code}
> {code}
> root@db4:~# nodetool status
> Datacenter: Ashburn
> ===
> Status=Up/Down
[jira] [Commented] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215298#comment-14215298
]
Michael Shuler commented on CASSANDRA-8325:
---
There are a multitude of places that Unsafe is used. While Cassandra on FreeBSD
is interesting to me, personally, it's not a "supported" (quoted intentionally,
because it should just work on Unix-like systems) OS.
Are you able to trigger this in a repeatable manner just starting Cassandra as
above, or was this a random occurrence? Does the same happen on another JDK
(does Oracle release one?)
Thanks for the bug report!
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
>Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log, system.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215300#comment-14215300
]
Michael Shuler commented on CASSANDRA-8325:
---
Answered my own question - runs under linux compat -
https://www.freebsd.org/java/install.html
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
>Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log, system.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8325) Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
[
https://issues.apache.org/jira/browse/CASSANDRA-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215310#comment-14215310
]
Michael Shuler commented on CASSANDRA-8325:
---
>From the mailing list post, it looks like openjdk8 was also attempted.
> Cassandra 2.1.x fails to start on FreeBSD (JVM crash)
> -
>
> Key: CASSANDRA-8325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8325
> Project: Cassandra
> Issue Type: Bug
> Environment: FreeBSD 10.0 with openjdk version "1.7.0_71", 64-Bit
> Server VM
>Reporter: Leonid Shalupov
> Attachments: hs_err_pid1856.log, system.log
>
>
> See attached error file after JVM crash
> {quote}
> FreeBSD xxx.intellij.net 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu
> Jan 16 22:34:59 UTC 2014
> r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> {quote}
> {quote}
> % java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK 64-Bit Server VM (build 24.71-b01, mixed mode)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8329) LeveledCompactionStrategy should split large files across data directories when compacting
[ https://issues.apache.org/jira/browse/CASSANDRA-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8329: -- Component/s: Core Fix Version/s: 2.0.12 Assignee: Marcus Eriksson Issue Type: Improvement (was: Bug) > LeveledCompactionStrategy should split large files across data directories > when compacting > -- > > Key: CASSANDRA-8329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8329 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: J.B. Langston >Assignee: Marcus Eriksson > Fix For: 2.0.12 > > > Because we fall back to STCS for L0 when LCS gets behind, the sstables in L0 > can get quite large during sustained periods of heavy writes. This can > result in large imbalances between data volumes when using JBOD support. > Eventually these large files get broken up as L0 sstables are moved up into > higher levels; however, because LCS only chooses a single volume on which to > write all of the sstables created during a single compaction, the imbalance > is persisted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8192) AssertionError in Memory.java
[
https://issues.apache.org/jira/browse/CASSANDRA-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215336#comment-14215336
]
Jonathan Ellis commented on CASSANDRA-8192:
---
We'll be happy to review any patches you propose, but we're not going to invest
more time into 32bit Windows otherwise. Sorry. As Josh says, if 2.0 works for
you that's probably your best bet.
> AssertionError in Memory.java
> -
>
> Key: CASSANDRA-8192
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8192
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows-7-32 bit, 3GB RAM, Java 1.7.0_67
>Reporter: Andreas Schnitzerling
>Assignee: Joshua McKenzie
> Attachments: cassandra.bat, cassandra.yaml, system.log
>
>
> Since update of 1 of 12 nodes from 2.1.0-rel to 2.1.1-rel Exception during
> start up.
> {panel:title=system.log}
> ERROR [SSTableBatchOpen:1] 2014-10-27 09:44:00,079 CassandraDaemon.java:153 -
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.io.util.Memory.size(Memory.java:307)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.compress.CompressionMetadata.(CompressionMetadata.java:135)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.compress.CompressionMetadata.create(CompressionMetadata.java:83)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.CompressedSegmentedFile$Builder.metadata(CompressedSegmentedFile.java:50)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.CompressedPoolingSegmentedFile$Builder.complete(CompressedPoolingSegmentedFile.java:48)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:766)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:725)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:402)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:302)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:438)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> ~[na:1.7.0_55]
> at java.util.concurrent.FutureTask.run(Unknown Source) ~[na:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> [na:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> [na:1.7.0_55]
> at java.lang.Thread.run(Unknown Source) [na:1.7.0_55]
> {panel}
> In the attached log you can still see as well CASSANDRA-8069 and
> CASSANDRA-6283.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8295) Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
[
https://issues.apache.org/jira/browse/CASSANDRA-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215370#comment-14215370
]
Jonathan Ellis commented on CASSANDRA-8295:
---
Unthrottling compaction will make it worse, not better.
Fundamentally you can only throw data at the disks so fast. Cassandra will
start sending back timeout exceptions if you exceed that and it has to load
shed ("MUTATION messages dropped"). At that point you can either respect the
load shed and back off, add capacity to meet your desired ingest rate. Right
now you are doing neither and suffering for it.
> Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
> -
>
> Key: CASSANDRA-8295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8295
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: DSE 4.5.3 Cassandra 2.0.11.82
>Reporter: Jose Martinez Poblete
> Attachments: alln01-ats-cas3.cassandra.yaml, output.tgz, system.tgz,
> system.tgz.1, system.tgz.2, system.tgz.3
>
>
> Customer runs a 3 node cluster
> Their dataset is less than 1Tb and during data load, one of the nodes enter a
> GC death spiral:
> {noformat}
> INFO [ScheduledTasks:1] 2014-11-07 23:31:08,094 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 3348 ms for 2 collections, 1658268944 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,486 GCInspector.java (line 116)
> GC for ParNew: 442 ms for 2 collections, 6079570032 used; max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,487 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 7351 ms for 2 collections, 6084678280 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:01,836 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 603 ms for 1 collections, 7132546096 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:09,626 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 761 ms for 1 collections, 7286946984 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:15,265 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 703 ms for 1 collections, 7251213520 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:25,027 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 1205 ms for 1 collections, 6507586104 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:41,374 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 13835 ms for 3 collections, 6514187192 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:54,137 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 6834 ms for 2 collections, 6521656200 used; max
> is 8375238656
> ...
> INFO [ScheduledTasks:1] 2014-11-08 12:13:11,086 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 43967 ms for 2 collections, 8368777672 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:14,151 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 63968 ms for 3 collections, 8369623824 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:55,643 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 41307 ms for 2 collections, 8370115376 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:20:06,197 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 309634 ms for 15 collections, 8374994928 used;
> max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 13:07:33,617 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 2681100 ms for 143 collections, 8347631560 used;
> max is 8375238656
> {noformat}
> Their application waits 1 minute before a retry when a timeout is returned
> This is what we find on their heapdumps:
> {noformat}
> Class Name
>
>
>| Shallow Heap
> | Retained Heap | Percentage
> -
> org.apache.cassandra.db.Memtable @ 0x773f52f80
>
>
>
[jira] [Updated] (CASSANDRA-8053) Support for user defined aggregate functions
[
https://issues.apache.org/jira/browse/CASSANDRA-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-8053:
--
Reviewer: Tyler Hobbs
[~thobbs] to review
> Support for user defined aggregate functions
>
>
> Key: CASSANDRA-8053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8053
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: cql, udf
> Fix For: 3.0
>
> Attachments: 8053v1.txt
>
>
> CASSANDRA-4914 introduces aggregate functions.
> This ticket is about to decide how we can support "user defined aggregate
> functions". UD aggregate functions should be supported for all UDF flavors
> (class, java, jsr223).
> Things to consider:
> * Special implementations for each scripting language should be omitted
> * No exposure of internal APIs (e.g. {{AggregateFunction}} interface)
> * No need for users to deal with serializers / codecs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8308) Windows: Commitlog access violations on unit tests
[
https://issues.apache.org/jira/browse/CASSANDRA-8308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-8308:
---
Attachment: 8308_v1.txt
# Swapped to FileChannel on CommitLogSegment
# Use reflection to grab FD out of it to use in trySkipCache (new method in
CLibrary)
# Added clibrary method for strerror
# Added logger warning on non-0 result from trySkipCache w/error message
# Tweaked logic on SchemaLoader to recursively delete contents of commitlog
folder rather than the folder itself
This fixes 3 of the 4 unit tests above; SSTableRewriterTest assumes that when a
sstable is successfully deleted it won't be present in the filesystem, however
on Windows when you delete a file with FILE_SHARE_DELETE and something else
still has a handle to the file, it stays in its original location on the drive
rather than getting removed and a link preserved in the /proc filesystem. I'll
open another ticket to make the SSTableRewriter tests more multi-platform
friendly.
The warning on trySkipCache has uncovered that we have invalid fd references on
our trySkipCache calls in SSTR.cloneWithNewStart - I haven't dug into it yet
but it might be an ordering issue where a file's deleted before we
posix_fadvise it.
> Windows: Commitlog access violations on unit tests
> --
>
> Key: CASSANDRA-8308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8308
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joshua McKenzie
>Assignee: Joshua McKenzie
>Priority: Minor
> Labels: Windows
> Fix For: 3.0
>
> Attachments: 8308_v1.txt
>
>
> We have four unit tests failing on trunk on Windows, all with
> FileSystemException's related to the SchemaLoader:
> {noformat}
> [junit] Test
> org.apache.cassandra.db.compaction.DateTieredCompactionStrategyTest FAILED
> [junit] Test org.apache.cassandra.cql3.ThriftCompatibilityTest FAILED
> [junit] Test org.apache.cassandra.io.sstable.SSTableRewriterTest FAILED
> [junit] Test org.apache.cassandra.repair.LocalSyncTaskTest FAILED
> {noformat}
> Example error:
> {noformat}
> [junit] Caused by: java.nio.file.FileSystemException:
> build\test\cassandra\commitlog;0\CommitLog-5-1415908745965.log: The process
> cannot access the file because it is being used by another process.
> [junit]
> [junit] at
> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> [junit] at
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> [junit] at
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> [junit] at
> sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> [junit] at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> [junit] at java.nio.file.Files.delete(Files.java:1079)
> [junit] at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:125)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8328) Expose Thread Pool maximum pool size in metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8328: -- Reviewer: Joshua McKenzie Assignee: Chris Lohfink [~JoshuaMcKenzie] to review > Expose Thread Pool maximum pool size in metrics > --- > > Key: CASSANDRA-8328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8328 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Trivial > Labels: metrics > Attachments: 0001-add-max-pool-size-metrics-for-CASSANDRA-8328.patch > > > The max pool size is exposed in the original > (o.a.c.internal/request/transport) metrics from CASSANDRA-5044, but they are > not available in the o.a.c.metrics beans. Pretty minor change to also expose > this there, which gives context to the maximum number of active tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8228) Log malfunctioning host on prepareForRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-8228: -- Reviewer: Yuki Morishita > Log malfunctioning host on prepareForRepair > --- > > Key: CASSANDRA-8228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8228 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Juho Mäkinen >Assignee: Rajanarayanan Thottuvaikkatumana >Priority: Trivial > Labels: lhf > Attachments: cassandra-trunk-8228.txt > > > Repair startup goes thru ActiveRepairService.prepareForRepair() which might > result with "Repair failed with error Did not get positive replies from all > endpoints." error, but there's no other logging regarding to this error. > It seems that it would be trivial to modify the prepareForRepair() to log the > host address which caused the error, thus ease the debugging effort. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8327) snapshots taken before repair are not cleared if snapshot fails
[ https://issues.apache.org/jira/browse/CASSANDRA-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-8327: -- Assignee: Yuki Morishita > snapshots taken before repair are not cleared if snapshot fails > --- > > Key: CASSANDRA-8327 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8327 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: cassandra 2.0.10.71 >Reporter: MASSIMO CELLI >Assignee: Yuki Morishita >Priority: Minor > > running repair service the following directory was created for the snapshots: > drwxr-xr-x 2 cassandra cassandra 36864 Nov 5 07:47 > 073d16e0-64c0-11e4-8e9a-7b3d4674c508 > but the system.log reports the following error which suggests the snapshot > failed: > ERROR [RMI TCP Connection(3251)-10.150.27.78] 2014-11-05 07:47:55,734 > StorageService.java (line 2599) Repair session > 073d16e0-64c0-11e4-8e9a-7b3d4674c508 for range > (7530018576963469312,7566047373982433280] failed with error > java.io.IOException: Failed during snapshot creation. > java.util.concurrent.ExecutionException: java.lang.RuntimeException: > java.io.IOException: Failed during snapshot creation. ERROR > [AntiEntropySessions:3312] 2014-11-05 07:47:55,731 RepairSession.java (line > 288) [repair #073d16e0-64c0-11e4-8e9a-7b3d4674c508] session completed with > the following error java.io.IOException: Failed during snapshot creation. > the problem is that the directory for the snapshots that fail are just left > on the disk and don't get cleaned up. They must be removed manually, which is > not ideal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8326) Cqlsh cannot connect in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215468#comment-14215468
]
Aleksey Yeschenko commented on CASSANDRA-8326:
--
FWIW the python driver shouldn't be needing the alias columns since 2.0, and
index_interval since 2.1. And *all* of these tables will be gone after
CASSANDRA-6717.
> Cqlsh cannot connect in trunk
> -
>
> Key: CASSANDRA-8326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8326
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Fix For: 3.0
>
>
> Cqlsh errors with {code}Unable to connect to any servers', {'127.0.0.1':
> KeyError('column_aliases',)}{code}. To fix, we need to pull in a newer
> version of the python driver that doesn't assume certain metadata exists.
> This was broken by the cassandra commit
> {{cbbc1191ce1656a92354a4fa3859626cb10083e5}}. A fix should be in version
> 2.1.3 of the driver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-7830) Decommissioning fails on a live node
[
https://issues.apache.org/jira/browse/CASSANDRA-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler resolved CASSANDRA-7830.
---
Resolution: Not a Problem
Reproduced In: 2.0.11, 2.0.3 (was: 2.0.3, 2.0.11)
In this case, the error is clear: "data is currently moving to this node;
unable to leave the ring"
Without knowing clearly what ring changes were made and the statuses, etc.,
it's difficult to tell why that occurred. In addition, at this point, the node
is gone, so it would be difficult to troubleshoot any longer :)
> Decommissioning fails on a live node
>
>
> Key: CASSANDRA-7830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7830
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ananthkumar K S
>
> {code}Exception in thread "main" java.lang.UnsupportedOperationException:
> data is currently moving to this node; unable to leave the ring at
> org.apache.cassandra.service.StorageService.decommission(StorageService.java:2629)
> 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:601) at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at
> com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
> at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601) 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
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722){code}
> I got the following exception when i was trying to decommission a live node.
> There is no reference in the manual saying that i need to stop the data
> coming into this node. Even then, decommissioning is specified for live nodes.
> Can anyone let me know if am doing something wrong or if this is a bug on
> cassandra part?
> Cassandra Version Used : 2.0.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7281) SELECT on tuple relations are broken for mixed ASC/DESC clustering order
[
https://issues.apache.org/jira/browse/CASSANDRA-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Szymaniuk updated CASSANDRA-7281:
Attachment: 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch
This patch makes the tuple query working
There are two concerns though:
1. I don't get why we have the last line assert in
testMultipleClusteringReversedComponents. The fact result set is not empty now
seem to be correct to me.
2. Not sure about validateSlices. The way slices are represented makes it fail
sometimes. Not sure if it's a bug in my code or I the validation is not correct
anymore. Here is example of validate failing:
create table foo (a int, b int, c int, d int , e int, PRIMARY KEY (a, b, c, d,
e) )
WITH CLUSTERING ORDER BY (b DESC, c ASC, d ASC, e DESC);
SELECT * FROM foo WHERE a=0 AND (b, c, d, e) > (0, 1, 1, 0);
I transform this restriction to 4 independent restrictions:
b>0
b=0 c=1 d=1 e>0
b=0 c=1 c>1
b=0 c>1
when we create slices out of it it ends up as:
slices = [[, 0004ff], [000404000104000100,
000404000104000104ff],
[000404000104000101, 000404000101],
[000404000101, 000401]]
so slices[2][1]==slices[3][0] which seems fine to me (maybe not optimal?)
then this condition in validateSlices make it fail:
if (i > 0 && comparator.compare(slices[i - 1].finish, start) >= 0)
In the patch I commented out the problematic condition in validation and the
query works. If the validation is still valid I will have to fix the code but I
need some sugestions.
Also I have bunch of dtests. Do I submit them independently?
> SELECT on tuple relations are broken for mixed ASC/DESC clustering order
>
>
> Key: CASSANDRA-7281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7281
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
> Fix For: 2.0.12
>
> Attachments:
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch
>
>
> As noted on
> [CASSANDRA-6875|https://issues.apache.org/jira/browse/CASSANDRA-6875?focusedCommentId=13992153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992153],
> the tuple notation is broken when the clustering order mixes ASC and DESC
> directives because the range of data they describe don't correspond to a
> single continuous slice internally. To copy the example from CASSANDRA-6875:
> {noformat}
> cqlsh:ks> create table foo (a int, b int, c int, PRIMARY KEY (a, b, c)) WITH
> CLUSTERING ORDER BY (b DESC, c ASC);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 2, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 1);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 0, 0);
> cqlsh:ks> SELECT * FROM foo WHERE a=0;
> a | b | c
> ---+---+---
> 0 | 2 | 0
> 0 | 1 | 0
> 0 | 1 | 1
> 0 | 0 | 0
> (4 rows)
> cqlsh:ks> SELECT * FROM foo WHERE a=0 AND (b, c) > (1, 0);
> a | b | c
> ---+---+---
> 0 | 2 | 0
> (1 rows)
> {noformat}
> The last query should really return {{(0, 2, 0)}} and {{(0, 1, 1)}}.
> For that specific example we should generate 2 internal slices, but I believe
> that with more clustering columns we may have more slices.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7281) SELECT on tuple relations are broken for mixed ASC/DESC clustering order
[
https://issues.apache.org/jira/browse/CASSANDRA-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215488#comment-14215488
]
Michael Shuler commented on CASSANDRA-7281:
---
Nit: if you're going to remove lines in
{{src/java/org/apache/cassandra/db/filter/ColumnSlice.java}}, remove them,
please, don't comment them out.
> SELECT on tuple relations are broken for mixed ASC/DESC clustering order
>
>
> Key: CASSANDRA-7281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7281
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
> Fix For: 2.0.12
>
> Attachments:
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch
>
>
> As noted on
> [CASSANDRA-6875|https://issues.apache.org/jira/browse/CASSANDRA-6875?focusedCommentId=13992153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992153],
> the tuple notation is broken when the clustering order mixes ASC and DESC
> directives because the range of data they describe don't correspond to a
> single continuous slice internally. To copy the example from CASSANDRA-6875:
> {noformat}
> cqlsh:ks> create table foo (a int, b int, c int, PRIMARY KEY (a, b, c)) WITH
> CLUSTERING ORDER BY (b DESC, c ASC);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 2, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 1);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 0, 0);
> cqlsh:ks> SELECT * FROM foo WHERE a=0;
> a | b | c
> ---+---+---
> 0 | 2 | 0
> 0 | 1 | 0
> 0 | 1 | 1
> 0 | 0 | 0
> (4 rows)
> cqlsh:ks> SELECT * FROM foo WHERE a=0 AND (b, c) > (1, 0);
> a | b | c
> ---+---+---
> 0 | 2 | 0
> (1 rows)
> {noformat}
> The last query should really return {{(0, 2, 0)}} and {{(0, 1, 1)}}.
> For that specific example we should generate 2 internal slices, but I believe
> that with more clustering columns we may have more slices.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7281) SELECT on tuple relations are broken for mixed ASC/DESC clustering order
[
https://issues.apache.org/jira/browse/CASSANDRA-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215496#comment-14215496
]
Michael Shuler commented on CASSANDRA-7281:
---
Missed the dtest comment - send those as a pull request on
https://github.com/riptano/cassandra-dtest - thanks!
> SELECT on tuple relations are broken for mixed ASC/DESC clustering order
>
>
> Key: CASSANDRA-7281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7281
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
> Fix For: 2.0.12
>
> Attachments:
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch
>
>
> As noted on
> [CASSANDRA-6875|https://issues.apache.org/jira/browse/CASSANDRA-6875?focusedCommentId=13992153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992153],
> the tuple notation is broken when the clustering order mixes ASC and DESC
> directives because the range of data they describe don't correspond to a
> single continuous slice internally. To copy the example from CASSANDRA-6875:
> {noformat}
> cqlsh:ks> create table foo (a int, b int, c int, PRIMARY KEY (a, b, c)) WITH
> CLUSTERING ORDER BY (b DESC, c ASC);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 2, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 1);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 0, 0);
> cqlsh:ks> SELECT * FROM foo WHERE a=0;
> a | b | c
> ---+---+---
> 0 | 2 | 0
> 0 | 1 | 0
> 0 | 1 | 1
> 0 | 0 | 0
> (4 rows)
> cqlsh:ks> SELECT * FROM foo WHERE a=0 AND (b, c) > (1, 0);
> a | b | c
> ---+---+---
> 0 | 2 | 0
> (1 rows)
> {noformat}
> The last query should really return {{(0, 2, 0)}} and {{(0, 1, 1)}}.
> For that specific example we should generate 2 internal slices, but I believe
> that with more clustering columns we may have more slices.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7281) SELECT on tuple relations are broken for mixed ASC/DESC clustering order
[
https://issues.apache.org/jira/browse/CASSANDRA-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-7281:
--
Reviewer: Sylvain Lebresne
> SELECT on tuple relations are broken for mixed ASC/DESC clustering order
>
>
> Key: CASSANDRA-7281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7281
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
> Fix For: 2.0.12
>
> Attachments:
> 0001-CASSANDRA-7281-SELECT-on-tuple-relations-are-broken-.patch
>
>
> As noted on
> [CASSANDRA-6875|https://issues.apache.org/jira/browse/CASSANDRA-6875?focusedCommentId=13992153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992153],
> the tuple notation is broken when the clustering order mixes ASC and DESC
> directives because the range of data they describe don't correspond to a
> single continuous slice internally. To copy the example from CASSANDRA-6875:
> {noformat}
> cqlsh:ks> create table foo (a int, b int, c int, PRIMARY KEY (a, b, c)) WITH
> CLUSTERING ORDER BY (b DESC, c ASC);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 2, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 0);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 1, 1);
> cqlsh:ks> INSERT INTO foo (a, b, c) VALUES (0, 0, 0);
> cqlsh:ks> SELECT * FROM foo WHERE a=0;
> a | b | c
> ---+---+---
> 0 | 2 | 0
> 0 | 1 | 0
> 0 | 1 | 1
> 0 | 0 | 0
> (4 rows)
> cqlsh:ks> SELECT * FROM foo WHERE a=0 AND (b, c) > (1, 0);
> a | b | c
> ---+---+---
> 0 | 2 | 0
> (1 rows)
> {noformat}
> The last query should really return {{(0, 2, 0)}} and {{(0, 1, 1)}}.
> For that specific example we should generate 2 internal slices, but I believe
> that with more clustering columns we may have more slices.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8330) Confusing Message: ConfigurationException: Found system keyspace files, but they couldn't be loaded!
Karl Mueller created CASSANDRA-8330: --- Summary: Confusing Message: ConfigurationException: Found system keyspace files, but they couldn't be loaded! Key: CASSANDRA-8330 URL: https://issues.apache.org/jira/browse/CASSANDRA-8330 Project: Cassandra Issue Type: Bug Environment: cassandra 2.0.10 Reporter: Karl Mueller Priority: Minor I restarted a node which was not responding to cqlsh. It produced this error: INFO [SSTableBatchOpen:3] 2014-11-17 16:36:50,388 SSTableReader.java (line 223) Opening /data2/data-cassandra/system/local/system-local-jb-304 (133 bytes) INFO [SSTableBatchOpen:2] 2014-11-17 16:36:50,388 SSTableReader.java (line 223) Opening /data2/data-cassandra/system/local/system-local-jb-305 (80 bytes) INFO [main] 2014-11-17 16:36:50,393 AutoSavingCache.java (line 114) reading saved cache /data2/cache-cassandra/system-local-KeyCache-b.db ERROR [main] 2014-11-17 16:36:50,543 CassandraDaemon.java (line 265) Fatal exception during initialization org.apache.cassandra.exceptions.ConfigurationException: Found system keyspace files, but they couldn't be loaded! at org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:554) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:261) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) After deleting the cache, I still got this error: INFO 16:41:43,718 Opening /data2/data-cassandra/system/local/system-local-jb-304 (133 bytes) INFO 16:41:43,718 Opening /data2/data-cassandra/system/local/system-local-jb-305 (80 bytes) ERROR 16:41:43,877 Fatal exception during initialization org.apache.cassandra.exceptions.ConfigurationException: Found system keyspace files, but they couldn't be loaded! at org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:554) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:261) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) I think possibly the node had corrupted one of the files due to it being in a bad state. This would be impossible to replicate, so I don't think the actual bug is that helpful. What I did find very confusing was the error message. There's nothing to indicate what the problem is! Is it a corrupt file? A valid file with bad information in it? Referencing something that doesn't exist?! I fixed it by deleting the system keyspace and starting it with its token, but many people wouldn't know to do that at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8295) Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
[
https://issues.apache.org/jira/browse/CASSANDRA-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215590#comment-14215590
]
Jose Martinez Poblete commented on CASSANDRA-8295:
--
Thanks [~jbellis]
> Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
> -
>
> Key: CASSANDRA-8295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8295
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: DSE 4.5.3 Cassandra 2.0.11.82
>Reporter: Jose Martinez Poblete
> Attachments: alln01-ats-cas3.cassandra.yaml, output.tgz, system.tgz,
> system.tgz.1, system.tgz.2, system.tgz.3
>
>
> Customer runs a 3 node cluster
> Their dataset is less than 1Tb and during data load, one of the nodes enter a
> GC death spiral:
> {noformat}
> INFO [ScheduledTasks:1] 2014-11-07 23:31:08,094 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 3348 ms for 2 collections, 1658268944 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,486 GCInspector.java (line 116)
> GC for ParNew: 442 ms for 2 collections, 6079570032 used; max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,487 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 7351 ms for 2 collections, 6084678280 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:01,836 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 603 ms for 1 collections, 7132546096 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:09,626 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 761 ms for 1 collections, 7286946984 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:15,265 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 703 ms for 1 collections, 7251213520 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:25,027 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 1205 ms for 1 collections, 6507586104 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:41,374 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 13835 ms for 3 collections, 6514187192 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:54,137 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 6834 ms for 2 collections, 6521656200 used; max
> is 8375238656
> ...
> INFO [ScheduledTasks:1] 2014-11-08 12:13:11,086 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 43967 ms for 2 collections, 8368777672 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:14,151 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 63968 ms for 3 collections, 8369623824 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:55,643 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 41307 ms for 2 collections, 8370115376 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:20:06,197 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 309634 ms for 15 collections, 8374994928 used;
> max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 13:07:33,617 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 2681100 ms for 143 collections, 8347631560 used;
> max is 8375238656
> {noformat}
> Their application waits 1 minute before a retry when a timeout is returned
> This is what we find on their heapdumps:
> {noformat}
> Class Name
>
>
>| Shallow Heap
> | Retained Heap | Percentage
> -
> org.apache.cassandra.db.Memtable @ 0x773f52f80
>
>
>| 72
> | 8,086,073,504 | 96.66%
> |- java.util.concurrent.ConcurrentSkipListMap @ 0x724508fe8
>
>
>| 4
[jira] [Created] (CASSANDRA-8331) Expose rate of change of values in histograms
Chris Lohfink created CASSANDRA-8331: Summary: Expose rate of change of values in histograms Key: CASSANDRA-8331 URL: https://issues.apache.org/jira/browse/CASSANDRA-8331 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Chris Lohfink Priority: Minor In the Metrics JMX Histograms, Sum has value for systems that want to get derivatives of the data to find rates of change. Particularly if the timing of collection is not perfect. The meters give some perspective to the rate of which things occur but not of the values themselves. This could be opened up in metrics but its been shot down: https://github.com/dropwizard/metrics/pull/304 I think theres still value in this. He does have point on distribution of data within the period, but in small windows with not very extreme values (ie sstables per read per second) I think its moot. Alternatively we can provide Meters for each of the histograms to use its implementation of a exponentially weighted moving average to get this value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8331) Expose rate of change of values in histograms
[ https://issues.apache.org/jira/browse/CASSANDRA-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215636#comment-14215636 ] Chris Lohfink commented on CASSANDRA-8331: -- I will be willing to give a shot at a patch for exposing Sum or adding a meter to a few choice histograms if its a good idea. > Expose rate of change of values in histograms > - > > Key: CASSANDRA-8331 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8331 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Priority: Minor > Labels: metrics > > In the Metrics JMX Histograms, Sum has value for systems that want to get > derivatives of the data to find rates of change. Particularly if the timing > of collection is not perfect. The meters give some perspective to the rate > of which things occur but not of the values themselves. This could be opened > up in metrics but its been shot down: > https://github.com/dropwizard/metrics/pull/304 > I think theres still value in this. He does have point on distribution of > data within the period, but in small windows with not very extreme values (ie > sstables per read per second) I think its moot. > Alternatively we can provide Meters for each of the histograms to use its > implementation of a exponentially weighted moving average to get this value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[ https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215660#comment-14215660 ] Alan Boudreault commented on CASSANDRA-7386: [~lyubent] I am currently testing the patch. What metrics did you use to generate you graphes (per disk)? Thanks > 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: Robert Stupp >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7386-2.0-v3.txt, 7386-2.1-v3.txt, 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] [Commented] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[ https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215665#comment-14215665 ] Lyuben Todorov commented on CASSANDRA-7386: --- [~aboudreault] It's *WriteValueMean* (wvm) that I used. The graph shows the wvm drop for the five discs that were un-saturated (they have a higher wvm to begin with during the second run as they are choosen more frequently over the two drives that were previously saturated). > 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: Robert Stupp >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7386-2.0-v3.txt, 7386-2.1-v3.txt, 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] [Created] (CASSANDRA-8332) Null pointer after droping keyspace
Chris Lohfink created CASSANDRA-8332:
Summary: Null pointer after droping keyspace
Key: CASSANDRA-8332
URL: https://issues.apache.org/jira/browse/CASSANDRA-8332
Project: Cassandra
Issue Type: Bug
Reporter: Chris Lohfink
Priority: Minor
After dropping keyspace, sometimes I see this in logs:
{code}
ERROR 03:40:29 Exception in thread Thread[CompactionExecutor:2,1,main]
java.lang.AssertionError: null
at
org.apache.cassandra.io.compress.CompressionParameters.setLiveMetadata(CompressionParameters.java:108)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableReader.getCompressionMetadata(SSTableReader.java:1142)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableReader.openDataReader(SSTableReader.java:1896)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableScanner.(SSTableScanner.java:68)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:1681)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:1693)
~[main/:na]
at
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getScanners(LeveledCompactionStrategy.java:181)
~[main/:na]
at
org.apache.cassandra.db.compaction.WrappingCompactionStrategy.getScanners(WrappingCompactionStrategy.java:320)
~[main/:na]
at
org.apache.cassandra.db.compaction.AbstractCompactionStrategy.getScanners(AbstractCompactionStrategy.java:340)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:151)
~[main/:na]
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
~[main/:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:75)
~[main/:na]
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:233)
~[main/:na]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
~[na:1.7.0_71]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
~[na:1.7.0_71]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_71]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_71]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
{code}
Minor issue since doesn't really affect anything, but the error makes it look
like somethings wrong. Seen on 2.1 branch
(1b21aef8152d96a180e75f2fcc5afad9ded6c595), not sure how far back (may be post
2.1.2).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
