[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});
