[jira] [Created] (CASSANDRA-4065) Bogus MemoryMeter liveRatio calculations
Bogus MemoryMeter liveRatio calculations Key: CASSANDRA-4065 URL: https://issues.apache.org/jira/browse/CASSANDRA-4065 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.8 Reporter: Daniel Doubleday Priority: Minor I get strange cfs.liveRatios. A couple of mem meter runs seem to calculate bogus results: {noformat} Tue 09:14:48 dd@blnrzh045:~$ grep 'setting live ratio to maximum of 64 instead of' /var/log/cassandra/system.log WARN [MemoryMeter:1] 2012-03-20 08:08:07,253 Memtable.java (line 193) setting live ratio to maximum of 64 instead of Infinity WARN [MemoryMeter:1] 2012-03-20 08:08:09,160 Memtable.java (line 193) setting live ratio to maximum of 64 instead of Infinity WARN [MemoryMeter:1] 2012-03-20 08:08:13,274 Memtable.java (line 193) setting live ratio to maximum of 64 instead of Infinity WARN [MemoryMeter:1] 2012-03-20 08:08:22,032 Memtable.java (line 193) setting live ratio to maximum of 64 instead of Infinity WARN [MemoryMeter:1] 2012-03-20 08:12:41,057 Memtable.java (line 193) setting live ratio to maximum of 64 instead of 67.11787351054079 WARN [MemoryMeter:1] 2012-03-20 08:13:50,877 Memtable.java (line 193) setting live ratio to maximum of 64 instead of 112.58547951925435 WARN [MemoryMeter:1] 2012-03-20 08:15:29,021 Memtable.java (line 193) setting live ratio to maximum of 64 instead of 193.36945063589877 WARN [MemoryMeter:1] 2012-03-20 08:17:50,716 Memtable.java (line 193) setting live ratio to maximum of 64 instead of 348.45008340969434 {noformat} Because meter runs never decrease liveRatio in Memtable (Which seems strange to me. If past calcs should be included for any reason wouldn't averaging make more sense?): {noformat} cfs.liveRatio = Math.max(cfs.liveRatio, newRatio); {noformat} Memtables are flushed every couple of secs: {noformat} ColumnFamilyStore.java (line 712) Enqueuing flush of Memtable-BlobStore@935814661(1874540/149963200 serialized/live bytes, 202 ops) {noformat} Even though a saner liveRatio has been calculated after the bogus runs: {noformat} INFO [MemoryMeter:1] 2012-03-20 08:19:55,934 Memtable.java (line 198) CFS(Keyspace='SmeetBlob', ColumnFamily='BlobStore') liveRatio is 64.0 (just-counted was 2.97165811895841). calculation took 124ms for 58 columns {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4061) Decommission should take a token
[ https://issues.apache.org/jira/browse/CASSANDRA-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233373#comment-13233373 ] MaHaiyang commented on CASSANDRA-4061: -- I think using "./nodetool -h host -p port decommission " is more simple than using "./nodetool -h host -p port decommision " . If "./nodetool -h host -p port decommision " could be available ,it can't be better. > Decommission should take a token > > > Key: CASSANDRA-4061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4061 > Project: Cassandra > Issue Type: Bug >Reporter: Brandon Williams >Assignee: Brandon Williams > Fix For: 1.2 > > > Like removetoken, decom should take a token parameter. This is a bit easier > said than done because it changes gossip, but I've seen enough people burned > by this (as I have myself.) In the short term though *decommission still > accepts a token parameter* which I thought we had fixed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3125) Move gossip library into a standalone artifact
[ https://issues.apache.org/jira/browse/CASSANDRA-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated CASSANDRA-3125: Labels: gsoc gsoc2012 mentor (was: ) > Move gossip library into a standalone artifact > --- > > Key: CASSANDRA-3125 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3125 > Project: Cassandra > Issue Type: Task >Reporter: Jake Farrell >Assignee: Jake Farrell >Priority: Minor > Labels: gsoc, gsoc2012, mentor > > There has been some talk on the mailing list of people want to use the gossip > portion of cassandra in their own applications. The goal for this will be to > create a standalone artifact -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4065) Bogus MemoryMeter liveRatio calculations
[ https://issues.apache.org/jira/browse/CASSANDRA-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233503#comment-13233503 ] Jonathan Ellis commented on CASSANDRA-4065: --- bq. meter runs never decrease liveRatio in Memtable, which seems strange to me. If past calcs should be included for any reason wouldn't averaging make more sense? I'm open to ways to improve this, but the idea is that the penalty for overestimating how big the memtable is (frequent flushes) is less severe than the penalty for underestimating (running out of memory and dying). > Bogus MemoryMeter liveRatio calculations > > > Key: CASSANDRA-4065 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4065 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.8 >Reporter: Daniel Doubleday >Priority: Minor > > I get strange cfs.liveRatios. > A couple of mem meter runs seem to calculate bogus results: > {noformat} > Tue 09:14:48 dd@blnrzh045:~$ grep 'setting live ratio to maximum of 64 > instead of' /var/log/cassandra/system.log > WARN [MemoryMeter:1] 2012-03-20 08:08:07,253 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:09,160 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:13,274 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:22,032 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:12:41,057 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 67.11787351054079 > WARN [MemoryMeter:1] 2012-03-20 08:13:50,877 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 112.58547951925435 > WARN [MemoryMeter:1] 2012-03-20 08:15:29,021 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 193.36945063589877 > WARN [MemoryMeter:1] 2012-03-20 08:17:50,716 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 348.45008340969434 > {noformat} > Because meter runs never decrease liveRatio in Memtable (Which seems strange > to me. If past calcs should be included for any reason wouldn't averaging > make more sense?): > {noformat} > cfs.liveRatio = Math.max(cfs.liveRatio, newRatio); > {noformat} > Memtables are flushed every couple of secs: > {noformat} > ColumnFamilyStore.java (line 712) Enqueuing flush of > Memtable-BlobStore@935814661(1874540/149963200 serialized/live bytes, 202 ops) > {noformat} > Even though a saner liveRatio has been calculated after the bogus runs: > {noformat} > INFO [MemoryMeter:1] 2012-03-20 08:19:55,934 Memtable.java (line 198) > CFS(Keyspace='SmeetBlob', ColumnFamily='BlobStore') >liveRatio is 64.0 (just-counted was 2.97165811895841). calculation took > 124ms for 58 columns > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4065) Bogus MemoryMeter liveRatio calculations
[ https://issues.apache.org/jira/browse/CASSANDRA-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233504#comment-13233504 ] Jonathan Ellis commented on CASSANDRA-4065: --- I wonder if we could use some kind of constantly-updated estimate instead of scanning the whole memtable periodically... > Bogus MemoryMeter liveRatio calculations > > > Key: CASSANDRA-4065 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4065 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.8 >Reporter: Daniel Doubleday >Priority: Minor > > I get strange cfs.liveRatios. > A couple of mem meter runs seem to calculate bogus results: > {noformat} > Tue 09:14:48 dd@blnrzh045:~$ grep 'setting live ratio to maximum of 64 > instead of' /var/log/cassandra/system.log > WARN [MemoryMeter:1] 2012-03-20 08:08:07,253 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:09,160 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:13,274 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:22,032 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:12:41,057 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 67.11787351054079 > WARN [MemoryMeter:1] 2012-03-20 08:13:50,877 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 112.58547951925435 > WARN [MemoryMeter:1] 2012-03-20 08:15:29,021 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 193.36945063589877 > WARN [MemoryMeter:1] 2012-03-20 08:17:50,716 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 348.45008340969434 > {noformat} > Because meter runs never decrease liveRatio in Memtable (Which seems strange > to me. If past calcs should be included for any reason wouldn't averaging > make more sense?): > {noformat} > cfs.liveRatio = Math.max(cfs.liveRatio, newRatio); > {noformat} > Memtables are flushed every couple of secs: > {noformat} > ColumnFamilyStore.java (line 712) Enqueuing flush of > Memtable-BlobStore@935814661(1874540/149963200 serialized/live bytes, 202 ops) > {noformat} > Even though a saner liveRatio has been calculated after the bogus runs: > {noformat} > INFO [MemoryMeter:1] 2012-03-20 08:19:55,934 Memtable.java (line 198) > CFS(Keyspace='SmeetBlob', ColumnFamily='BlobStore') >liveRatio is 64.0 (just-counted was 2.97165811895841). calculation took > 124ms for 58 columns > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4066) Cassandra cluster stops responding on time change (scheduling not using monotonic time?)
Cassandra cluster stops responding on time change (scheduling not using monotonic time?) - Key: CASSANDRA-4066 URL: https://issues.apache.org/jira/browse/CASSANDRA-4066 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.6 Environment: Linux; CentOS6 2.6.32-220.4.2.el6.x86_64 Reporter: David Daeschler The server installation I set up did not have ntpd installed in the base installation. When I noticed that the clocks were skewing I installed ntp and set the date on all the servers in the cluster. A short time later, I started getting UnavailableExceptions on the clients. Also, one sever seemed to be unaffected by the time change. That server happened to have it's time pushed forward, not backwards like the other 3 in the cluster. This leads me to believe something is running on a timer/schedule that is not monotonic. I'm posting this as a bug, but I suppose it might just be part of the communication protocols etc for the cluster and part of the design. But I think the devs should be aware of what I saw. Otherwise, thank you for a fantastic product. Even after restarting 75% of the cluster things seem to have recovered nicely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4066) Cassandra cluster stops responding on time change (scheduling not using monotonic time?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4066: -- Component/s: Core Priority: Minor (was: Major) Affects Version/s: (was: 1.0.6) Fix Version/s: 1.1.1 Assignee: Brandon Williams Labels: gossip (was: ) We make extensive use of Java's ScheduledExecutorService, which does not deal well with the system time being pulled out from under it: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7139684 I'm willing to live with this for the majority of scheduled tasks, however, it might be worth updating Gossip to use it's own thread + sleep calls to avoid this. On the other hand, if you didn't have Gossip dying with UAE, it would be very difficult to figure out why the rest of the background tasks stopped executing, which would cause things to go bad a lot more gradually. What do you think, Brandon? > Cassandra cluster stops responding on time change (scheduling not using > monotonic time?) > - > > Key: CASSANDRA-4066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4066 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Linux; CentOS6 2.6.32-220.4.2.el6.x86_64 >Reporter: David Daeschler >Assignee: Brandon Williams >Priority: Minor > Labels: gossip > Fix For: 1.1.1 > > > The server installation I set up did not have ntpd installed in the base > installation. When I noticed that the clocks were skewing I installed ntp and > set the date on all the servers in the cluster. A short time later, I started > getting UnavailableExceptions on the clients. > Also, one sever seemed to be unaffected by the time change. That server > happened to have it's time pushed forward, not backwards like the other 3 in > the cluster. This leads me to believe something is running on a > timer/schedule that is not monotonic. > I'm posting this as a bug, but I suppose it might just be part of the > communication protocols etc for the cluster and part of the design. But I > think the devs should be aware of what I saw. > Otherwise, thank you for a fantastic product. Even after restarting 75% of > the cluster things seem to have recovered nicely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4066) Cassandra cluster stops responding on time change (scheduling not using monotonic time?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233521#comment-13233521 ] David Daeschler commented on CASSANDRA-4066: Seeing the reference bug you posted, this might help as well: # java -version java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) > Cassandra cluster stops responding on time change (scheduling not using > monotonic time?) > - > > Key: CASSANDRA-4066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4066 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Linux; CentOS6 2.6.32-220.4.2.el6.x86_64 >Reporter: David Daeschler >Assignee: Brandon Williams >Priority: Minor > Labels: gossip > Fix For: 1.1.1 > > > The server installation I set up did not have ntpd installed in the base > installation. When I noticed that the clocks were skewing I installed ntp and > set the date on all the servers in the cluster. A short time later, I started > getting UnavailableExceptions on the clients. > Also, one sever seemed to be unaffected by the time change. That server > happened to have it's time pushed forward, not backwards like the other 3 in > the cluster. This leads me to believe something is running on a > timer/schedule that is not monotonic. > I'm posting this as a bug, but I suppose it might just be part of the > communication protocols etc for the cluster and part of the design. But I > think the devs should be aware of what I saw. > Otherwise, thank you for a fantastic product. Even after restarting 75% of > the cluster things seem to have recovered nicely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4066) Cassandra cluster stops responding on time change (scheduling not using monotonic time?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233526#comment-13233526 ] David Daeschler commented on CASSANDRA-4066: Another bit of information. I tried the normal procedure for stopping the server which is part of an init script. It executes 'kill PID' to stop the server. This script failed after waiting about 5 minutes for cassandra to stop. Checking top, I didn't see any CPU or disk activity from the cassandra service, so I ended up force killing it with kill -9. Just giving this information in case it affects your view of the scope/location of the problem. > Cassandra cluster stops responding on time change (scheduling not using > monotonic time?) > - > > Key: CASSANDRA-4066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4066 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Linux; CentOS6 2.6.32-220.4.2.el6.x86_64 >Reporter: David Daeschler >Assignee: Brandon Williams >Priority: Minor > Labels: gossip > Fix For: 1.1.1 > > > The server installation I set up did not have ntpd installed in the base > installation. When I noticed that the clocks were skewing I installed ntp and > set the date on all the servers in the cluster. A short time later, I started > getting UnavailableExceptions on the clients. > Also, one sever seemed to be unaffected by the time change. That server > happened to have it's time pushed forward, not backwards like the other 3 in > the cluster. This leads me to believe something is running on a > timer/schedule that is not monotonic. > I'm posting this as a bug, but I suppose it might just be part of the > communication protocols etc for the cluster and part of the design. But I > think the devs should be aware of what I saw. > Otherwise, thank you for a fantastic product. Even after restarting 75% of > the cluster things seem to have recovered nicely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4065) Bogus MemoryMeter liveRatio calculations
[ https://issues.apache.org/jira/browse/CASSANDRA-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233560#comment-13233560 ] Daniel Doubleday commented on CASSANDRA-4065: - Maybe a simple solution would suffice: Don't use jamm but do some simplified estimation as estimate_size = $raw_size + $row_count * ROW_OVERHEAD + $column_count * COL_OVERHEAD Since we know the used data structures ... and to keep it easy use 64b overhead since this will be the usual case anyway. > Bogus MemoryMeter liveRatio calculations > > > Key: CASSANDRA-4065 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4065 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.8 >Reporter: Daniel Doubleday >Priority: Minor > > I get strange cfs.liveRatios. > A couple of mem meter runs seem to calculate bogus results: > {noformat} > Tue 09:14:48 dd@blnrzh045:~$ grep 'setting live ratio to maximum of 64 > instead of' /var/log/cassandra/system.log > WARN [MemoryMeter:1] 2012-03-20 08:08:07,253 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:09,160 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:13,274 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:22,032 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:12:41,057 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 67.11787351054079 > WARN [MemoryMeter:1] 2012-03-20 08:13:50,877 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 112.58547951925435 > WARN [MemoryMeter:1] 2012-03-20 08:15:29,021 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 193.36945063589877 > WARN [MemoryMeter:1] 2012-03-20 08:17:50,716 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 348.45008340969434 > {noformat} > Because meter runs never decrease liveRatio in Memtable (Which seems strange > to me. If past calcs should be included for any reason wouldn't averaging > make more sense?): > {noformat} > cfs.liveRatio = Math.max(cfs.liveRatio, newRatio); > {noformat} > Memtables are flushed every couple of secs: > {noformat} > ColumnFamilyStore.java (line 712) Enqueuing flush of > Memtable-BlobStore@935814661(1874540/149963200 serialized/live bytes, 202 ops) > {noformat} > Even though a saner liveRatio has been calculated after the bogus runs: > {noformat} > INFO [MemoryMeter:1] 2012-03-20 08:19:55,934 Memtable.java (line 198) > CFS(Keyspace='SmeetBlob', ColumnFamily='BlobStore') >liveRatio is 64.0 (just-counted was 2.97165811895841). calculation took > 124ms for 58 columns > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4065) Bogus MemoryMeter liveRatio calculations
[ https://issues.apache.org/jira/browse/CASSANDRA-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233592#comment-13233592 ] Jonathan Ellis commented on CASSANDRA-4065: --- That's probably possible in theory, but there isn't a fixed-size overhead for structures like CLHM. > Bogus MemoryMeter liveRatio calculations > > > Key: CASSANDRA-4065 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4065 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.8 >Reporter: Daniel Doubleday >Priority: Minor > > I get strange cfs.liveRatios. > A couple of mem meter runs seem to calculate bogus results: > {noformat} > Tue 09:14:48 dd@blnrzh045:~$ grep 'setting live ratio to maximum of 64 > instead of' /var/log/cassandra/system.log > WARN [MemoryMeter:1] 2012-03-20 08:08:07,253 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:09,160 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:13,274 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:22,032 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:12:41,057 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 67.11787351054079 > WARN [MemoryMeter:1] 2012-03-20 08:13:50,877 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 112.58547951925435 > WARN [MemoryMeter:1] 2012-03-20 08:15:29,021 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 193.36945063589877 > WARN [MemoryMeter:1] 2012-03-20 08:17:50,716 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 348.45008340969434 > {noformat} > Because meter runs never decrease liveRatio in Memtable (Which seems strange > to me. If past calcs should be included for any reason wouldn't averaging > make more sense?): > {noformat} > cfs.liveRatio = Math.max(cfs.liveRatio, newRatio); > {noformat} > Memtables are flushed every couple of secs: > {noformat} > ColumnFamilyStore.java (line 712) Enqueuing flush of > Memtable-BlobStore@935814661(1874540/149963200 serialized/live bytes, 202 ops) > {noformat} > Even though a saner liveRatio has been calculated after the bogus runs: > {noformat} > INFO [MemoryMeter:1] 2012-03-20 08:19:55,934 Memtable.java (line 198) > CFS(Keyspace='SmeetBlob', ColumnFamily='BlobStore') >liveRatio is 64.0 (just-counted was 2.97165811895841). calculation took > 124ms for 58 columns > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4066) Cassandra cluster stops responding on time change (scheduling not using monotonic time?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233648#comment-13233648 ] Brandon Williams commented on CASSANDRA-4066: - I can confirm that this is indeed the GossipTask no longer running when the clock is pushed backward far enough. As you mention, we use SES extensively and likely all those timed tasks have also quit firing, which could lead to an untold amount of confusion if we special-cased gossip, since there would be no immediate red flag to indicate a problem. Starting a node far in the future has other consequences too, such as CASSANDRA-3654. I think I would rather see the UAE and know that my machines have connectivity to identify this problem and fix it correctly. Even if we do special-case the GossipTask, we'll also need to fix LoadBroadcaster so we don't end up with a broken view of the load on the ring, and at that point it feels like a slippery slope where we need to fix everything, or fail as quickly as possible, which is what the current behavior does. Also an interesting thing to note is that the node still replies to gossip syn messages with a gossip ack, but because we only update the FD on a version/generation change, and because LoadBroadcaster is also broken the node has no reason to generate new versions, it remains seen as down to the other nodes. If LB did happen to work, we'd see the node flap every 90 seconds. > Cassandra cluster stops responding on time change (scheduling not using > monotonic time?) > - > > Key: CASSANDRA-4066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4066 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Linux; CentOS6 2.6.32-220.4.2.el6.x86_64 >Reporter: David Daeschler >Assignee: Brandon Williams >Priority: Minor > Labels: gossip > Fix For: 1.1.1 > > > The server installation I set up did not have ntpd installed in the base > installation. When I noticed that the clocks were skewing I installed ntp and > set the date on all the servers in the cluster. A short time later, I started > getting UnavailableExceptions on the clients. > Also, one sever seemed to be unaffected by the time change. That server > happened to have it's time pushed forward, not backwards like the other 3 in > the cluster. This leads me to believe something is running on a > timer/schedule that is not monotonic. > I'm posting this as a bug, but I suppose it might just be part of the > communication protocols etc for the cluster and part of the design. But I > think the devs should be aware of what I saw. > Otherwise, thank you for a fantastic product. Even after restarting 75% of > the cluster things seem to have recovered nicely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4066) Cassandra cluster stops responding on time change (scheduling not using monotonic time?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4066. - Resolution: Won't Fix > Cassandra cluster stops responding on time change (scheduling not using > monotonic time?) > - > > Key: CASSANDRA-4066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4066 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Linux; CentOS6 2.6.32-220.4.2.el6.x86_64 >Reporter: David Daeschler >Assignee: Brandon Williams >Priority: Minor > Labels: gossip > Fix For: 1.1.1 > > > The server installation I set up did not have ntpd installed in the base > installation. When I noticed that the clocks were skewing I installed ntp and > set the date on all the servers in the cluster. A short time later, I started > getting UnavailableExceptions on the clients. > Also, one sever seemed to be unaffected by the time change. That server > happened to have it's time pushed forward, not backwards like the other 3 in > the cluster. This leads me to believe something is running on a > timer/schedule that is not monotonic. > I'm posting this as a bug, but I suppose it might just be part of the > communication protocols etc for the cluster and part of the design. But I > think the devs should be aware of what I saw. > Otherwise, thank you for a fantastic product. Even after restarting 75% of > the cluster things seem to have recovered nicely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4066) Cassandra cluster stops responding on time change (scheduling not using monotonic time?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233662#comment-13233662 ] David Daeschler commented on CASSANDRA-4066: Thanks for looking. At least this is documented now. Just FYI this can become a problem on some virtualized systems even with time sync enabled. For example there appears to be a bug going around for windows on Hyper-V where the time sync service just stops working. I have a lot of servers running in this configuration (though not running cassandra thankfully) and I have had to schedule a daily reset of the time sync services to keep the clocks in check. Anyways, have a nice day and keep up the good work. > Cassandra cluster stops responding on time change (scheduling not using > monotonic time?) > - > > Key: CASSANDRA-4066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4066 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Linux; CentOS6 2.6.32-220.4.2.el6.x86_64 >Reporter: David Daeschler >Assignee: Brandon Williams >Priority: Minor > Labels: gossip > Fix For: 1.1.1 > > > The server installation I set up did not have ntpd installed in the base > installation. When I noticed that the clocks were skewing I installed ntp and > set the date on all the servers in the cluster. A short time later, I started > getting UnavailableExceptions on the clients. > Also, one sever seemed to be unaffected by the time change. That server > happened to have it's time pushed forward, not backwards like the other 3 in > the cluster. This leads me to believe something is running on a > timer/schedule that is not monotonic. > I'm posting this as a bug, but I suppose it might just be part of the > communication protocols etc for the cluster and part of the design. But I > think the devs should be aware of what I saw. > Otherwise, thank you for a fantastic product. Even after restarting 75% of > the cluster things seem to have recovered nicely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4067) Report lifetime compaction throughput
Report lifetime compaction throughput - Key: CASSANDRA-4067 URL: https://issues.apache.org/jira/browse/CASSANDRA-4067 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Trivial Fix For: 1.1.0 Would be useful to be able to monitor total compaction throughput without having to poll frequently enough to make sure we get every CompactionInfo object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4065) Bogus MemoryMeter liveRatio calculations
[ https://issues.apache.org/jira/browse/CASSANDRA-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233847#comment-13233847 ] Daniel Doubleday commented on CASSANDRA-4065: - bq. That's probably possible in theory, but there isn't a fixed-size overhead for structures like CLHM. Well yes - I though of an approximation. But maybe even easier (still conservative but able to heal): {noformat} if (newRatio > cfs.liveRatio) { cfs.liveRatio = newRatio; } else { cfs.liveRatio = (cfs.liveRatio + newRatio) / 2.0; } {noformat} > Bogus MemoryMeter liveRatio calculations > > > Key: CASSANDRA-4065 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4065 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.8 >Reporter: Daniel Doubleday >Priority: Minor > > I get strange cfs.liveRatios. > A couple of mem meter runs seem to calculate bogus results: > {noformat} > Tue 09:14:48 dd@blnrzh045:~$ grep 'setting live ratio to maximum of 64 > instead of' /var/log/cassandra/system.log > WARN [MemoryMeter:1] 2012-03-20 08:08:07,253 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:09,160 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:13,274 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:08:22,032 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of Infinity > WARN [MemoryMeter:1] 2012-03-20 08:12:41,057 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 67.11787351054079 > WARN [MemoryMeter:1] 2012-03-20 08:13:50,877 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 112.58547951925435 > WARN [MemoryMeter:1] 2012-03-20 08:15:29,021 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 193.36945063589877 > WARN [MemoryMeter:1] 2012-03-20 08:17:50,716 Memtable.java (line 193) > setting live ratio to maximum of 64 instead of 348.45008340969434 > {noformat} > Because meter runs never decrease liveRatio in Memtable (Which seems strange > to me. If past calcs should be included for any reason wouldn't averaging > make more sense?): > {noformat} > cfs.liveRatio = Math.max(cfs.liveRatio, newRatio); > {noformat} > Memtables are flushed every couple of secs: > {noformat} > ColumnFamilyStore.java (line 712) Enqueuing flush of > Memtable-BlobStore@935814661(1874540/149963200 serialized/live bytes, 202 ops) > {noformat} > Even though a saner liveRatio has been calculated after the bogus runs: > {noformat} > INFO [MemoryMeter:1] 2012-03-20 08:19:55,934 Memtable.java (line 198) > CFS(Keyspace='SmeetBlob', ColumnFamily='BlobStore') >liveRatio is 64.0 (just-counted was 2.97165811895841). calculation took > 124ms for 58 columns > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4068) Add link for searchable user archives to index.html
Add link for searchable user archives to index.html - Key: CASSANDRA-4068 URL: https://issues.apache.org/jira/browse/CASSANDRA-4068 Project: Cassandra Issue Type: Improvement Components: Documentation & website Reporter: Lewis John McGibbney Priority: Minor I was frustrated by the absence of a link to the searchable user@ Cassandra list. This patch just needs one of the committers to patch the site, then build and publish for us all to sleep in peace knowing that we can access the user lists at the click of a link :) Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4068) Add link for searchable user archives to index.html
[ https://issues.apache.org/jira/browse/CASSANDRA-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lewis John McGibbney updated CASSANDRA-4068: Attachment: CASSANDRA-4068.patch Trivial patch attachment which addresses this issue. > Add link for searchable user archives to index.html > - > > Key: CASSANDRA-4068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4068 > Project: Cassandra > Issue Type: Improvement > Components: Documentation & website >Reporter: Lewis John McGibbney >Priority: Minor > Attachments: CASSANDRA-4068.patch > > > I was frustrated by the absence of a link to the searchable user@ Cassandra > list. This patch just needs one of the committers to patch the site, then > build and publish for us all to sleep in peace knowing that we can access the > user lists at the click of a link :) > Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[2/6] git commit: Merge branch 'cassandra-1.1.0' into cassandra-1.1
Merge branch 'cassandra-1.1.0' into cassandra-1.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5787bb80 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5787bb80 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5787bb80 Branch: refs/heads/cassandra-1.1 Commit: 5787bb80ed54da34aca0bbbaf3c016024658dc93 Parents: 706787c 050e61a Author: Jonathan Ellis Authored: Tue Mar 20 18:04:25 2012 -0500 Committer: Jonathan Ellis Committed: Tue Mar 20 18:04:25 2012 -0500 -- .../org/apache/cassandra/cql/UpdateStatement.java |2 ++ .../cassandra/cql3/statements/UpdateStatement.java |2 ++ src/java/org/apache/cassandra/db/DecoratedKey.java |2 +- 3 files changed, 5 insertions(+), 1 deletions(-) --
[3/6] git commit: Merge branch 'cassandra-1.1.0' into cassandra-1.1
Merge branch 'cassandra-1.1.0' into cassandra-1.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5787bb80 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5787bb80 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5787bb80 Branch: refs/heads/trunk Commit: 5787bb80ed54da34aca0bbbaf3c016024658dc93 Parents: 706787c 050e61a Author: Jonathan Ellis Authored: Tue Mar 20 18:04:25 2012 -0500 Committer: Jonathan Ellis Committed: Tue Mar 20 18:04:25 2012 -0500 -- .../org/apache/cassandra/cql/UpdateStatement.java |2 ++ .../cassandra/cql3/statements/UpdateStatement.java |2 ++ src/java/org/apache/cassandra/db/DecoratedKey.java |2 +- 3 files changed, 5 insertions(+), 1 deletions(-) --
[5/6] git commit: re-allow indexing empty column values patch by yukim; reviewed by jbellis for CASSANDRA-4031
re-allow indexing empty column values patch by yukim; reviewed by jbellis for CASSANDRA-4031 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/050e61a7 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/050e61a7 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/050e61a7 Branch: refs/heads/cassandra-1.1.0 Commit: 050e61a70bc95257c45f405fdb9997512096f963 Parents: c5aa781 Author: Jonathan Ellis Authored: Tue Mar 20 18:04:14 2012 -0500 Committer: Jonathan Ellis Committed: Tue Mar 20 18:04:14 2012 -0500 -- .../org/apache/cassandra/cql/UpdateStatement.java |2 ++ .../cassandra/cql3/statements/UpdateStatement.java |2 ++ src/java/org/apache/cassandra/db/DecoratedKey.java |2 +- 3 files changed, 5 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/cql/UpdateStatement.java -- diff --git a/src/java/org/apache/cassandra/cql/UpdateStatement.java b/src/java/org/apache/cassandra/cql/UpdateStatement.java index d6d410a..4c2be4d 100644 --- a/src/java/org/apache/cassandra/cql/UpdateStatement.java +++ b/src/java/org/apache/cassandra/cql/UpdateStatement.java @@ -36,6 +36,7 @@ import org.apache.cassandra.thrift.ConsistencyLevel; import org.apache.cassandra.thrift.InvalidRequestException; import static org.apache.cassandra.cql.QueryProcessor.validateColumn; +import static org.apache.cassandra.cql.QueryProcessor.validateKey; import static org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily; import static org.apache.cassandra.thrift.ThriftValidation.validateCommutativeForWrite; @@ -185,6 +186,7 @@ public class UpdateStatement extends AbstractModification private IMutation mutationForKey(String keyspace, ByteBuffer key, CFMetaData metadata, Long timestamp, ClientState clientState, List variables) throws InvalidRequestException { +validateKey(key); AbstractType comparator = getComparator(keyspace); // if true we need to wrap RowMutation into CounterMutation http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java -- diff --git a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java b/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java index dd699f4..a1724d9 100644 --- a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java @@ -32,6 +32,7 @@ import org.apache.cassandra.thrift.InvalidRequestException; import org.apache.cassandra.utils.ByteBufferUtil; import static org.apache.cassandra.cql.QueryProcessor.validateColumnName; +import static org.apache.cassandra.cql.QueryProcessor.validateKey; import static org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily; import static org.apache.cassandra.thrift.ThriftValidation.validateCommutativeForWrite; @@ -148,6 +149,7 @@ public class UpdateStatement extends ModificationStatement private IMutation mutationForKey(CFDefinition cfDef, ClientState clientState, ByteBuffer key, ColumnNameBuilder builder, List variables) throws InvalidRequestException { +validateKey(key); // if true we need to wrap RowMutation into CounterMutation boolean hasCounterColumn = false; RowMutation rm = new RowMutation(cfDef.cfm.ksName, key); http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/db/DecoratedKey.java -- diff --git a/src/java/org/apache/cassandra/db/DecoratedKey.java b/src/java/org/apache/cassandra/db/DecoratedKey.java index 81ead8c..4f6c862 100644 --- a/src/java/org/apache/cassandra/db/DecoratedKey.java +++ b/src/java/org/apache/cassandra/db/DecoratedKey.java @@ -52,7 +52,7 @@ public class DecoratedKey extends RowPosition public DecoratedKey(T token, ByteBuffer key) { -assert token != null && key != null && key.remaining() > 0; +assert token != null && key != null; this.token = token; this.key = key; }
[6/6] git commit: re-allow indexing empty column values patch by yukim; reviewed by jbellis for CASSANDRA-4031
re-allow indexing empty column values patch by yukim; reviewed by jbellis for CASSANDRA-4031 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/050e61a7 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/050e61a7 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/050e61a7 Branch: refs/heads/cassandra-1.1 Commit: 050e61a70bc95257c45f405fdb9997512096f963 Parents: c5aa781 Author: Jonathan Ellis Authored: Tue Mar 20 18:04:14 2012 -0500 Committer: Jonathan Ellis Committed: Tue Mar 20 18:04:14 2012 -0500 -- .../org/apache/cassandra/cql/UpdateStatement.java |2 ++ .../cassandra/cql3/statements/UpdateStatement.java |2 ++ src/java/org/apache/cassandra/db/DecoratedKey.java |2 +- 3 files changed, 5 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/cql/UpdateStatement.java -- diff --git a/src/java/org/apache/cassandra/cql/UpdateStatement.java b/src/java/org/apache/cassandra/cql/UpdateStatement.java index d6d410a..4c2be4d 100644 --- a/src/java/org/apache/cassandra/cql/UpdateStatement.java +++ b/src/java/org/apache/cassandra/cql/UpdateStatement.java @@ -36,6 +36,7 @@ import org.apache.cassandra.thrift.ConsistencyLevel; import org.apache.cassandra.thrift.InvalidRequestException; import static org.apache.cassandra.cql.QueryProcessor.validateColumn; +import static org.apache.cassandra.cql.QueryProcessor.validateKey; import static org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily; import static org.apache.cassandra.thrift.ThriftValidation.validateCommutativeForWrite; @@ -185,6 +186,7 @@ public class UpdateStatement extends AbstractModification private IMutation mutationForKey(String keyspace, ByteBuffer key, CFMetaData metadata, Long timestamp, ClientState clientState, List variables) throws InvalidRequestException { +validateKey(key); AbstractType comparator = getComparator(keyspace); // if true we need to wrap RowMutation into CounterMutation http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java -- diff --git a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java b/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java index dd699f4..a1724d9 100644 --- a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java @@ -32,6 +32,7 @@ import org.apache.cassandra.thrift.InvalidRequestException; import org.apache.cassandra.utils.ByteBufferUtil; import static org.apache.cassandra.cql.QueryProcessor.validateColumnName; +import static org.apache.cassandra.cql.QueryProcessor.validateKey; import static org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily; import static org.apache.cassandra.thrift.ThriftValidation.validateCommutativeForWrite; @@ -148,6 +149,7 @@ public class UpdateStatement extends ModificationStatement private IMutation mutationForKey(CFDefinition cfDef, ClientState clientState, ByteBuffer key, ColumnNameBuilder builder, List variables) throws InvalidRequestException { +validateKey(key); // if true we need to wrap RowMutation into CounterMutation boolean hasCounterColumn = false; RowMutation rm = new RowMutation(cfDef.cfm.ksName, key); http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/db/DecoratedKey.java -- diff --git a/src/java/org/apache/cassandra/db/DecoratedKey.java b/src/java/org/apache/cassandra/db/DecoratedKey.java index 81ead8c..4f6c862 100644 --- a/src/java/org/apache/cassandra/db/DecoratedKey.java +++ b/src/java/org/apache/cassandra/db/DecoratedKey.java @@ -52,7 +52,7 @@ public class DecoratedKey extends RowPosition public DecoratedKey(T token, ByteBuffer key) { -assert token != null && key != null && key.remaining() > 0; +assert token != null && key != null; this.token = token; this.key = key; }
[4/6] git commit: re-allow indexing empty column values patch by yukim; reviewed by jbellis for CASSANDRA-4031
re-allow indexing empty column values patch by yukim; reviewed by jbellis for CASSANDRA-4031 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/050e61a7 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/050e61a7 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/050e61a7 Branch: refs/heads/trunk Commit: 050e61a70bc95257c45f405fdb9997512096f963 Parents: c5aa781 Author: Jonathan Ellis Authored: Tue Mar 20 18:04:14 2012 -0500 Committer: Jonathan Ellis Committed: Tue Mar 20 18:04:14 2012 -0500 -- .../org/apache/cassandra/cql/UpdateStatement.java |2 ++ .../cassandra/cql3/statements/UpdateStatement.java |2 ++ src/java/org/apache/cassandra/db/DecoratedKey.java |2 +- 3 files changed, 5 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/cql/UpdateStatement.java -- diff --git a/src/java/org/apache/cassandra/cql/UpdateStatement.java b/src/java/org/apache/cassandra/cql/UpdateStatement.java index d6d410a..4c2be4d 100644 --- a/src/java/org/apache/cassandra/cql/UpdateStatement.java +++ b/src/java/org/apache/cassandra/cql/UpdateStatement.java @@ -36,6 +36,7 @@ import org.apache.cassandra.thrift.ConsistencyLevel; import org.apache.cassandra.thrift.InvalidRequestException; import static org.apache.cassandra.cql.QueryProcessor.validateColumn; +import static org.apache.cassandra.cql.QueryProcessor.validateKey; import static org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily; import static org.apache.cassandra.thrift.ThriftValidation.validateCommutativeForWrite; @@ -185,6 +186,7 @@ public class UpdateStatement extends AbstractModification private IMutation mutationForKey(String keyspace, ByteBuffer key, CFMetaData metadata, Long timestamp, ClientState clientState, List variables) throws InvalidRequestException { +validateKey(key); AbstractType comparator = getComparator(keyspace); // if true we need to wrap RowMutation into CounterMutation http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java -- diff --git a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java b/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java index dd699f4..a1724d9 100644 --- a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java @@ -32,6 +32,7 @@ import org.apache.cassandra.thrift.InvalidRequestException; import org.apache.cassandra.utils.ByteBufferUtil; import static org.apache.cassandra.cql.QueryProcessor.validateColumnName; +import static org.apache.cassandra.cql.QueryProcessor.validateKey; import static org.apache.cassandra.thrift.ThriftValidation.validateColumnFamily; import static org.apache.cassandra.thrift.ThriftValidation.validateCommutativeForWrite; @@ -148,6 +149,7 @@ public class UpdateStatement extends ModificationStatement private IMutation mutationForKey(CFDefinition cfDef, ClientState clientState, ByteBuffer key, ColumnNameBuilder builder, List variables) throws InvalidRequestException { +validateKey(key); // if true we need to wrap RowMutation into CounterMutation boolean hasCounterColumn = false; RowMutation rm = new RowMutation(cfDef.cfm.ksName, key); http://git-wip-us.apache.org/repos/asf/cassandra/blob/050e61a7/src/java/org/apache/cassandra/db/DecoratedKey.java -- diff --git a/src/java/org/apache/cassandra/db/DecoratedKey.java b/src/java/org/apache/cassandra/db/DecoratedKey.java index 81ead8c..4f6c862 100644 --- a/src/java/org/apache/cassandra/db/DecoratedKey.java +++ b/src/java/org/apache/cassandra/db/DecoratedKey.java @@ -52,7 +52,7 @@ public class DecoratedKey extends RowPosition public DecoratedKey(T token, ByteBuffer key) { -assert token != null && key != null && key.remaining() > 0; +assert token != null && key != null; this.token = token; this.key = key; }
[1/6] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 706787cfe -> 5787bb80e refs/heads/cassandra-1.1.0 c5aa781e8 -> 050e61a70 refs/heads/trunk ae62b54dd -> 908e0e2d7 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/908e0e2d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/908e0e2d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/908e0e2d Branch: refs/heads/trunk Commit: 908e0e2d7fe56124a01eb4f9b02b7e2034e177e0 Parents: ae62b54 5787bb8 Author: Jonathan Ellis Authored: Tue Mar 20 18:04:33 2012 -0500 Committer: Jonathan Ellis Committed: Tue Mar 20 18:04:33 2012 -0500 -- .../org/apache/cassandra/cql/UpdateStatement.java |2 ++ .../cassandra/cql3/statements/UpdateStatement.java |2 ++ src/java/org/apache/cassandra/db/DecoratedKey.java |2 +- 3 files changed, 5 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/908e0e2d/src/java/org/apache/cassandra/cql/UpdateStatement.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/908e0e2d/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/908e0e2d/src/java/org/apache/cassandra/db/DecoratedKey.java -- diff --cc src/java/org/apache/cassandra/db/DecoratedKey.java index 3f1db38,4f6c862..72091a1 --- a/src/java/org/apache/cassandra/db/DecoratedKey.java +++ b/src/java/org/apache/cassandra/db/DecoratedKey.java @@@ -46,12 -47,12 +46,12 @@@ public class DecoratedKey extends RowPo } }; -public final T token; +public final Token token; public final ByteBuffer key; -public DecoratedKey(T token, ByteBuffer key) +public DecoratedKey(Token token, ByteBuffer key) { - assert token != null && key != null && key.remaining() > 0; + assert token != null && key != null; this.token = token; this.key = key; }
[jira] [Commented] (CASSANDRA-4068) Add link for searchable user archives to index.html
[ https://issues.apache.org/jira/browse/CASSANDRA-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233932#comment-13233932 ] Jonathan Ellis commented on CASSANDRA-4068: --- What's wrong with the "Archives" link to http://www.mail-archive.com/user@cassandra.apache.org/ ? > Add link for searchable user archives to index.html > - > > Key: CASSANDRA-4068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4068 > Project: Cassandra > Issue Type: Improvement > Components: Documentation & website >Reporter: Lewis John McGibbney >Priority: Minor > Attachments: CASSANDRA-4068.patch > > > I was frustrated by the absence of a link to the searchable user@ Cassandra > list. This patch just needs one of the committers to patch the site, then > build and publish for us all to sleep in peace knowing that we can access the > user lists at the click of a link :) > Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[cassandra-node] 12 new revisions pushed by gdusba...@gmail.com on 2012-03-20 11:15 GMT
12 new revisions: Revision: 6966cf8c2a69 Author: Tomaz Muraus Date: Mon Feb 13 11:12:14 2012 Log: Change all the emitted log events to be in the following format emit(l... http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=6966cf8c2a69 Revision: e4f3ac432b19 Author: Tomaz Muraus Date: Mon Feb 13 12:23:43 2012 Log: Update readme. http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=e4f3ac432b19 Revision: a90fa485ba30 Author: Tomaz Muraus Date: Mon Feb 13 12:54:50 2012 Log: Update affected test. http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=a90fa485ba30 Revision: b74166bc74e4 Author: Tomaz Muraus Date: Mon Feb 13 13:59:32 2012 Log: bimp version to 0.9.0 http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=b74166bc74e4 Revision: 890c02e3ccdc Author: Tomaz Muraus Date: Mon Feb 13 13:59:43 2012 Log: update changes. http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=890c02e3ccdc Revision: 04360de36eca Author: Peter Rekdal Sunde Date: Wed Feb 22 12:29:28 2012 Log: Documentation link is broken. DataStax offers a better CQL reference o... http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=04360de36eca Revision: eca636faca5d Author: Tomaž Muraus Date: Wed Feb 22 12:42:54 2012 Log: Merge pull request #21 from peters/patch-2... http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=eca636faca5d Revision: ab0ea78dc05f Author: Tomaz Muraus Date: Tue Feb 28 14:22:41 2012 Log: Also emit an error log event while catching an error. http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=ab0ea78dc05f Revision: 9878cd717402 Author: Tomaz Muraus Date: Wed Mar 14 12:50:37 2012 Log: Remove TimedOutException from appExceptions - we should retry a query ... http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=9878cd717402 Revision: 75b447f7216c Author: Tomaz Muraus Date: Wed Mar 14 12:53:34 2012 Log: Also include err in the log object. http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=75b447f7216c Revision: f3955453cd42 Author: Tomaz Muraus Date: Wed Mar 14 13:42:36 2012 Log: Update readme. http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=f3955453cd42 Revision: 4887b6da82d2 Author: Gary Dusbabek Date: Wed Mar 14 14:06:02 2012 Log: bump version 0.9.1 http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=4887b6da82d2 == Revision: 6966cf8c2a69 Author: Tomaz Muraus Date: Mon Feb 13 11:12:14 2012 Log: Change all the emitted log events to be in the following format emit(log, level, message, obj) where obj is an optional object with arguments. http://code.google.com/a/apache-extras.org/p/cassandra-node/source/detail?r=6966cf8c2a69 Modified: /lib/driver.js === --- /lib/driver.js Fri Feb 3 07:43:44 2012 +++ /lib/driver.js Mon Feb 13 11:12:14 2012 @@ -210,20 +210,23 @@ var self = this, timeoutId; - self.emit('log', 'info', 'connecting ' + self.connectionInfo.host + ':' + self.connectionInfo.port + '(' + this._id + ')'); + self.emit('log', 'info', 'connecting ' + self.connectionInfo.host + ':' + self.connectionInfo.port + '(' + this._id + ')', +{'connectionInfo': self.connectionInfo}); // build connection here, so that timeouts on bad hosts happen now and not in the constructor. this.con = thrift.createConnection(self.connectionInfo.host, self.connectionInfo.port); this.con.on('error', function(err) { clearTimeout(timeoutId); -self.emit('log', 'error', self.connectionInfo.host + ':' + self.connectionInfo.port + ' error during connect.'); +self.emit('log', 'error', self.connectionInfo.host + ':' + self.connectionInfo.port + ' error during connect.', + {'connectionInfo': self.connectionInfo, 'err': err}); amendError(err, self.connectionInfo); callback(err); }); this.con.on('close', function() { clearTimeout(timeoutId); -self.emit('log', 'info', self.connectionInfo.host + ':' + self.connectionInfo.port + ' is closed (' + self._id + ')'); +self.emit('log', 'info', self.connectionInfo.host + ':' + self.connectionInfo.port + ' is closed (' + self._id + ')', + {'connectionInfo': self.connectionInfo}); }); this.con.on('connect', function() { @@ -390,11 +393,11 @@ start, end, diff; start = new Date().getTime(); -self.emit('log', 'cql', {'query': query, 'parameterized_query': cqlString, 'args': args}); +self.emit('log', 'cql', cqlString, {'query': query, 'parameterized_query': cqlString, 'args': args});