[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Attachment: cassandra-1.1-4656-histograms_with_empty_values.txt
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: cassandra-1.1-4656-histograms_with_empty_values.txt,
cassandra-1.2-4656-empty_values.txt
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4678) Add possibility to stop repair session from nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zotov updated CASSANDRA-4678: Attachment: (was: nodetool_stoprepair_command_v1.patch) Add possibility to stop repair session from nodetool Key: CASSANDRA-4678 URL: https://issues.apache.org/jira/browse/CASSANDRA-4678 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Minor Labels: nodetool, repair Attachments: cassandra-1.1-4678.txt I've added possibility to stop repair session from nodetool. 'stoprepair' command has been introduced. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4677) Change description of nodetool ring command
[
https://issues.apache.org/jira/browse/CASSANDRA-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4677:
Attachment: (was: nodetool_ring_description.patch)
Change description of nodetool ring command
---
Key: CASSANDRA-4677
URL: https://issues.apache.org/jira/browse/CASSANDRA-4677
Project: Cassandra
Issue Type: Task
Components: Tools
Affects Versions: 1.1.5
Reporter: Alexey Zotov
Priority: Trivial
Labels: ring
Attachments: cassandra-1.1-4677.txt
Additional option of 'nodetool ring' command is not documented.
Old variant:
{code}
ring - Print information about the token ring
{code}
New variant
{code}
ring [keyspace]- Print information about the token ring for a given
keyspace (for all keyspaces if it is not specified)
{code}
Patch has been attached.
Some history (I think it will be useful for someone who will have the same
problem):
I have 4-nodes cluster. One of nodes is located in other DC (DC2). I've met
the problem that 'nodetool ring' shows that node in DC2 'Owns 0.00%'. I've
found following questions:
http://www.datastax.com/support-forums/topic/owns-in-nodetool
http://mail-archives.apache.org/mod_mbox/cassandra-user/201202.mbox/%3c323dbc99-8519-4e86-b69b-6520d53fa...@humbaba.net%3E
and task with fix:
https://issues.apache.org/jira/browse/CASSANDRA-3412
So you should use 'nodetool ring keyspace' for getting right information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Attachment: cassandra-1.2-4656-empty_values.txt
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: cassandra-1.1-4656-histograms_with_empty_values.txt,
cassandra-1.2-4656-empty_values.txt
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Attachment: cassandra-1.2-4656-empty_values.tx
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: cassandra-1.1-4656-histograms_with_empty_values.txt,
cassandra-1.2-4656-empty_values.txt
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Attachment: (was: cassandra-1.2-4656-empty_values.tx)
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: cassandra-1.1-4656-histograms_with_empty_values.txt,
cassandra-1.2-4656-empty_values.txt
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Attachment: (was: StorageProxy_histograms_with_empty_values_v11.patch)
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: cassandra-1.1-4656-histograms_with_empty_values.txt,
cassandra-1.2-4656-empty_values.txt
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Attachment: (was: Empty_values_in_histograms_v12.patch)
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: cassandra-1.1-4656-histograms_with_empty_values.txt,
cassandra-1.2-4656-empty_values.txt
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458438#comment-13458438
]
Alexey Zotov commented on CASSANDRA-4656:
-
Patches have been recreated using git instead of intellij idea.
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: cassandra-1.1-4656-histograms_with_empty_values.txt,
cassandra-1.2-4656-empty_values.txt
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4683) running nodetool cleanup throws an exception
[ https://issues.apache.org/jira/browse/CASSANDRA-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458440#comment-13458440 ] Sylvain Lebresne commented on CASSANDRA-4683: - In particular, there is no assertion whatsoever in SystemTable.getCurrentLocalNodeId() in 1.1.5 so I suspect too that this is not a 1.1.5 node. running nodetool cleanup throws an exception Key: CASSANDRA-4683 URL: https://issues.apache.org/jira/browse/CASSANDRA-4683 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Reporter: Bartłomiej Romański We've just upgraded to 1.1.5 from 1.1.2. After that running nodetool cleanup we've got the following error: Exception in thread main java.lang.AssertionError at org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:462) at org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.init(NodeId.java:195) at org.apache.cassandra.utils.NodeId$LocalIds.clinit(NodeId.java:43) at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:50) at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:55) at org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:175) at org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1769) 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:1447) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:89) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1292) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1380) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:812) 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at sun.rmi.transport.Transport$1.run(Transport.java:174) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Any ideas? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4584: --- Attachment: 4584.patch patch that adds the keyword trace to cql3. tracing is forced for a query when the keyword is prepended (e.g. trace select * from Standard1;) the CqlResult from the query includes the session uuid so that clients may use it to query the events/sessions tables adds support for showing said uuid in cqlsh *but* couldn't figure out how to format it in intelligible form (only gibberish is printed, uuid is returned as bytes, tried using the formatting methods but ultimately gave up, need help). also altered cassandra-dbapi2 so that cursor now includes the uuid from the reponse (submitted patch in http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=24) Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458454#comment-13458454 ] David Alves edited comment on CASSANDRA-4584 at 9/19/12 5:37 PM: - patch that adds the keyword trace to cql3. tracing is forced for a query when the keyword is prepended (e.g. trace select * from Standard1;) the CqlResult from the query includes the session uuid so that clients may use it to query the events/sessions tables adds support for showing said uuid in cqlsh *but* couldn't figure out how to format it in intelligible form (only gibberish is printed, uuid is returned as bytes, tried using the formatting methods but ultimately gave up, need help). also altered cassandra-dbapi2 so that cursor now includes the uuid from the reponse (submitted patch in http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=24) was (Author: dr-alves): patch that adds the keyword trace to cql3. tracing is forced for a query when the keyword is prepended (e.g. trace select * from Standard1;) the CqlResult from the query includes the session uuid so that clients may use it to query the events/sessions tables adds support for showing said uuid in cqlsh *but* couldn't figure out how to format it in intelligible form (only gibberish is printed, uuid is returned as bytes, tried using the formatting methods but ultimately gave up, need help). also altered cassandra-dbapi2 so that cursor now includes the uuid from the reponse (submitted patch in http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=24) Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458458#comment-13458458 ] David Alves commented on CASSANDRA-4584: Note: patch needs an updated version of lib/cql-internal-only-1.2.0.zip that can be built with the patch in http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=24 Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458464#comment-13458464 ] Sylvain Lebresne commented on CASSANDRA-4584: - Have only looked very superficially to the patch but since every statement can be traced, we should call enableTracingIfRequested in a generic place (in QueryProcessor.processStatement typically) rather that in random methods in the specific statements. In particular, it's only called in Modification, Select and Truncate statements, which doesn't cover all the statements. Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458471#comment-13458471 ] David Alves commented on CASSANDRA-4584: Allowing tracing only on Modification/Select and Truncate statements was deliberate as it mimics what is done in the thrift interface (cf/keyspace methods do not enable tracing), but I hadn't thought of placing it in QueryProcessor, maybe it makes more sense there. Still you raise a point should schema altering methods be traced? Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458476#comment-13458476 ] Sylvain Lebresne commented on CASSANDRA-4584: - If we don't want to allow tracing schema altering statements, we shouldn't allow the TRACE syntax and do nothing with it. But honestly I'm not sure there is a point in disallowing tracing for some query, especially since that's more work than doing it for all queries. Besides, for any query it could be interesting to know how long it took to parse it, to validate it and to execute it. Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458492#comment-13458492 ] David Alves commented on CASSANDRA-4584: the non-schema-tracing behavior is legacy from the original patch, but I can't actually think of a reason not to trace schema altering/querying statements, so I'll add it where you suggest (and also add it to thrift for that matter). Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4684) Binary protocol: inform clients of schema changes
Sylvain Lebresne created CASSANDRA-4684: --- Summary: Binary protocol: inform clients of schema changes Key: CASSANDRA-4684 URL: https://issues.apache.org/jira/browse/CASSANDRA-4684 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 2 It would be nice to inform clients when a schema change occurs as this would allow said client to maintain the current state of the schema, which might be useful/desirable. To allow that, we can: # return that a query has changed the schema (instead of simply a 'void' return), in the same spirit than CASSANDRA-3707. # add events notification on schema change. Just to be clear, the goal is only to inform that a change has occured, the client would still have to query the system table to know the exact content of the change, but at least it'll know when to do such query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4684) Binary protocol: inform clients of schema changes
[ https://issues.apache.org/jira/browse/CASSANDRA-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4684: Attachment: 0002-Add-migration-events.txt 0001-Return-schema-change-infos.txt Attaching 2 patches that adds the 2 features described above. Note that this only affect the binary protocol, and it's relatively minor changes, so I think it's probably fine to push in beta2. Binary protocol: inform clients of schema changes - Key: CASSANDRA-4684 URL: https://issues.apache.org/jira/browse/CASSANDRA-4684 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 2 Attachments: 0001-Return-schema-change-infos.txt, 0002-Add-migration-events.txt It would be nice to inform clients when a schema change occurs as this would allow said client to maintain the current state of the schema, which might be useful/desirable. To allow that, we can: # return that a query has changed the schema (instead of simply a 'void' return), in the same spirit than CASSANDRA-3707. # add events notification on schema change. Just to be clear, the goal is only to inform that a change has occured, the client would still have to query the system table to know the exact content of the change, but at least it'll know when to do such query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[1/4] git commit: Print zero instead of empty values. Patch by Alexey Zotov, reviewed by brandonwilliams for CASSANDRA-4656
Updated Branches:
refs/heads/cassandra-1.1 e6326e9fd - b43cc362a
refs/heads/trunk 1693ee22f - 96a46771b
Print zero instead of empty values.
Patch by Alexey Zotov, reviewed by brandonwilliams for CASSANDRA-4656
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/96a46771
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/96a46771
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/96a46771
Branch: refs/heads/trunk
Commit: 96a46771b287a265a4d9faf61543163e342f6d87
Parents: edd0d6d
Author: Brandon Williams brandonwilli...@apache.org
Authored: Wed Sep 19 06:13:34 2012 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Wed Sep 19 06:13:34 2012 -0500
--
src/java/org/apache/cassandra/tools/NodeCmd.java | 16
1 files changed, 8 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/96a46771/src/java/org/apache/cassandra/tools/NodeCmd.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java
b/src/java/org/apache/cassandra/tools/NodeCmd.java
index b7dfb68..5f2ac12 100644
--- a/src/java/org/apache/cassandra/tools/NodeCmd.java
+++ b/src/java/org/apache/cassandra/tools/NodeCmd.java
@@ -828,11 +828,11 @@ public class NodeCmd
{
output.println(String.format(%-10d%10s%18s%18s%18s%18s,
offsets[i],
- (i sprh.length ? sprh[i] : ),
- (i rwlh.length ? rwlh[i] : ),
- (i rrlh.length ? rrlh[i] : ),
- (i ersh.length ? ersh[i] : ),
- (i ecch.length ? ecch[i] : )));
+ (i sprh.length ? sprh[i] : 0),
+ (i rwlh.length ? rwlh[i] : 0),
+ (i rrlh.length ? rrlh[i] : 0),
+ (i ersh.length ? ersh[i] : 0),
+ (i ecch.length ? ecch[i] : 0)));
}
}
@@ -851,9 +851,9 @@ public class NodeCmd
{
output.println(String.format(%-10d%18s%18s%18s,
offsets[i],
-(i rrlh.length ? rrlh[i] : ),
-(i rwlh.length ? rwlh[i] : ),
-(i rrnglh.length ? rrnglh[i] : )));
+(i rrlh.length ? rrlh[i] : 0),
+(i rwlh.length ? rwlh[i] : 0),
+(i rrnglh.length ? rrnglh[i] :
0)));
}
}
[2/4] git commit: Merge branch 'cassandra-1.1' into trunk
Merge branch 'cassandra-1.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/edd0d6d8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/edd0d6d8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/edd0d6d8 Branch: refs/heads/trunk Commit: edd0d6d83e1722150c661f171ac1b4f5d25e32df Parents: 1693ee2 b43cc36 Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Sep 19 06:12:55 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Sep 19 06:12:55 2012 -0500 -- --
[4/4] git commit: Backport proxyhistograms to 1.1, print zero instead of blank values. Patch by Alexey Zotov, reviewed by brandonwilliams for CASSANDRA-4656
Backport proxyhistograms to 1.1, print zero instead of blank values.
Patch by Alexey Zotov, reviewed by brandonwilliams for CASSANDRA-4656
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b43cc362
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b43cc362
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b43cc362
Branch: refs/heads/cassandra-1.1
Commit: b43cc362aa568a46bc53e545c68518b0bd350b76
Parents: e6326e9
Author: Brandon Williams brandonwilli...@apache.org
Authored: Wed Sep 19 06:11:22 2012 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Wed Sep 19 06:11:22 2012 -0500
--
.../org/apache/cassandra/service/StorageProxy.java |3 +-
src/java/org/apache/cassandra/tools/NodeCmd.java | 39 +--
src/java/org/apache/cassandra/tools/NodeProbe.java | 12 +++-
3 files changed, 45 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b43cc362/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 23e0de4..bc45e84 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -63,6 +63,7 @@ import org.apache.cassandra.utils.*;
public class StorageProxy implements StorageProxyMBean
{
+public static final String MBEAN_NAME =
org.apache.cassandra.db:type=StorageProxy;
private static final Logger logger =
LoggerFactory.getLogger(StorageProxy.class);
private static final boolean OPTIMIZE_LOCAL_REQUESTS = true; // set to
false to test messagingservice path on single node
@@ -99,7 +100,7 @@ public class StorageProxy implements StorageProxyMBean
MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
try
{
-mbs.registerMBean(new StorageProxy(), new
ObjectName(org.apache.cassandra.db:type=StorageProxy));
+mbs.registerMBean(new StorageProxy(), new ObjectName(MBEAN_NAME));
}
catch (Exception e)
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b43cc362/src/java/org/apache/cassandra/tools/NodeCmd.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java
b/src/java/org/apache/cassandra/tools/NodeCmd.java
index d0ec068..4d2790d 100644
--- a/src/java/org/apache/cassandra/tools/NodeCmd.java
+++ b/src/java/org/apache/cassandra/tools/NodeCmd.java
@@ -33,6 +33,7 @@ import java.util.Map.Entry;
import java.util.concurrent.ExecutionException;
import org.apache.cassandra.service.CacheServiceMBean;
+import org.apache.cassandra.service.StorageProxyMBean;
import org.apache.commons.cli.*;
import org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutorMBean;
@@ -107,6 +108,7 @@ public class NodeCmd
JOIN,
MOVE,
NETSTATS,
+PROXYHISTOGRAMS,
REBUILD,
REFRESH,
REMOVETOKEN,
@@ -145,6 +147,7 @@ public class NodeCmd
addCmdHelp(header, cfstats, Print statistics on column families);
addCmdHelp(header, version, Print cassandra version);
addCmdHelp(header, tpstats, Print usage statistics of thread
pools);
+addCmdHelp(header, proxyhistograms, Print statistic histograms for
network operations);
addCmdHelp(header, drain, Drain the node (stop accepting writes and
flush all column families));
addCmdHelp(header, decommission, Decommission the *node I am
connecting to*);
addCmdHelp(header, compactionstats, Print statistics on
compactions);
@@ -600,14 +603,35 @@ public class NodeCmd
{
output.println(String.format(%-10d%10s%18s%18s%18s%18s,
offsets[i],
- (i sprh.length ? sprh[i] : ),
- (i rwlh.length ? rwlh[i] : ),
- (i rrlh.length ? rrlh[i] : ),
- (i ersh.length ? ersh[i] : ),
- (i ecch.length ? ecch[i] : )));
+ (i sprh.length ? sprh[i] : 0),
+ (i rwlh.length ? rwlh[i] : 0),
+ (i rrlh.length ? rrlh[i] : 0),
+ (i ersh.length ? ersh[i] : 0),
+ (i ecch.length ? ecch[i] : 0)));
}
}
+private void printProxyHistograms(PrintStream output)
+{
+
[3/4] git commit: Backport proxyhistograms to 1.1, print zero instead of blank values. Patch by Alexey Zotov, reviewed by brandonwilliams for CASSANDRA-4656
Backport proxyhistograms to 1.1, print zero instead of blank values.
Patch by Alexey Zotov, reviewed by brandonwilliams for CASSANDRA-4656
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b43cc362
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b43cc362
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b43cc362
Branch: refs/heads/trunk
Commit: b43cc362aa568a46bc53e545c68518b0bd350b76
Parents: e6326e9
Author: Brandon Williams brandonwilli...@apache.org
Authored: Wed Sep 19 06:11:22 2012 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Wed Sep 19 06:11:22 2012 -0500
--
.../org/apache/cassandra/service/StorageProxy.java |3 +-
src/java/org/apache/cassandra/tools/NodeCmd.java | 39 +--
src/java/org/apache/cassandra/tools/NodeProbe.java | 12 +++-
3 files changed, 45 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b43cc362/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 23e0de4..bc45e84 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -63,6 +63,7 @@ import org.apache.cassandra.utils.*;
public class StorageProxy implements StorageProxyMBean
{
+public static final String MBEAN_NAME =
org.apache.cassandra.db:type=StorageProxy;
private static final Logger logger =
LoggerFactory.getLogger(StorageProxy.class);
private static final boolean OPTIMIZE_LOCAL_REQUESTS = true; // set to
false to test messagingservice path on single node
@@ -99,7 +100,7 @@ public class StorageProxy implements StorageProxyMBean
MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
try
{
-mbs.registerMBean(new StorageProxy(), new
ObjectName(org.apache.cassandra.db:type=StorageProxy));
+mbs.registerMBean(new StorageProxy(), new ObjectName(MBEAN_NAME));
}
catch (Exception e)
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b43cc362/src/java/org/apache/cassandra/tools/NodeCmd.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java
b/src/java/org/apache/cassandra/tools/NodeCmd.java
index d0ec068..4d2790d 100644
--- a/src/java/org/apache/cassandra/tools/NodeCmd.java
+++ b/src/java/org/apache/cassandra/tools/NodeCmd.java
@@ -33,6 +33,7 @@ import java.util.Map.Entry;
import java.util.concurrent.ExecutionException;
import org.apache.cassandra.service.CacheServiceMBean;
+import org.apache.cassandra.service.StorageProxyMBean;
import org.apache.commons.cli.*;
import org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutorMBean;
@@ -107,6 +108,7 @@ public class NodeCmd
JOIN,
MOVE,
NETSTATS,
+PROXYHISTOGRAMS,
REBUILD,
REFRESH,
REMOVETOKEN,
@@ -145,6 +147,7 @@ public class NodeCmd
addCmdHelp(header, cfstats, Print statistics on column families);
addCmdHelp(header, version, Print cassandra version);
addCmdHelp(header, tpstats, Print usage statistics of thread
pools);
+addCmdHelp(header, proxyhistograms, Print statistic histograms for
network operations);
addCmdHelp(header, drain, Drain the node (stop accepting writes and
flush all column families));
addCmdHelp(header, decommission, Decommission the *node I am
connecting to*);
addCmdHelp(header, compactionstats, Print statistics on
compactions);
@@ -600,14 +603,35 @@ public class NodeCmd
{
output.println(String.format(%-10d%10s%18s%18s%18s%18s,
offsets[i],
- (i sprh.length ? sprh[i] : ),
- (i rwlh.length ? rwlh[i] : ),
- (i rrlh.length ? rrlh[i] : ),
- (i ersh.length ? ersh[i] : ),
- (i ecch.length ? ecch[i] : )));
+ (i sprh.length ? sprh[i] : 0),
+ (i rwlh.length ? rwlh[i] : 0),
+ (i rrlh.length ? rrlh[i] : 0),
+ (i ersh.length ? ersh[i] : 0),
+ (i ecch.length ? ecch[i] : 0)));
}
}
+private void printProxyHistograms(PrintStream output)
+{
+
[jira] [Updated] (CASSANDRA-4384) HintedHandoff can begin before SS knows the hostID
[
https://issues.apache.org/jira/browse/CASSANDRA-4384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-4384:
Attachment: 4384.txt
Not sure where we stand on the schema changes, but we can trivially prevent
this exception by checking the gossiper instead of SS now.
HintedHandoff can begin before SS knows the hostID
--
Key: CASSANDRA-4384
URL: https://issues.apache.org/jira/browse/CASSANDRA-4384
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Assignee: Eric Evans
Fix For: 1.2.0
Attachments: 4384.txt
Since HH fires from the FD, SS won't quite have the hostId yet:
{noformat}
INFO 18:58:04,196 Started hinted handoff for host: null with IP:
/10.179.65.102
INFO 18:58:04,197 Node /10.179.65.102 state jump to normal
ERROR 18:58:04,197 Exception in thread Thread[HintedHandoff:1,1,main]
java.lang.NullPointerException
at org.apache.cassandra.utils.UUIDGen.decompose(UUIDGen.java:120)
at
org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:304)
at
org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:250)
at
org.apache.cassandra.db.HintedHandOffManager.access$400(HintedHandOffManager.java:87)
at
org.apache.cassandra.db.HintedHandOffManager$4.runMayThrow(HintedHandOffManager.java:433)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:26)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{noformat}
Simple solution seems to be getting the hostId from gossip instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4685) scrubbing the system keyspace fails on peers and schema
Brandon Williams created CASSANDRA-4685:
---
Summary: scrubbing the system keyspace fails on peers and schema
Key: CASSANDRA-4685
URL: https://issues.apache.org/jira/browse/CASSANDRA-4685
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Fix For: 1.2.0
{noformat}
INFO 12:20:42,822 Scrubbing
SSTableReader(path='/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ia-1-Data.db')
WARN 12:20:42,826 Non-fatal error reading row (stacktrace follows)
java.lang.RuntimeException: Error validating row
DecoratedKey(61935297886570031978600740763604084078, 4b6579737061636531)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:244)
at
org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:111)
at
org.apache.cassandra.db.compaction.PrecompactedRow.init(PrecompactedRow.java:95)
at
org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:151)
at
org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:157)
at org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:173)
at
org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:495)
at
org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:484)
at
org.apache.cassandra.db.compaction.CompactionManager.access$300(CompactionManager.java:66)
at
org.apache.cassandra.db.compaction.CompactionManager$3.perform(CompactionManager.java:223)
at
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:193)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.cassandra.db.marshal.MarshalException: String didn't
validate.
at org.apache.cassandra.db.marshal.UTF8Type.validate(UTF8Type.java:65)
at org.apache.cassandra.db.Column.validateFields(Column.java:287)
at
org.apache.cassandra.db.ColumnFamily.validateColumnFields(ColumnFamily.java:378)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:240)
... 15 more
WARN 12:20:42,826 Row at 19 is unreadable; skipping to next
WARN 12:20:42,827 No valid rows found while scrubbing
SSTableReader(path='/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ia-1-Data.db');
it is marked for deletion now. If you want to attempt manual recovery, you can
find a copy in the pre-scrub snapshot
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4686) update hadoop version in wordcount exampe
Philip Crotwell created CASSANDRA-4686: -- Summary: update hadoop version in wordcount exampe Key: CASSANDRA-4686 URL: https://issues.apache.org/jira/browse/CASSANDRA-4686 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.5 Reporter: Philip Crotwell Priority: Trivial example/hadoop_word_count uses Hadoop 0.20.2, should use most recent stable version of hadoop, 1.0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4686) update hadoop version in wordcount exampe
[ https://issues.apache.org/jira/browse/CASSANDRA-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Crotwell updated CASSANDRA-4686: --- Comment: was deleted (was: updates ivy.xml in word count example to hadoop 1.0.3) update hadoop version in wordcount exampe - Key: CASSANDRA-4686 URL: https://issues.apache.org/jira/browse/CASSANDRA-4686 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.5 Reporter: Philip Crotwell Priority: Trivial Labels: patch Attachments: trunk-4686.txt example/hadoop_word_count uses Hadoop 0.20.2, should use most recent stable version of hadoop, 1.0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4686) update hadoop version in wordcount exampe
[ https://issues.apache.org/jira/browse/CASSANDRA-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Crotwell updated CASSANDRA-4686: --- Attachment: trunk-4686.txt patch update hadoop version in wordcount exampe - Key: CASSANDRA-4686 URL: https://issues.apache.org/jira/browse/CASSANDRA-4686 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.5 Reporter: Philip Crotwell Priority: Trivial Labels: patch Attachments: trunk-4686.txt example/hadoop_word_count uses Hadoop 0.20.2, should use most recent stable version of hadoop, 1.0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
Leonid Shalupov created CASSANDRA-4687:
--
Summary: Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz,
kkk)
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Priority: Critical
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4686) update hadoop version in wordcount exampe
[ https://issues.apache.org/jira/browse/CASSANDRA-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4686: Labels: (was: patch) update hadoop version in wordcount exampe - Key: CASSANDRA-4686 URL: https://issues.apache.org/jira/browse/CASSANDRA-4686 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.5 Reporter: Philip Crotwell Priority: Trivial Attachments: trunk-4686.txt example/hadoop_word_count uses Hadoop 0.20.2, should use most recent stable version of hadoop, 1.0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4688) comments and error messages use wrong method names
Philip Crotwell created CASSANDRA-4688: -- Summary: comments and error messages use wrong method names Key: CASSANDRA-4688 URL: https://issues.apache.org/jira/browse/CASSANDRA-4688 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.5 Reporter: Philip Crotwell Priority: Minor comments and error messages in ColumnFamilyInputFormat do not reflect the actual method names in ConfigHelper -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4688) comments and error messages use wrong method names
[ https://issues.apache.org/jira/browse/CASSANDRA-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Crotwell updated CASSANDRA-4688: --- Attachment: trunk-4688.txt patch comments and error messages use wrong method names -- Key: CASSANDRA-4688 URL: https://issues.apache.org/jira/browse/CASSANDRA-4688 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.5 Reporter: Philip Crotwell Priority: Minor Attachments: trunk-4688.txt comments and error messages in ColumnFamilyInputFormat do not reflect the actual method names in ConfigHelper -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4464) expose 2I CFs to the rest of nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4464: Attachment: 4464.txt Patch uses the dot notation method, however it doesn't work for scrub because there are a bunch of assertions and throws that have to be removed to even get scrub to run on a 2I, and I'm not certain it will even do the right thing if you do. It's made worse by that fact that if you miss removing one of these, the whole cf gets thrown away. Other operations (including useless ones like flush and snapshot) do work, however. expose 2I CFs to the rest of nodetool - Key: CASSANDRA-4464 URL: https://issues.apache.org/jira/browse/CASSANDRA-4464 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Minor Fix For: 1.1.6 Attachments: 4464.txt This was begun in CASSANDRA-4063. We should extend it to scrub as well, and probably compact since any sane way to do it for scrub should give the other for free. Not sure how easy these will be since they go through CompactionManager via StorageProxy. I think getValidColumnFamilies could be updated to check for index CFs with dot notation. (Other operations like flush or snapshot don't make sense for 2I CFs in isolation of their parent.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kibirev updated CASSANDRA-4681:
Attachment: SlabAllocator.java.list
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java, SlabAllocator.java.list
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4689) Log error when using IN together with ORDER BY
Tyler Patterson created CASSANDRA-4689:
--
Summary: Log error when using IN together with ORDER BY
Key: CASSANDRA-4689
URL: https://issues.apache.org/jira/browse/CASSANDRA-4689
Project: Cassandra
Issue Type: Bug
Environment: built from source on cassandra-1.1
(b43cc362aa568a46bc53e545c68518b0bd350b76)
os: ubuntu
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
{code}
$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.32.0]
Use HELP for help.
cqlsh use ks;
cqlsh:ks drop TABLE test;
cqlsh:ks CREATE TABLE test (my_id varchar, time_id uuid, value int, PRIMARY
KEY (my_id, time_id));
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key1', 1, 1);
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key2', 2, 2);
cqlsh:ks select * from test where my_id in('key1', 'key2') order by time_id;
TSocket read 0 bytes
{code}
The log shows this:
{code}
ERROR [Thrift:5] 2012-09-19 08:44:59,859 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.IllegalArgumentException: Column time_id wasn't found in select
clause.
at
org.apache.cassandra.cql3.statements.SelectStatement.getColumnPositionInSelect(SelectStatement.java:866)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:836)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:807)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1242)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
NOTE: This issue appears similar to
https://issues.apache.org/jira/browse/CASSANDRA-4612 from the user perspective,
even though 4612 was verified as fixed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458737#comment-13458737
]
Oleg Kibirev commented on CASSANDRA-4681:
-
I have also prototyped the newly attached version that keeps a list of extra
slabs in the event of a race condition, however it's throughput and GC
performance are inferior to the simpler fix, at least in my benchmark.
I don't think allocating separate blocks only in the event of a race condition
defeats the purpose of SlabAllocator. Either race condition is rare and
impact on GC is minimum - after all there are many other objects of different
size, including an instance of ByteBuffer per call, that are allocated in
addition to slabs. Or the node is so congested that race condition is the
default case, in which case no solution, but especially not while (!done)
Thread.yield() is likely to produce good results.
It is of course entirely possible that the .list version performs better in a
different benchmark.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java, SlabAllocator.java.list
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458746#comment-13458746 ] David Alves commented on CASSANDRA-4584: bq. But honestly I'm not sure there is a point in disallowing tracing for some query, especially since that's more work than doing it for all queries. Besides, for any query it could be interesting to know how long it took to parse it, to validate it and to execute it. I see no reason why tracing should not be enabled for schema querying/altering statements, but since trace is keyword we only know wether to trace *after* we parse the query, which will make it difficult to track parse times. Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4584: --- Attachment: 4584.patch moves enabling tracing into queryprocessor, still missing uuid pretty printing in cqlsh. Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch, 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4380) CQLSH: describe command doesn't output valid CQL command.
[
https://issues.apache.org/jira/browse/CASSANDRA-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458777#comment-13458777
]
Michael Dyrby Jensen commented on CASSANDRA-4380:
-
Using CQL3, how are you now expected to create a column family like:
CREATE TABLE UserProducts
(
userId uuid PRIMARY KEY
);
Where I would then dynamically add the product ids in the column name for each
product, and leaving the column value null for each. The type of the product id
is uuid.
When I try to create this column family I am told: No definition found that is
not part of the PRIMARY KEY
Any help is greatly appreciated.
CQLSH: describe command doesn't output valid CQL command.
-
Key: CASSANDRA-4380
URL: https://issues.apache.org/jira/browse/CASSANDRA-4380
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.1.3
{noformat}
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=blob AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
I can create a cf in cql3 and then use describe cf to get the above output.
However trying to run that create statement says that all of the following
are invalid options:
* default_validation
* min_compaction_threshold
* max_compaction_threshold
* comparator
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4380) CQLSH: describe command doesn't output valid CQL command.
[
https://issues.apache.org/jira/browse/CASSANDRA-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458777#comment-13458777
]
Michael Dyrby Jensen edited comment on CASSANDRA-4380 at 9/20/12 2:59 AM:
--
Using CQL3, how are you now expected to create a column family like:
CREATE TABLE UserProducts
(
userId uuid PRIMARY KEY
);
Where I would then dynamically add the product ids in the column name for each
product, and leaving the column value null for each. The type of the product id
is uuid.
When I try to create this column family I am told: No definition found that is
not part of the PRIMARY KEY
Any help is greatly appreciated.
It works with CQL2, so is it a bug that CQL3 cannot?
was (Author: dyrby76):
Using CQL3, how are you now expected to create a column family like:
CREATE TABLE UserProducts
(
userId uuid PRIMARY KEY
);
Where I would then dynamically add the product ids in the column name for each
product, and leaving the column value null for each. The type of the product id
is uuid.
When I try to create this column family I am told: No definition found that is
not part of the PRIMARY KEY
Any help is greatly appreciated.
CQLSH: describe command doesn't output valid CQL command.
-
Key: CASSANDRA-4380
URL: https://issues.apache.org/jira/browse/CASSANDRA-4380
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.1.3
{noformat}
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=blob AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
I can create a cf in cql3 and then use describe cf to get the above output.
However trying to run that create statement says that all of the following
are invalid options:
* default_validation
* min_compaction_threshold
* max_compaction_threshold
* comparator
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[3/3] git commit: update nodetool ring description patch by Alexey Zotov; reviewed by jbellis for CASSANDRA-4677
update nodetool ring description patch by Alexey Zotov; reviewed by jbellis for CASSANDRA-4677 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c565b64f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c565b64f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c565b64f Branch: refs/heads/cassandra-1.1 Commit: c565b64fe1566ed29a260ca0ff0b777ed533c717 Parents: b43cc36 Author: Jonathan Ellis jbel...@apache.org Authored: Wed Sep 19 11:08:22 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Sep 19 11:08:31 2012 -0500 -- src/java/org/apache/cassandra/tools/NodeCmd.java |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c565b64f/src/java/org/apache/cassandra/tools/NodeCmd.java -- diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java b/src/java/org/apache/cassandra/tools/NodeCmd.java index 4d2790d..3f8e942 100644 --- a/src/java/org/apache/cassandra/tools/NodeCmd.java +++ b/src/java/org/apache/cassandra/tools/NodeCmd.java @@ -141,7 +141,6 @@ public class NodeCmd StringBuilder header = new StringBuilder(); header.append(\nAvailable commands:\n); // No args -addCmdHelp(header, ring, Print information about the token ring); addCmdHelp(header, join, Join the ring); addCmdHelp(header, info, Print node information (uptime, load, ...)); addCmdHelp(header, cfstats, Print statistics on column families); @@ -162,6 +161,7 @@ public class NodeCmd addCmdHelp(header, resetlocalschema, Reset node's local schema and resync); // One arg +addCmdHelp(header, ring [keyspace], Print information about the token ring for a given keyspace (for all keyspaces if it is not specified)); addCmdHelp(header, netstats [host], Print network information on provided host (connecting node by default)); addCmdHelp(header, move new token, Move node on the token ring to a new token); addCmdHelp(header, removetoken status|force|token, Show status of current token removal, force completion of pending removal or remove providen token);
[2/3] git commit: update nodetool ring description patch by Alexey Zotov; reviewed by jbellis for CASSANDRA-4677
update nodetool ring description patch by Alexey Zotov; reviewed by jbellis for CASSANDRA-4677 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c565b64f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c565b64f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c565b64f Branch: refs/heads/trunk Commit: c565b64fe1566ed29a260ca0ff0b777ed533c717 Parents: b43cc36 Author: Jonathan Ellis jbel...@apache.org Authored: Wed Sep 19 11:08:22 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Sep 19 11:08:31 2012 -0500 -- src/java/org/apache/cassandra/tools/NodeCmd.java |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c565b64f/src/java/org/apache/cassandra/tools/NodeCmd.java -- diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java b/src/java/org/apache/cassandra/tools/NodeCmd.java index 4d2790d..3f8e942 100644 --- a/src/java/org/apache/cassandra/tools/NodeCmd.java +++ b/src/java/org/apache/cassandra/tools/NodeCmd.java @@ -141,7 +141,6 @@ public class NodeCmd StringBuilder header = new StringBuilder(); header.append(\nAvailable commands:\n); // No args -addCmdHelp(header, ring, Print information about the token ring); addCmdHelp(header, join, Join the ring); addCmdHelp(header, info, Print node information (uptime, load, ...)); addCmdHelp(header, cfstats, Print statistics on column families); @@ -162,6 +161,7 @@ public class NodeCmd addCmdHelp(header, resetlocalschema, Reset node's local schema and resync); // One arg +addCmdHelp(header, ring [keyspace], Print information about the token ring for a given keyspace (for all keyspaces if it is not specified)); addCmdHelp(header, netstats [host], Print network information on provided host (connecting node by default)); addCmdHelp(header, move new token, Move node on the token ring to a new token); addCmdHelp(header, removetoken status|force|token, Show status of current token removal, force completion of pending removal or remove providen token);
[1/3] git commit: merge from 1.1
Updated Branches:
refs/heads/cassandra-1.1 b43cc362a - c565b64fe
refs/heads/trunk 96a46771b - 4c1b11bc3
merge from 1.1
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4c1b11bc
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4c1b11bc
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4c1b11bc
Branch: refs/heads/trunk
Commit: 4c1b11bc35ed8770076742ad27e8374418e9970e
Parents: 96a4677 c565b64
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Sep 19 11:10:39 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Sep 19 11:10:39 2012 -0500
--
src/java/org/apache/cassandra/tools/NodeCmd.java | 611 +
1 files changed, 183 insertions(+), 428 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4c1b11bc/src/java/org/apache/cassandra/tools/NodeCmd.java
--
diff --cc src/java/org/apache/cassandra/tools/NodeCmd.java
index 5f2ac12,3f8e942..4d2790d
--- a/src/java/org/apache/cassandra/tools/NodeCmd.java
+++ b/src/java/org/apache/cassandra/tools/NodeCmd.java
@@@ -162,11 -138,63 +138,63 @@@ public class NodeCm
private static void printUsage()
{
HelpFormatter hf = new HelpFormatter();
- StringBuilder header = new StringBuilder(512);
- header.append(\nAvailable commands\n);
- final NodeToolHelp ntHelp = loadHelp();
- for(NodeToolHelp.NodeToolCommand cmd : ntHelp.commands)
- addCmdHelp(header, cmd);
+ StringBuilder header = new StringBuilder();
+ header.append(\nAvailable commands:\n);
+ // No args
++addCmdHelp(header, ring, Print information about the token ring);
+ addCmdHelp(header, join, Join the ring);
+ addCmdHelp(header, info, Print node information (uptime, load,
...));
+ addCmdHelp(header, cfstats, Print statistics on column families);
+ addCmdHelp(header, version, Print cassandra version);
+ addCmdHelp(header, tpstats, Print usage statistics of thread
pools);
+ addCmdHelp(header, proxyhistograms, Print statistic histograms for
network operations);
+ addCmdHelp(header, drain, Drain the node (stop accepting writes
and flush all column families));
+ addCmdHelp(header, decommission, Decommission the *node I am
connecting to*);
+ addCmdHelp(header, compactionstats, Print statistics on
compactions);
+ addCmdHelp(header, disablegossip, Disable gossip (effectively
marking the node dead));
+ addCmdHelp(header, enablegossip, Reenable gossip);
+ addCmdHelp(header, disablethrift, Disable thrift server);
+ addCmdHelp(header, enablethrift, Reenable thrift server);
+ addCmdHelp(header, statusthrift, Status of thrift server);
+ addCmdHelp(header, gossipinfo, Shows the gossip information for
the cluster);
+ addCmdHelp(header, invalidatekeycache, Invalidate the key cache);
+ addCmdHelp(header, invalidaterowcache, Invalidate the row cache);
+ addCmdHelp(header, resetlocalschema, Reset node's local schema and
resync);
+
+ // One arg
-addCmdHelp(header, ring [keyspace], Print information about the
token ring for a given keyspace (for all keyspaces if it is not specified));
+ addCmdHelp(header, netstats [host], Print network information on
provided host (connecting node by default));
+ addCmdHelp(header, move new token, Move node on the token ring
to a new token);
+ addCmdHelp(header, removetoken status|force|token, Show status
of current token removal, force completion of pending removal or remove
providen token);
+ addCmdHelp(header, setcompactionthroughput value_in_mb, Set the
MB/s throughput cap for compaction in the system, or 0 to disable throttling.);
+ addCmdHelp(header, setstreamthroughput value_in_mb, Set the MB/s
throughput cap for streaming in the system, or 0 to disable throttling.);
+ addCmdHelp(header, describering [keyspace], Shows the token ranges
info of a given keyspace.);
+ addCmdHelp(header, rangekeysample, Shows the sampled keys held
across all keyspaces.);
+ addCmdHelp(header, rebuild [src-dc-name], Rebuild data by
streaming from other nodes (similarly to bootstrap));
+
+ // Two args
+ addCmdHelp(header, snapshot [keyspaces...] -cf [columnfamilyName] -t
[snapshotName], Take a snapshot of the optionally specified column family of
the specified keyspaces using optional name snapshotName);
+ addCmdHelp(header, clearsnapshot [keyspaces...] -t [snapshotName],
Remove snapshots for the specified keyspaces. Either remove all snapshots or
remove the snapshots with the given name.);
+
[jira] [Commented] (CASSANDRA-4682) simple scripting bug in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458790#comment-13458790 ] Yang Yang commented on CASSANDRA-4682: -- https://github.com/apache/cassandra/blame/cassandra-1.1.0/conf/cassandra-env.sh it's in 1.1.0 branch, but not trunk, it's also present in 1.1.2 release simple scripting bug in cassandra-env.sh Key: CASSANDRA-4682 URL: https://issues.apache.org/jira/browse/CASSANDRA-4682 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Priority: Minor the case clause contains break, which is syntactically wrong. generally it does not show up in command line since the stderr and stdout is redirected -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4683) running nodetool cleanup throws an exception
[ https://issues.apache.org/jira/browse/CASSANDRA-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4683. --- Resolution: Duplicate in 1.1.2 the assertion in getCurrentLocalNodeId is on line 444, in 1.1.3 and 1.1.4 it's on 461. So... probably on 1.1.4? In any case, resolving as duplicate, solution is to upgrade to real 1.1.5. running nodetool cleanup throws an exception Key: CASSANDRA-4683 URL: https://issues.apache.org/jira/browse/CASSANDRA-4683 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Reporter: Bartłomiej Romański We've just upgraded to 1.1.5 from 1.1.2. After that running nodetool cleanup we've got the following error: Exception in thread main java.lang.AssertionError at org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:462) at org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.init(NodeId.java:195) at org.apache.cassandra.utils.NodeId$LocalIds.clinit(NodeId.java:43) at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:50) at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:55) at org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:175) at org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1769) 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:1447) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:89) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1292) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1380) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:812) 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at sun.rmi.transport.Transport$1.run(Transport.java:174) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Any ideas? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4584: --- Attachment: 4584.patch reverted changes to cqlsh as those go into CASSANDRA-4585 Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch, 4584.patch, 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4643) AssertionError: DecoratedKey(-1, ) != DecoratedKey
[ https://issues.apache.org/jira/browse/CASSANDRA-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4643. --- Resolution: Duplicate Looks like the same thing as CASSANDRA-4687; Leonid has a bisect culprit over there, so we'll start digging with that AssertionError: DecoratedKey(-1, ) != DecoratedKey -- Key: CASSANDRA-4643 URL: https://issues.apache.org/jira/browse/CASSANDRA-4643 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.5 Reporter: Radim Kolar i got lot of following errors: decorated key -1 != some number INFO [CompactionExecutor:10] 2012-09-11 02:22:13,586 CompactionController.java (line 172) Compacting large row system/HintsColumnFamily:67fd0f04ca3294558142a5b33a30f6f5 (241502947 bytes) incrementally ERROR [ReadStage:44] 2012-09-11 02:22:13,992 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[ReadStage:44,5,main] java.lang.AssertionError: DecoratedKey(-1, ) != DecoratedKey(133375303318769338050543368330356089660, ad4f) in c:\cassandra\data\test\sipdb\test-sipdb-he-5-Data.db at org.apache.cassandra.db.columniterator.SSTableNamesIterator.init(SSTableNamesIterator.java:72) at org.apache.cassandra.db.filter.NamesQueryFilter.getSSTableColumnIterator(NamesQueryFilter.java:61) at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79) at org.apache.cassandra.db.CollationController.collectTimeOrderedData(CollationController.java:124) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458806#comment-13458806 ] David Alves commented on CASSANDRA-4584: moving cqlsh to another issue makes this one pretty much done (before review that is) Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4584.patch, 4584.patch, 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4686) update hadoop version in wordcount exampe
[ https://issues.apache.org/jira/browse/CASSANDRA-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4686: -- Reviewer: jeromatron Affects Version/s: (was: 1.1.5) Fix Version/s: 1.2.0 beta 2 update hadoop version in wordcount exampe - Key: CASSANDRA-4686 URL: https://issues.apache.org/jira/browse/CASSANDRA-4686 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Philip Crotwell Priority: Trivial Fix For: 1.2.0 beta 2 Attachments: trunk-4686.txt example/hadoop_word_count uses Hadoop 0.20.2, should use most recent stable version of hadoop, 1.0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4585) Add cqlsh support for tracing results
[ https://issues.apache.org/jira/browse/CASSANDRA-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4585: --- Attachment: 4585.patch requires http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=24 to go in. just missing pretty printing the uuid. Add cqlsh support for tracing results - Key: CASSANDRA-4585 URL: https://issues.apache.org/jira/browse/CASSANDRA-4585 Project: Cassandra Issue Type: Sub-task Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.0 Attachments: 4585.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4683) running nodetool cleanup throws an exception
[ https://issues.apache.org/jira/browse/CASSANDRA-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458808#comment-13458808 ] Bartłomiej Romański commented on CASSANDRA-4683: This is 1.1.5 node! br@b5:~$ cassandra -v xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms12G -Xmx12G -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss160k 1.1.5 br@b5:~$ nodetool cleanup Exception in thread main java.lang.NoClassDefFoundError: Could not initialize class org.apache.cassandra.utils.NodeId$LocalIds at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:50) at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:55) at org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:175) at org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1769) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) The node has been rebooted after upgrade so I'm pretty sure that the running process is also 1.1.5. Is there a way (eg. JMX or nodetool) to query live instance about it's version? running nodetool cleanup throws an exception Key: CASSANDRA-4683 URL: https://issues.apache.org/jira/browse/CASSANDRA-4683 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Reporter: Bartłomiej Romański We've just upgraded to 1.1.5 from 1.1.2. After that running nodetool cleanup we've got the following error: Exception in thread main java.lang.AssertionError at org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:462) at org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.init(NodeId.java:195) at org.apache.cassandra.utils.NodeId$LocalIds.clinit(NodeId.java:43) at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:50) at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:55) at org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:175) at org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1769) 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:1447) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:89) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1292) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1380) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:812) 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at sun.rmi.transport.Transport$1.run(Transport.java:174) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at
[jira] [Updated] (CASSANDRA-4689) Log error when using IN together with ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4689:
--
Assignee: Sylvain Lebresne (was: Pavel Yaskevich)
Log error when using IN together with ORDER BY
--
Key: CASSANDRA-4689
URL: https://issues.apache.org/jira/browse/CASSANDRA-4689
Project: Cassandra
Issue Type: Bug
Environment: built from source on cassandra-1.1
(b43cc362aa568a46bc53e545c68518b0bd350b76)
os: ubuntu
Reporter: Tyler Patterson
Assignee: Sylvain Lebresne
{code}
$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.32.0]
Use HELP for help.
cqlsh use ks;
cqlsh:ks drop TABLE test;
cqlsh:ks CREATE TABLE test (my_id varchar, time_id uuid, value int, PRIMARY
KEY (my_id, time_id));
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key1', 1, 1);
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key2', 2, 2);
cqlsh:ks select * from test where my_id in('key1', 'key2') order by time_id;
TSocket read 0 bytes
{code}
The log shows this:
{code}
ERROR [Thrift:5] 2012-09-19 08:44:59,859 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.IllegalArgumentException: Column time_id wasn't found in select
clause.
at
org.apache.cassandra.cql3.statements.SelectStatement.getColumnPositionInSelect(SelectStatement.java:866)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:836)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:807)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1242)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
NOTE: This issue appears similar to
https://issues.apache.org/jira/browse/CASSANDRA-4612 from the user
perspective, even though 4612 was verified as fixed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458811#comment-13458811
]
Jonathan Ellis commented on CASSANDRA-4681:
---
If you're seeing 4x performance, that doesn't sound very rare to me.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java, SlabAllocator.java.list
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4380) CQLSH: describe command doesn't output valid CQL command.
[
https://issues.apache.org/jira/browse/CASSANDRA-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458814#comment-13458814
]
Jonathan Ellis commented on CASSANDRA-4380:
---
CREATE TABLE UserProducts (
user_id uuid,
product_id uuid,
PRIMARY KEY (user_id, product_id)
);
More details at http://www.datastax.com/dev/blog/schema-in-cassandra-1-1.
Let's take any further discussion on usage to the mailing list. Thanks!
CQLSH: describe command doesn't output valid CQL command.
-
Key: CASSANDRA-4380
URL: https://issues.apache.org/jira/browse/CASSANDRA-4380
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.1.3
{noformat}
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=blob AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
I can create a cf in cql3 and then use describe cf to get the above output.
However trying to run that create statement says that all of the following
are invalid options:
* default_validation
* min_compaction_threshold
* max_compaction_threshold
* comparator
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4682) simple scripting bug in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4682. --- Resolution: Invalid then it's been addressed post-1.1.2 simple scripting bug in cassandra-env.sh Key: CASSANDRA-4682 URL: https://issues.apache.org/jira/browse/CASSANDRA-4682 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Priority: Minor the case clause contains break, which is syntactically wrong. generally it does not show up in command line since the stderr and stdout is redirected -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4683) running nodetool cleanup throws an exception
[
https://issues.apache.org/jira/browse/CASSANDRA-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458820#comment-13458820
]
Jonathan Ellis commented on CASSANDRA-4683:
---
You're probably the victim of some classpath confusion.
Cassandra logs version on startup, e.g.
{noformat}
INFO [main] 2012-05-01 13:17:25,348 StorageService.java (line 422) Cassandra
version: 1.1.0-SNAPSHOT
{noformat}
running nodetool cleanup throws an exception
Key: CASSANDRA-4683
URL: https://issues.apache.org/jira/browse/CASSANDRA-4683
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.5
Reporter: Bartłomiej Romański
We've just upgraded to 1.1.5 from 1.1.2.
After that running nodetool cleanup we've got the following error:
Exception in thread main java.lang.AssertionError
at
org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:462)
at
org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.init(NodeId.java:195)
at org.apache.cassandra.utils.NodeId$LocalIds.clinit(NodeId.java:43)
at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:50)
at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:55)
at
org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:175)
at
org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1769)
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:1447)
at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:89)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1292)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1380)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:812)
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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Any ideas?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458821#comment-13458821
]
Oleg Kibirev commented on CASSANDRA-4681:
-
So in this case the list version should be good? It triggered more full GCs
than simple version in my benchmark, perhaps because the threads were delayed
by more complex code/allocating a bigger block from completing activity that
would have otherwise released some memory.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java, SlabAllocator.java.list
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458821#comment-13458821
]
Oleg Kibirev edited comment on CASSANDRA-4681 at 9/20/12 3:33 AM:
--
So in this case the list version should be good? It triggered more full GCs
than simple version in my benchmark, perhaps because the threads were delayed
by more complex code/allocating a bigger block from completing activity that
would have otherwise released some memory. But things could certainly be
different in another benchmark
was (Author: okibirev):
So in this case the list version should be good? It triggered more full GCs
than simple version in my benchmark, perhaps because the threads were delayed
by more complex code/allocating a bigger block from completing activity that
would have otherwise released some memory.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java, SlabAllocator.java.list
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4585) Add cqlsh support for tracing results
[ https://issues.apache.org/jira/browse/CASSANDRA-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458824#comment-13458824 ] Jonathan Ellis commented on CASSANDRA-4585: --- Does that mean you're planning to add pretty printing, or that it's enough of a pain that you recommend not bothering with for now? Add cqlsh support for tracing results - Key: CASSANDRA-4585 URL: https://issues.apache.org/jira/browse/CASSANDRA-4585 Project: Cassandra Issue Type: Sub-task Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4585.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4585) Add cqlsh support for tracing results
[ https://issues.apache.org/jira/browse/CASSANDRA-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4585: -- Assignee: David Alves (was: Aleksey Yeschenko) Add cqlsh support for tracing results - Key: CASSANDRA-4585 URL: https://issues.apache.org/jira/browse/CASSANDRA-4585 Project: Cassandra Issue Type: Sub-task Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4585.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4690) Delete only workload OOM cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4690. --- Resolution: Duplicate see CASSANDRA-3741 Delete only workload OOM cassandra -- Key: CASSANDRA-4690 URL: https://issues.apache.org/jira/browse/CASSANDRA-4690 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.11 Environment: OpenJDK 6 Reporter: Radim Kolar Priority: Blocker Restart cassandra node and run delete only workload against CF. No other update operations like insert or delete are used against that CF. Cassandra do not counts deletes in serialized/live bytes. It counts them just as ops. After some time cassandra will run almost out of Java heap space and tries to do emergency flush, which will not be done at CF with deletes because cassandra thinks that it has 0 live bytes. This will result in OOM after while, but usually cassandra just hangs. To make this workload finish, you have to issue periodic nodetool flush commands. Their flueshes on that CF looks: INFO [RMI TCP Connection(69)-64.6.108.239] 2012-09-19 18:22:46,366 ColumnFamilyStore.java (line 705) Enqueuing flush of Memtable-sipdb@359811109(0/0 serialized/live bytes, 688056 ops) INFO [FlushWriter:13] 2012-09-19 18:22:46,366 Memtable.java (line 246) Writing Memtable-sipdb@359811109(0/0 serialized/live bytes, 688056 ops) INFO [FlushWriter:13] 2012-09-19 18:22:49,719 Memtable.java (line 283) Completed flushing /var/lib/cassandra/data/test/sipdb-hd-4726-Data.db (37155024 bytes) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458828#comment-13458828
]
Jonathan Ellis commented on CASSANDRA-4681:
---
Not sure:
{noformat}
$ patch -p1 SlabAllocator.java.list
patch: Only garbage was found in the patch input.
{noformat}
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java, SlabAllocator.java.list
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4584: -- Reviewer: slebresne (was: xedin) Fix Version/s: (was: 1.2.0) 1.2.0 beta 2 Labels: cql3 (was: ) Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Labels: cql3 Fix For: 1.2.0 beta 2 Attachments: 4584.patch, 4584.patch, 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4585) Add cqlsh support for tracing results
[ https://issues.apache.org/jira/browse/CASSANDRA-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458830#comment-13458830 ] David Alves commented on CASSANDRA-4585: we need it to be able to query the trace tables so i'm planning on adding it, just need some more time Add cqlsh support for tracing results - Key: CASSANDRA-4585 URL: https://issues.apache.org/jira/browse/CASSANDRA-4585 Project: Cassandra Issue Type: Sub-task Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4585.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kibirev updated CASSANDRA-4681:
Attachment: slab-list.patch
patch for list-based slab allocator against 1.1.5
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java, SlabAllocator.java.list,
slab-list.patch
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458834#comment-13458834
]
Oleg Kibirev commented on CASSANDRA-4681:
-
This was a complete file for general review and discussion. I have just
uploaded a patch for the same against 1.1.5.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java, SlabAllocator.java.list,
slab-list.patch
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3741) OOMs because delete operations are not accounted
[ https://issues.apache.org/jira/browse/CASSANDRA-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458849#comment-13458849 ] Radim Kolar commented on CASSANDRA-3741: was this backported to cassandra 1.0? OOMs because delete operations are not accounted Key: CASSANDRA-3741 URL: https://issues.apache.org/jira/browse/CASSANDRA-3741 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Assignee: Andriy Kolyadenko Fix For: 1.1.1 Currently we are moving to new data format where new format is written into new CFs and old one is deleted key-by-key. I have started getting OOMs and found out that delete operations are not accounted and so, column families are not flushed (changed == 0 with delete only operations) by storage manager. This is pull request that fixed this problem for me: https://github.com/apache/cassandra/pull/5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4560) Add tracing support for CQL3 bind variables
[ https://issues.apache.org/jira/browse/CASSANDRA-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4560: --- Assignee: David Alves Add tracing support for CQL3 bind variables --- Key: CASSANDRA-4560 URL: https://issues.apache.org/jira/browse/CASSANDRA-4560 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2.1 Attachments: 4560.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4560) Add tracing support for CQL3 bind variables
[ https://issues.apache.org/jira/browse/CASSANDRA-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4560: --- Attachment: 4560.patch simple patch that exposes bound variable names by exposing ParsedStatement.Prepared in ClientState instead of exposing CQLStatement directly. Add tracing support for CQL3 bind variables --- Key: CASSANDRA-4560 URL: https://issues.apache.org/jira/browse/CASSANDRA-4560 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Priority: Minor Fix For: 1.2.1 Attachments: 4560.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3741) OOMs because delete operations are not accounted
[ https://issues.apache.org/jira/browse/CASSANDRA-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458860#comment-13458860 ] Jonathan Ellis commented on CASSANDRA-3741: --- No, this is a sensitive area of the code and we don't want to risk destabilizing it. OOMs because delete operations are not accounted Key: CASSANDRA-3741 URL: https://issues.apache.org/jira/browse/CASSANDRA-3741 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Assignee: Andriy Kolyadenko Fix For: 1.1.1 Currently we are moving to new data format where new format is written into new CFs and old one is deleted key-by-key. I have started getting OOMs and found out that delete operations are not accounted and so, column families are not flushed (changed == 0 with delete only operations) by storage manager. This is pull request that fixed this problem for me: https://github.com/apache/cassandra/pull/5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4689) Log error when using IN together with ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458864#comment-13458864
]
Pavel Yaskevich commented on CASSANDRA-4689:
Jonathan, I can easily handle this one if Sylvain has a lot on his plate.
Log error when using IN together with ORDER BY
--
Key: CASSANDRA-4689
URL: https://issues.apache.org/jira/browse/CASSANDRA-4689
Project: Cassandra
Issue Type: Bug
Environment: built from source on cassandra-1.1
(b43cc362aa568a46bc53e545c68518b0bd350b76)
os: ubuntu
Reporter: Tyler Patterson
Assignee: Sylvain Lebresne
{code}
$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.32.0]
Use HELP for help.
cqlsh use ks;
cqlsh:ks drop TABLE test;
cqlsh:ks CREATE TABLE test (my_id varchar, time_id uuid, value int, PRIMARY
KEY (my_id, time_id));
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key1', 1, 1);
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key2', 2, 2);
cqlsh:ks select * from test where my_id in('key1', 'key2') order by time_id;
TSocket read 0 bytes
{code}
The log shows this:
{code}
ERROR [Thrift:5] 2012-09-19 08:44:59,859 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.IllegalArgumentException: Column time_id wasn't found in select
clause.
at
org.apache.cassandra.cql3.statements.SelectStatement.getColumnPositionInSelect(SelectStatement.java:866)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:836)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:807)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1242)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
NOTE: This issue appears similar to
https://issues.apache.org/jira/browse/CASSANDRA-4612 from the user
perspective, even though 4612 was verified as fixed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4662) Core support for Thrift SSL integration
[
https://issues.apache.org/jira/browse/CASSANDRA-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458869#comment-13458869
]
Vijay commented on CASSANDRA-4662:
--
1) IMO the changes to the configuration needs to be done in the major releases
(changes in encryption option name) so folks will notice NEWS.txt, the default
is none if they dont read news.txt
2) ThriftSSLFactory is not called anywhere, am i missing something here? If we
decide to use ThriftSSLFactory is better served within the o.a.c.thrift (not
sure if we need a seperate class for this though)
3)
{code}
int clientTimeout = 1;
{code}
Should be RPC Timeout, if you look at the thrift source it is client
SoTimeout...
Traditionally we dont set SoTimeout in the server for the client connections
(You might want to follow the same, because the other parts of cassandra will
timeout just after the socket timeout and the client will not receive the
Operation timeout).
4)
{code}
# this client encryption will only apply if you set rpc_server_type = sync.
{code}
Why?
Other concern have is either we support SSL or not, which is kind of hard in
real life there can be clients which might not need encryption enabled, for
unencrypted ports can be easily blocked via firewall.
It will be easier to review if we have stress modified and have an end to end
test setup.
Core support for Thrift SSL integration
---
Key: CASSANDRA-4662
URL: https://issues.apache.org/jira/browse/CASSANDRA-4662
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Jason Brown
Assignee: Jason Brown
Fix For: 1.1.6
Attachments:
0001-CASSANDRA-4662.-Core-work-of-adding-thrift-ssl-suppo.patch
Ticket to separate out the changes to yaml and cassandra/thrift code for the
thrift SSL integration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4585) Add cqlsh support for tracing results
[ https://issues.apache.org/jira/browse/CASSANDRA-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4585: --- Attachment: 4585.patch added pretty printing to the uuid. the result can be used directly to query the sessions/events table. Add cqlsh support for tracing results - Key: CASSANDRA-4585 URL: https://issues.apache.org/jira/browse/CASSANDRA-4585 Project: Cassandra Issue Type: Sub-task Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 4585.patch, 4585.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4681:
--
Attachment: 4681-v3.txt
This doesn't quite do what you want; it just postpones the race until next ==
null. (And the cost of a race is much higher since each Region construction
now includes the full byte[].)
v3 attached to allow just one thread* to continue and allocate next when the
original is exhausted.
*other threads that fail allocation, but check for next != null after a
successful CAS will still race, which is why we need to make .next an
AtomicReference as well.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: 4681-v3.txt, SlabAllocator.java,
SlabAllocator.java.list, slab-list.patch
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458920#comment-13458920
]
Oleg Kibirev commented on CASSANDRA-4681:
-
Jonathan - why is there a race when next is not modified once a region is
inserted into the list? I am either inserting or removing a node into the
linked list and use compareAndSet to make sure the head of the list still has
an expected value.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: 4681-v3.txt, SlabAllocator.java,
SlabAllocator.java.list, slab-list.patch
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458928#comment-13458928
]
Jonathan Ellis commented on CASSANDRA-4681:
---
Suppose current region A is exhausted. A.next = B. All threads race to CAS B
into A, then continue. Now you have current = B and B.next = null. Nobody
will try to allocate B.next until B is exhausted, in which case they will all
create the new Region and CAS again.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: 4681-v3.txt, SlabAllocator.java,
SlabAllocator.java.list, slab-list.patch
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458928#comment-13458928
]
Jonathan Ellis edited comment on CASSANDRA-4681 at 9/20/12 5:27 AM:
Suppose current region A is exhausted. A.next = B. All threads CAS B into A,
then continue. Now you have current = B and B.next = null. Nobody will try to
allocate B.next until B is exhausted, in which case they will all create the
new Region and CAS again.
was (Author: jbellis):
Suppose current region A is exhausted. A.next = B. All threads race to
CAS B into A, then continue. Now you have current = B and B.next = null.
Nobody will try to allocate B.next until B is exhausted, in which case they
will all create the new Region and CAS again.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: 4681-v3.txt, SlabAllocator.java,
SlabAllocator.java.list, slab-list.patch
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3741) OOMs because delete operations are not accounted
[ https://issues.apache.org/jira/browse/CASSANDRA-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458932#comment-13458932 ] Radim Kolar commented on CASSANDRA-3741: 1.0 is already destabilized by this bug. If you want to have minimal effect, then add just 1 byte to live bytes count for every delete. In non delete only workload, it will have minimal effect. Its important to have non zero count otherwise it will not be flushed to disk on memory pressure. OOMs because delete operations are not accounted Key: CASSANDRA-3741 URL: https://issues.apache.org/jira/browse/CASSANDRA-3741 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Assignee: Andriy Kolyadenko Fix For: 1.1.1 Currently we are moving to new data format where new format is written into new CFs and old one is deleted key-by-key. I have started getting OOMs and found out that delete operations are not accounted and so, column families are not flushed (changed == 0 with delete only operations) by storage manager. This is pull request that fixed this problem for me: https://github.com/apache/cassandra/pull/5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458935#comment-13458935
]
Oleg Kibirev commented on CASSANDRA-4681:
-
So they will all create new regions and push them onto the stack. No regions
will be leaked. By definition, there are only 3 alternatives 1. make slab
allocation single-threaded (current approach) 2. allocate non slabbed buffers
if a slab is not ready 3. Allocate multiple slabs in racing threads and make
them available for subsequent use. How does next is atomicreference approach
differ from the original one?
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: 4681-v3.txt, SlabAllocator.java,
SlabAllocator.java.list, slab-list.patch
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4662) Core support for Thrift SSL integration
[ https://issues.apache.org/jira/browse/CASSANDRA-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458940#comment-13458940 ] Jason Brown commented on CASSANDRA-4662: 1) The configuration is backward compatible (you can use the traditional names for the rpc_server_type - sync/async/hsha). However, I do like the notion of using the class name for the value (so you can plug in what variant you wish), and, yes, that would best be left for a major rev rather than a point upgrade. 2) ThriftSSLFactory is actually used in a sister ticket, CASSANDRA-4608 :). The work for the full SSL integration got spread around several tickets; parent ticket is CASSANDRA-4239. I put ThriftSSLFactory in o.a.c.security as it seemed parallel to the existing SSLFactory, but I'm flexible on the package. 3) D'oh! I forgot to remove the hard coded value. Let me fix this one. 4) Good question (which I probably should have answered in the yaml itself): thrift only supports blocking SSL sockets, so I assumed it would only work with the sync rpc_server_type. However, I'll double check to see if it can work with hsha. As for supporting SSL or not, I've made it configurable at the server-side to use it (via the yaml's new client_encryption_options.enabled). I'll take a look at stress, as well, to test this out. Core support for Thrift SSL integration --- Key: CASSANDRA-4662 URL: https://issues.apache.org/jira/browse/CASSANDRA-4662 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jason Brown Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0001-CASSANDRA-4662.-Core-work-of-adding-thrift-ssl-suppo.patch Ticket to separate out the changes to yaml and cassandra/thrift code for the thrift SSL integration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4584: --- Attachment: 4584.patch moved the initial logging of cql queries into QueryProcessor in the cql3 case because sessions were being started before and we needed to log params. Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Labels: cql3 Fix For: 1.2.0 beta 2 Attachments: 4584.patch, 4584.patch, 4584.patch, 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4662) Core support for Thrift SSL integration
[
https://issues.apache.org/jira/browse/CASSANDRA-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458961#comment-13458961
]
Vijay commented on CASSANDRA-4662:
--
{quote}
1) The configuration is backward compatible (you can use the traditional names
for the rpc_server_type - sync/async/hsha).
{quote}
I am talking about rename of encryption_options to server_encryption_options, i
am not sure if we need 2 classes there too :)
{quote}
ThriftSSLFactory is actually used in a sister ticket
{quote}
It is better to merge this effort into the sister ticket then as the sister
ticket by itself will not be useful.
{quote}
thrift only supports blocking SSL sockets
{quote}
take a look at CustomTHsHaServer
Core support for Thrift SSL integration
---
Key: CASSANDRA-4662
URL: https://issues.apache.org/jira/browse/CASSANDRA-4662
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Jason Brown
Assignee: Jason Brown
Fix For: 1.1.6
Attachments:
0001-CASSANDRA-4662.-Core-work-of-adding-thrift-ssl-suppo.patch
Ticket to separate out the changes to yaml and cassandra/thrift code for the
thrift SSL integration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4560) Add tracing support for CQL3 bind variables
[ https://issues.apache.org/jira/browse/CASSANDRA-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4560: --- Attachment: (was: 4560.patch) Add tracing support for CQL3 bind variables --- Key: CASSANDRA-4560 URL: https://issues.apache.org/jira/browse/CASSANDRA-4560 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-4584: --- Attachment: 4584.patch Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Labels: cql3 Fix For: 1.2.0 beta 2 Attachments: 4584.patch, 4584.patch, 4584.patch, 4584.patch, 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4584) Add CQL syntax to enable request tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459019#comment-13459019 ] David Alves edited comment on CASSANDRA-4584 at 9/20/12 6:48 AM: - separated logging for prepared query submission, execution and regular query execution, this pretty much includes CASSANDRA-4560 which is now included in this patch. was (Author: dr-alves): separated logging for prepared query submission, execution and regular query execution, this pretty much includes CASSANDRA-4560 which is not included in this patch. Add CQL syntax to enable request tracing Key: CASSANDRA-4584 URL: https://issues.apache.org/jira/browse/CASSANDRA-4584 Project: Cassandra Issue Type: Sub-task Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: David Alves Labels: cql3 Fix For: 1.2.0 beta 2 Attachments: 4584.patch, 4584.patch, 4584.patch, 4584.patch, 4584.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4560) Add tracing support for CQL3 bind variables
[ https://issues.apache.org/jira/browse/CASSANDRA-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves resolved CASSANDRA-4560. Resolution: Fixed Add tracing support for CQL3 bind variables --- Key: CASSANDRA-4560 URL: https://issues.apache.org/jira/browse/CASSANDRA-4560 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 1.2.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459087#comment-13459087
]
Jonathan Ellis commented on CASSANDRA-4681:
---
What we want is to create a Next with a single thread while everyone else gets
to allocate from old-next and get back to what they were doing.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: 4681-v3.txt, SlabAllocator.java,
SlabAllocator.java.list, slab-list.patch
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Revert merge from 1.1
Updated Branches: refs/heads/trunk 4c1b11bc3 - f31dbee7d Revert merge from 1.1 This reverts commit 4c1b11bc35ed8770076742ad27e8374418e9970e, reversing changes made to 96a46771b287a265a4d9faf61543163e342f6d87. Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f31dbee7 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f31dbee7 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f31dbee7 Branch: refs/heads/trunk Commit: f31dbee7d60c1f8e343ef16c68360af8c9485733 Parents: 4c1b11b Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Sep 19 16:30:52 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Sep 19 16:30:52 2012 -0500 -- src/java/org/apache/cassandra/tools/NodeCmd.java | 611 - 1 files changed, 428 insertions(+), 183 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f31dbee7/src/java/org/apache/cassandra/tools/NodeCmd.java -- diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java b/src/java/org/apache/cassandra/tools/NodeCmd.java index 4d2790d..5f2ac12 100644 --- a/src/java/org/apache/cassandra/tools/NodeCmd.java +++ b/src/java/org/apache/cassandra/tools/NodeCmd.java @@ -1,6 +1,4 @@ -package org.apache.cassandra.tools; /* - * * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information @@ -9,71 +7,94 @@ package org.apache.cassandra.tools; * License); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, - * software distributed under the License is distributed on an - * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - * KIND, either express or implied. See the License for the - * specific language governing permissions and limitations - * under the License. + * http://www.apache.org/licenses/LICENSE-2.0 * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. */ - +package org.apache.cassandra.tools; import java.io.IOException; +import java.io.InputStream; import java.io.PrintStream; import java.lang.management.MemoryUsage; import java.net.ConnectException; import java.net.InetAddress; import java.net.UnknownHostException; import java.text.DecimalFormat; -import java.util.*; +import java.util.ArrayList; +import java.util.Arrays; +import java.util.Collection; +import java.util.HashMap; +import java.util.HashSet; +import java.util.Iterator; +import java.util.LinkedHashMap; +import java.util.List; +import java.util.Map; import java.util.Map.Entry; +import java.util.Set; import java.util.concurrent.ExecutionException; -import org.apache.cassandra.service.CacheServiceMBean; -import org.apache.cassandra.service.StorageProxyMBean; -import org.apache.commons.cli.*; +import com.google.common.collect.LinkedHashMultimap; +import com.google.common.collect.Maps; +import org.apache.commons.cli.CommandLine; +import org.apache.commons.cli.CommandLineParser; +import org.apache.commons.cli.HelpFormatter; +import org.apache.commons.cli.Option; +import org.apache.commons.cli.Options; +import org.apache.commons.cli.ParseException; +import org.apache.commons.cli.PosixParser; import org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutorMBean; -import org.apache.cassandra.config.ConfigurationException; import org.apache.cassandra.db.ColumnFamilyStoreMBean; +import org.apache.cassandra.db.Table; import org.apache.cassandra.db.compaction.CompactionManagerMBean; import org.apache.cassandra.db.compaction.OperationType; +import org.apache.cassandra.exceptions.ConfigurationException; +import org.apache.cassandra.exceptions.InvalidRequestException; +import org.apache.cassandra.io.util.FileUtils; +import org.apache.cassandra.locator.EndpointSnitchInfoMBean; import org.apache.cassandra.net.MessagingServiceMBean; -import org.apache.cassandra.thrift.InvalidRequestException; +import org.apache.cassandra.service.CacheServiceMBean; +import org.apache.cassandra.service.StorageProxyMBean; import org.apache.cassandra.utils.EstimatedHistogram; import org.apache.cassandra.utils.Pair; +import org.yaml.snakeyaml.Loader; +import org.yaml.snakeyaml.TypeDescription; +import org.yaml.snakeyaml.Yaml; +import org.yaml.snakeyaml.constructor.Constructor;
git commit: Cleanup strange import fallout from revert
Updated Branches: refs/heads/trunk f31dbee7d - 0ada18462 Cleanup strange import fallout from revert Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0ada1846 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0ada1846 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0ada1846 Branch: refs/heads/trunk Commit: 0ada184628b4a1c86b35b73c51d9eb9f635f7ca0 Parents: f31dbee Author: Brandon Williams brandonwilli...@apache.org Authored: Wed Sep 19 16:39:06 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Wed Sep 19 16:39:06 2012 -0500 -- src/java/org/apache/cassandra/tools/NodeCmd.java | 21 ++-- 1 files changed, 3 insertions(+), 18 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0ada1846/src/java/org/apache/cassandra/tools/NodeCmd.java -- diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java b/src/java/org/apache/cassandra/tools/NodeCmd.java index 5f2ac12..704be4d 100644 --- a/src/java/org/apache/cassandra/tools/NodeCmd.java +++ b/src/java/org/apache/cassandra/tools/NodeCmd.java @@ -25,28 +25,13 @@ import java.net.ConnectException; import java.net.InetAddress; import java.net.UnknownHostException; import java.text.DecimalFormat; -import java.util.ArrayList; -import java.util.Arrays; -import java.util.Collection; -import java.util.HashMap; -import java.util.HashSet; -import java.util.Iterator; -import java.util.LinkedHashMap; -import java.util.List; -import java.util.Map; -import java.util.Map.Entry; -import java.util.Set; import java.util.concurrent.ExecutionException; +import java.util.Map.Entry; +import java.util.*; import com.google.common.collect.LinkedHashMultimap; import com.google.common.collect.Maps; -import org.apache.commons.cli.CommandLine; -import org.apache.commons.cli.CommandLineParser; -import org.apache.commons.cli.HelpFormatter; -import org.apache.commons.cli.Option; -import org.apache.commons.cli.Options; -import org.apache.commons.cli.ParseException; -import org.apache.commons.cli.PosixParser; +import org.apache.commons.cli.*; import org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutorMBean; import org.apache.cassandra.db.ColumnFamilyStoreMBean;
[jira] [Commented] (CASSANDRA-4678) Add possibility to stop repair session from nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459155#comment-13459155 ] Alexey Zotov commented on CASSANDRA-4678: - Sylvain, thanks for reference! Add possibility to stop repair session from nodetool Key: CASSANDRA-4678 URL: https://issues.apache.org/jira/browse/CASSANDRA-4678 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Minor Labels: nodetool, repair Attachments: cassandra-1.1-4678.txt I've added possibility to stop repair session from nodetool. 'stoprepair' command has been introduced. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4689) Log error when using IN together with ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4689:
---
Attachment: CASSANDRA-4689.patch
changes from CASSANDRA-4612 aren't covering extended selections properly.
Log error when using IN together with ORDER BY
--
Key: CASSANDRA-4689
URL: https://issues.apache.org/jira/browse/CASSANDRA-4689
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.5
Environment: built from source on cassandra-1.1
(b43cc362aa568a46bc53e545c68518b0bd350b76)
os: ubuntu
Reporter: Tyler Patterson
Assignee: Sylvain Lebresne
Fix For: 1.1.6
Attachments: CASSANDRA-4689.patch
{code}
$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.32.0]
Use HELP for help.
cqlsh use ks;
cqlsh:ks drop TABLE test;
cqlsh:ks CREATE TABLE test (my_id varchar, time_id uuid, value int, PRIMARY
KEY (my_id, time_id));
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key1', 1, 1);
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key2', 2, 2);
cqlsh:ks select * from test where my_id in('key1', 'key2') order by time_id;
TSocket read 0 bytes
{code}
The log shows this:
{code}
ERROR [Thrift:5] 2012-09-19 08:44:59,859 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.IllegalArgumentException: Column time_id wasn't found in select
clause.
at
org.apache.cassandra.cql3.statements.SelectStatement.getColumnPositionInSelect(SelectStatement.java:866)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:836)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:807)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1242)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
NOTE: This issue appears similar to
https://issues.apache.org/jira/browse/CASSANDRA-4612 from the user
perspective, even though 4612 was verified as fixed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4689) Log error when using IN together with ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4689:
---
Reviewer: slebresne
Log error when using IN together with ORDER BY
--
Key: CASSANDRA-4689
URL: https://issues.apache.org/jira/browse/CASSANDRA-4689
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.5
Environment: built from source on cassandra-1.1
(b43cc362aa568a46bc53e545c68518b0bd350b76)
os: ubuntu
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4689.patch
{code}
$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.32.0]
Use HELP for help.
cqlsh use ks;
cqlsh:ks drop TABLE test;
cqlsh:ks CREATE TABLE test (my_id varchar, time_id uuid, value int, PRIMARY
KEY (my_id, time_id));
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key1', 1, 1);
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key2', 2, 2);
cqlsh:ks select * from test where my_id in('key1', 'key2') order by time_id;
TSocket read 0 bytes
{code}
The log shows this:
{code}
ERROR [Thrift:5] 2012-09-19 08:44:59,859 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.IllegalArgumentException: Column time_id wasn't found in select
clause.
at
org.apache.cassandra.cql3.statements.SelectStatement.getColumnPositionInSelect(SelectStatement.java:866)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:836)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:807)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1242)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
NOTE: This issue appears similar to
https://issues.apache.org/jira/browse/CASSANDRA-4612 from the user
perspective, even though 4612 was verified as fixed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4689) Log error when using IN together with ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich reassigned CASSANDRA-4689:
--
Assignee: Pavel Yaskevich (was: Sylvain Lebresne)
Log error when using IN together with ORDER BY
--
Key: CASSANDRA-4689
URL: https://issues.apache.org/jira/browse/CASSANDRA-4689
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.5
Environment: built from source on cassandra-1.1
(b43cc362aa568a46bc53e545c68518b0bd350b76)
os: ubuntu
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4689.patch
{code}
$ bin/cqlsh -3
Connected to Test Cluster at localhost:9160.
[cqlsh 2.2.0 | Cassandra 1.1.5-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.32.0]
Use HELP for help.
cqlsh use ks;
cqlsh:ks drop TABLE test;
cqlsh:ks CREATE TABLE test (my_id varchar, time_id uuid, value int, PRIMARY
KEY (my_id, time_id));
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key1', 1, 1);
cqlsh:ks INSERT INTO test (my_id, time_id, value) VALUES ('key2', 2, 2);
cqlsh:ks select * from test where my_id in('key1', 'key2') order by time_id;
TSocket read 0 bytes
{code}
The log shows this:
{code}
ERROR [Thrift:5] 2012-09-19 08:44:59,859 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.IllegalArgumentException: Column time_id wasn't found in select
clause.
at
org.apache.cassandra.cql3.statements.SelectStatement.getColumnPositionInSelect(SelectStatement.java:866)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:836)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:807)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:137)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1242)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
NOTE: This issue appears similar to
https://issues.apache.org/jira/browse/CASSANDRA-4612 from the user
perspective, even though 4612 was verified as fixed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4545) add cql support for batchlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459174#comment-13459174 ] Aleksey Yeschenko commented on CASSANDRA-4545: -- I've done some simple benchmarking using cassandra-stress Inserter and modified Inserter that uses atomic_batch_mutate instead of batch_mutate. I used a three-node cluster, wiped and restarted every machine between test runs. cassandra-stres was being run from a fourth machine. Every batch only contains mutations to one partition key. I'll have to modify Stress more to include mutations of different rows in a batch. The difference will be larger there (regular mutations will be sent to different machines in parallel, but the whole serialized batch itself will still be sent in one piece, and we'll be waiting for at least one response (CL.ONE) before distributing regular mutations). So take the following numbers as the least possible difference between batch_mutate and atomic_batch_mutate or atomic_batch_mutate best case scenario. -n 1000 -c 1 == batch mutate 1000,100,100,0.008556,0 == atomic batch mutate 1000,100,100,0.024504,3 -n 1000 -c 10 == batch mutate 1000,100,100,0.010149,0 == atomic batch mutate 1000,100,100,0.032331,1 -n 1000 -c 100 == batch mutate 1000,100,100,0.038674,2 == atomic batch mutate 1000,100,100,0.041967,2 -n 1000 -c 1000 == batch mutate 1000,100,100,0.088965,4 == atomic batch mutate 1000,100,100,0.136551,6 -n 1000 -c 1 == batch mutate 547,54,54,0.6684040219378428,11 1000,45,45,0.5687505518763797,18 == atomic batch mutate 546,54,54,0.7630347985347985,11 924,37,37,0.768542328042328,21 1000,7,7,1.5153157894736842,24 -n 50 -c 10 == batch mutate 8,0,0,8.057,23 33,2,2,14.80572,33 50,1,1,18.833529411764705,35 == atomic batch mutate 10,1,1,6.5336,20 30,2,2,14.04065,30 40,1,1,27.3045,40 50,1,1,31.8171,46 add cql support for batchlog Key: CASSANDRA-4545 URL: https://issues.apache.org/jira/browse/CASSANDRA-4545 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Need to expose the equivalent of atomic_batch_mutate (CASSANDRA-4542) to CQL3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4691) Upgrade pig to 0.10
Brandon Williams created CASSANDRA-4691: --- Summary: Upgrade pig to 0.10 Key: CASSANDRA-4691 URL: https://issues.apache.org/jira/browse/CASSANDRA-4691 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.2.0 beta 2 Now that pig has a newer release and we have an upcoming one, it's a good chance to upgrade. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4545) add cql support for batchlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459197#comment-13459197 ] Aleksey Yeschenko commented on CASSANDRA-4545: -- I'm going to add more numbers on the weekends - with batches including mutations to different rows. add cql support for batchlog Key: CASSANDRA-4545 URL: https://issues.apache.org/jira/browse/CASSANDRA-4545 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Need to expose the equivalent of atomic_batch_mutate (CASSANDRA-4542) to CQL3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
