[jira] Issue Comment Edited: (CASSANDRA-2242) Improve BRAFTest
[ https://issues.apache.org/jira/browse/CASSANDRA-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999310#comment-12999310 ] Pavel Yaskevich edited comment on CASSANDRA-2242 at 2/25/11 11:42 AM: -- Should I wait until CASSANDRA-2241 to be committed? was (Author: xedin): Sould I wait until CASSANDRA-2241 to be committed? Improve BRAFTest Key: CASSANDRA-2242 URL: https://issues.apache.org/jira/browse/CASSANDRA-2242 Project: Cassandra Issue Type: Test Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.3 BRAF is insufficiently tested (see CASSANDRA-2241). I'd like to get this up to 100% line coverage. (Not sure what it's actually at right now, since ant codecoverage doesn't work.) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2242) Improve BRAFTest
[ https://issues.apache.org/jira/browse/CASSANDRA-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999310#comment-12999310 ] Pavel Yaskevich commented on CASSANDRA-2242: Sould I wait until CASSANDRA-2241 to be committed? Improve BRAFTest Key: CASSANDRA-2242 URL: https://issues.apache.org/jira/browse/CASSANDRA-2242 Project: Cassandra Issue Type: Test Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.3 BRAF is insufficiently tested (see CASSANDRA-2241). I'd like to get this up to 100% line coverage. (Not sure what it's actually at right now, since ant codecoverage doesn't work.) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2247) Cleanup unused imports and generics
Cleanup unused imports and generics --- Key: CASSANDRA-2247 URL: https://issues.apache.org/jira/browse/CASSANDRA-2247 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Norman Maurer In current cassandra trunk are many classes which import packages which are never used. The same is true for Loggers which are often instanced and then not used. Beside this I see many warnings related to generic usage. Would be nice to clean this up a bit. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2248) ant javadoc fails on windows
ant javadoc fails on windows Key: CASSANDRA-2248 URL: https://issues.apache.org/jira/browse/CASSANDRA-2248 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Norman Maurer When try to run ant javadoc (or any task that include javadoc) on windows it fails with the error: Javadoc failed: java.io.IOException: Cannot run program c:\Program Files\Java\jdk1.6.0_17\bin\javadoc.exe: CreateProcess error=87, The parameter is incorrect -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2248) ant javadoc fails on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated CASSANDRA-2248: - Attachment: CASSANDRA-2248.diff This fix the build on windows. ant javadoc fails on windows Key: CASSANDRA-2248 URL: https://issues.apache.org/jira/browse/CASSANDRA-2248 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Norman Maurer Attachments: CASSANDRA-2248.diff When try to run ant javadoc (or any task that include javadoc) on windows it fails with the error: Javadoc failed: java.io.IOException: Cannot run program c:\Program Files\Java\jdk1.6.0_17\bin\javadoc.exe: CreateProcess error=87, The parameter is incorrect -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2248) ant javadoc fails on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated CASSANDRA-2248: - Environment: windows 7, ant 1.8.2 ant javadoc fails on windows Key: CASSANDRA-2248 URL: https://issues.apache.org/jira/browse/CASSANDRA-2248 Project: Cassandra Issue Type: Bug Components: Packaging Environment: windows 7, ant 1.8.2 Reporter: Norman Maurer Attachments: CASSANDRA-2248.diff When try to run ant javadoc (or any task that include javadoc) on windows it fails with the error: Javadoc failed: java.io.IOException: Cannot run program c:\Program Files\Java\jdk1.6.0_17\bin\javadoc.exe: CreateProcess error=87, The parameter is incorrect -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2248) ant javadoc fails on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999345#comment-12999345 ] Norman Maurer commented on CASSANDRA-2248: -- Related to this: https://issues.apache.org/bugzilla/show_bug.cgi?id=41958 ant javadoc fails on windows Key: CASSANDRA-2248 URL: https://issues.apache.org/jira/browse/CASSANDRA-2248 Project: Cassandra Issue Type: Bug Components: Packaging Environment: windows 7, ant 1.8.2 Reporter: Norman Maurer Attachments: CASSANDRA-2248.diff When try to run ant javadoc (or any task that include javadoc) on windows it fails with the error: Javadoc failed: java.io.IOException: Cannot run program c:\Program Files\Java\jdk1.6.0_17\bin\javadoc.exe: CreateProcess error=87, The parameter is incorrect -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2249) Use correct build version in build.xml
Use correct build version in build.xml -- Key: CASSANDRA-2249 URL: https://issues.apache.org/jira/browse/CASSANDRA-2249 Project: Cassandra Issue Type: Task Components: Packaging Reporter: Norman Maurer Priority: Trivial Fix For: 0.8 Attachments: CASSANDRA-2249.diff build.xml still use 0.7.1 as build version. I think trunk should use 0.8.0 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2249) Use correct build version in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated CASSANDRA-2249: - Attachment: CASSANDRA-2249.diff Bump up version to 0.8.0 Use correct build version in build.xml -- Key: CASSANDRA-2249 URL: https://issues.apache.org/jira/browse/CASSANDRA-2249 Project: Cassandra Issue Type: Task Components: Packaging Reporter: Norman Maurer Priority: Trivial Fix For: 0.8 Attachments: CASSANDRA-2249.diff build.xml still use 0.7.1 as build version. I think trunk should use 0.8.0 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2247) Cleanup unused imports and generics
[ https://issues.apache.org/jira/browse/CASSANDRA-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated CASSANDRA-2247: - Attachment: CASSANDRA-2247-part1.diff First iteration for cleanup stuff. If its ok I will attach patches in chunk so they don'T get to big and contain changes all over the place Cleanup unused imports and generics --- Key: CASSANDRA-2247 URL: https://issues.apache.org/jira/browse/CASSANDRA-2247 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Norman Maurer Attachments: CASSANDRA-2247-part1.diff In current cassandra trunk are many classes which import packages which are never used. The same is true for Loggers which are often instanced and then not used. Beside this I see many warnings related to generic usage. Would be nice to clean this up a bit. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074555 - in /cassandra/branches/cassandra-0.7: ./ src/java/org/apache/cassandra/db/commitlog/ src/java/org/apache/cassandra/io/sstable/ src/java/org/apache/cassandra/io/util/ test/unit/o
Author: jbellis
Date: Fri Feb 25 14:56:57 2011
New Revision: 1074555
URL: http://svn.apache.org/viewvc?rev=1074555view=rev
Log:
fix BufferedRandomAccessFile bugs
patch by jbellis; reviewed by tjake for CASSANDRA-2241
Added:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/sstable/DescriptorTest.java
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/Descriptor.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/BufferedRandomAccessFile.java
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/util/BufferedRandomAccessFileTest.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1074555r1=1074554r2=1074555view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Fri Feb 25 14:56:57 2011
@@ -18,7 +18,7 @@
* add nodetool scrub (CASSANDRA-2217)
* fix sstable2json large-row pagination (CASSANDRA-2188)
* fix EOFing on requests for the last bytes in a file (CASSANDRA-2213)
- * fix BRAF performance when seeking to EOF (CASSANDRA-2218)
+ * fix BufferedRandomAccessFile bugs (CASSANDRA-2218, -2241)
* check for memtable flush_after_mins exceeded every 10s (CASSANDRA-2183)
* fix cache saving on Windows (CASSANDRA-2207)
* add validateSchemaAgreement call + synchronization to schema
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/commitlog/CommitLog.java?rev=1074555r1=1074554r2=1074555view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
Fri Feb 25 14:56:57 2011
@@ -172,7 +172,7 @@ public class CommitLog
for (File file : clogs)
{
-int bufferSize = (int)Math.min(file.length(), 32 * 1024 * 1024);
+int bufferSize = (int) Math.min(Math.max(file.length(), 1), 32 *
1024 * 1024);
BufferedRandomAccessFile reader = new BufferedRandomAccessFile(new
File(file.getAbsolutePath()), r, bufferSize, true);
try
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/Descriptor.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/Descriptor.java?rev=1074555r1=1074554r2=1074555view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/Descriptor.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/Descriptor.java
Fri Feb 25 14:56:57 2011
@@ -76,8 +76,8 @@ public class Descriptor
hasStringsInBloomFilter = version.compareTo(c) 0;
hasIntRowSize = version.compareTo(d) 0;
hasEncodedKeys = version.compareTo(e) 0;
-isLatestVersion = version.compareTo(CURRENT_VERSION) == 0;
usesOldBloomFilter = version.compareTo(f) 0;
+isLatestVersion = version.compareTo(CURRENT_VERSION) == 0;
}
public String filenameFor(Component component)
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/BufferedRandomAccessFile.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/BufferedRandomAccessFile.java?rev=1074555r1=1074554r2=1074555view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/BufferedRandomAccessFile.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/util/BufferedRandomAccessFile.java
Fri Feb 25 14:56:57 2011
@@ -47,16 +47,16 @@ public class BufferedRandomAccessFile ex
public static final int DEFAULT_BUFFER_SIZE = 65535;
// isDirty - true if this.buffer contains any un-synced bytes
-// hitEOF - true if buffer capacity is less then it's maximal size
-private boolean isDirty, syncNeeded, hitEOF = false;
+private boolean isDirty, syncNeeded;
// buffer which will cache file blocks
-private ByteBuffer buffer;
+private byte[] buffer;
// `current` as current position in file
// `bufferOffset` is the offset of the beginning of the buffer
-// `bufferEnd` is `bufferOffset` + count of bytes read from file, i.e. the
lowest
[jira] Commented: (CASSANDRA-2242) Improve BRAFTest
[ https://issues.apache.org/jira/browse/CASSANDRA-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999390#comment-12999390 ] Jonathan Ellis commented on CASSANDRA-2242: --- 2241 is committed now Improve BRAFTest Key: CASSANDRA-2242 URL: https://issues.apache.org/jira/browse/CASSANDRA-2242 Project: Cassandra Issue Type: Test Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 0.7.3 BRAF is insufficiently tested (see CASSANDRA-2241). I'd like to get this up to 100% line coverage. (Not sure what it's actually at right now, since ant codecoverage doesn't work.) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074563 - /cassandra/branches/cassandra-0.7/build.xml
Author: jbellis
Date: Fri Feb 25 15:05:45 2011
New Revision: 1074563
URL: http://svn.apache.org/viewvc?rev=1074563view=rev
Log:
fix ant javadoc on Windows
patch by Norman Maurer; reviewed by jbellis for CASSANDRA-2248
Modified:
cassandra/branches/cassandra-0.7/build.xml
Modified: cassandra/branches/cassandra-0.7/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/build.xml?rev=1074563r1=1074562r2=1074563view=diff
==
--- cassandra/branches/cassandra-0.7/build.xml (original)
+++ cassandra/branches/cassandra-0.7/build.xml Fri Feb 25 15:05:45 2011
@@ -673,6 +673,7 @@
javadoc destdir=${javadoc.dir} author=true version=true use=true
windowtitle=${ant.project.name} API classpathref=cassandra.classpath
bottom=Copyright amp;copy; ${YEAR} The Apache Software Foundation
+ useexternalfile=yes
maxmemory=256m
fileset dir=${build.src.java} defaultexcludes=yes
[jira] Resolved: (CASSANDRA-2248) ant javadoc fails on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2248. --- Resolution: Fixed Fix Version/s: 0.7.3 Reviewer: jbellis Assignee: Norman Maurer committed, thanks! ant javadoc fails on windows Key: CASSANDRA-2248 URL: https://issues.apache.org/jira/browse/CASSANDRA-2248 Project: Cassandra Issue Type: Bug Components: Packaging Environment: windows 7, ant 1.8.2 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.7.3 Attachments: CASSANDRA-2248.diff When try to run ant javadoc (or any task that include javadoc) on windows it fails with the error: Javadoc failed: java.io.IOException: Cannot run program c:\Program Files\Java\jdk1.6.0_17\bin\javadoc.exe: CreateProcess error=87, The parameter is incorrect -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074566 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/commitlog/ src/java/org/apache/cassandra/io/sstable/ src
Author: jbellis
Date: Fri Feb 25 15:07:11 2011
New Revision: 1074566
URL: http://svn.apache.org/viewvc?rev=1074566view=rev
Log:
merge from 0.7
Added:
cassandra/trunk/test/unit/org/apache/cassandra/io/sstable/DescriptorTest.java
- copied unchanged from r1074565,
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/sstable/DescriptorTest.java
Modified:
cassandra/trunk/ (props changed)
cassandra/trunk/CHANGES.txt
cassandra/trunk/build.xml
cassandra/trunk/contrib/ (props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
(props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
(props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java
(props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java
(props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java
(props changed)
cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
cassandra/trunk/src/java/org/apache/cassandra/io/sstable/Descriptor.java
cassandra/trunk/src/java/org/apache/cassandra/io/util/BufferedRandomAccessFile.java
cassandra/trunk/test/unit/org/apache/cassandra/io/util/BufferedRandomAccessFileTest.java
Propchange: cassandra/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Fri Feb 25 15:07:11 2011
@@ -1,5 +1,5 @@
/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1071777
-/cassandra/branches/cassandra-0.7:1026516-1074322
+/cassandra/branches/cassandra-0.7:1026516-1074565
/cassandra/branches/cassandra-0.7.0:1053690-1055654
/cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689
/incubator/cassandra/branches/cassandra-0.3:774578-796573
Modified: cassandra/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1074566r1=1074565r2=1074566view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Fri Feb 25 15:07:11 2011
@@ -30,7 +30,7 @@
* add nodetool scrub (CASSANDRA-2217)
* fix sstable2json large-row pagination (CASSANDRA-2188)
* fix EOFing on requests for the last bytes in a file (CASSANDRA-2213)
- * fix BRAF performance when seeking to EOF (CASSANDRA-2218)
+ * fix BufferedRandomAccessFile bugs (CASSANDRA-2218, -2241)
* check for memtable flush_after_mins exceeded every 10s (CASSANDRA-2183)
* fix cache saving on Windows (CASSANDRA-2207)
* add validateSchemaAgreement call + synchronization to schema
Modified: cassandra/trunk/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/trunk/build.xml?rev=1074566r1=1074565r2=1074566view=diff
==
--- cassandra/trunk/build.xml (original)
+++ cassandra/trunk/build.xml Fri Feb 25 15:07:11 2011
@@ -699,6 +699,7 @@
javadoc destdir=${javadoc.dir} author=true version=true use=true
windowtitle=${ant.project.name} API classpathref=cassandra.classpath
bottom=Copyright amp;copy; ${YEAR} The Apache Software Foundation
+ useexternalfile=yes
maxmemory=256m
fileset dir=${build.src.java} defaultexcludes=yes
Propchange: cassandra/trunk/contrib/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Fri Feb 25 15:07:11 2011
@@ -1,5 +1,5 @@
/cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009
-/cassandra/branches/cassandra-0.7/contrib:1026516-1074322
+/cassandra/branches/cassandra-0.7/contrib:1026516-1074565
/cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654
/cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689
/incubator/cassandra/branches/cassandra-0.3/contrib:774578-796573
Propchange:
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Fri Feb 25 15:07:11 2011
@@ -1,5 +1,5 @@
/cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1071777
-/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1074322
+/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1074565
/cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654
/cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689
svn commit: r1074567 - /cassandra/trunk/build.xml
Author: jbellis
Date: Fri Feb 25 15:07:57 2011
New Revision: 1074567
URL: http://svn.apache.org/viewvc?rev=1074567view=rev
Log:
update version string to 0.8
Modified:
cassandra/trunk/build.xml
Modified: cassandra/trunk/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/trunk/build.xml?rev=1074567r1=1074566r2=1074567view=diff
==
--- cassandra/trunk/build.xml (original)
+++ cassandra/trunk/build.xml Fri Feb 25 15:07:57 2011
@@ -50,7 +50,7 @@
property name=test.long.src value=${test.dir}/long/
property name=test.distributed.src value=${test.dir}/distributed/
property name=dist.dir value=${build.dir}/dist/
-property name=base.version value=0.7.1/
+property name=base.version value=0.8.0/
condition property=version value=${base.version}
isset property=release/
/condition
[jira] Resolved: (CASSANDRA-2249) Use correct build version in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2249. --- Resolution: Fixed Assignee: Norman Maurer committed Use correct build version in build.xml -- Key: CASSANDRA-2249 URL: https://issues.apache.org/jira/browse/CASSANDRA-2249 Project: Cassandra Issue Type: Task Components: Packaging Reporter: Norman Maurer Assignee: Norman Maurer Priority: Trivial Fix For: 0.8 Attachments: CASSANDRA-2249.diff build.xml still use 0.7.1 as build version. I think trunk should use 0.8.0 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074570 - in /cassandra/trunk/src/java/org/apache/cassandra: client/ concurrent/ db/ db/context/ streaming/ thrift/ utils/ utils/obs/
Author: jbellis
Date: Fri Feb 25 15:10:44 2011
New Revision: 1074570
URL: http://svn.apache.org/viewvc?rev=1074570view=rev
Log:
r/m unused imports and parameterize IPartitioner uses
patch by Norman Maurer; reviewed by jbellis for CASSANDRA-2247
Modified:
cassandra/trunk/src/java/org/apache/cassandra/client/RingCache.java
cassandra/trunk/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
cassandra/trunk/src/java/org/apache/cassandra/concurrent/RetryingScheduledThreadPoolExecutor.java
cassandra/trunk/src/java/org/apache/cassandra/db/DeletedColumn.java
cassandra/trunk/src/java/org/apache/cassandra/db/ExpiringColumn.java
cassandra/trunk/src/java/org/apache/cassandra/db/HintedHandOffManager.java
cassandra/trunk/src/java/org/apache/cassandra/db/IMutation.java
cassandra/trunk/src/java/org/apache/cassandra/db/ReadRepairVerbHandler.java
cassandra/trunk/src/java/org/apache/cassandra/db/Row.java
cassandra/trunk/src/java/org/apache/cassandra/db/RowIterator.java
cassandra/trunk/src/java/org/apache/cassandra/db/RowMutationVerbHandler.java
cassandra/trunk/src/java/org/apache/cassandra/db/SliceByNamesReadCommand.java
cassandra/trunk/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
cassandra/trunk/src/java/org/apache/cassandra/db/SuperColumn.java
cassandra/trunk/src/java/org/apache/cassandra/db/Table.java
cassandra/trunk/src/java/org/apache/cassandra/db/context/CounterContext.java
cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamInSession.java
cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamOut.java
cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamingService.java
cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java
cassandra/trunk/src/java/org/apache/cassandra/utils/BloomFilter.java
cassandra/trunk/src/java/org/apache/cassandra/utils/EstimatedHistogram.java
cassandra/trunk/src/java/org/apache/cassandra/utils/ExpiringMap.java
cassandra/trunk/src/java/org/apache/cassandra/utils/GuidGenerator.java
cassandra/trunk/src/java/org/apache/cassandra/utils/LegacyBloomFilter.java
cassandra/trunk/src/java/org/apache/cassandra/utils/StatusLogger.java
cassandra/trunk/src/java/org/apache/cassandra/utils/obs/ArrayUtil.java
Modified: cassandra/trunk/src/java/org/apache/cassandra/client/RingCache.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/client/RingCache.java?rev=1074570r1=1074569r2=1074570view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/client/RingCache.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/client/RingCache.java Fri Feb
25 15:10:44 2011
@@ -52,12 +52,12 @@ public class RingCache
private final SetString seeds_ = new HashSetString();
private final int port_;
-private final IPartitioner partitioner_;
+private final IPartitioner? partitioner_;
private final String keyspace;
private MultimapRange, InetAddress rangeMap;
-public RingCache(String keyspace, IPartitioner partitioner, String
addresses, int port) throws IOException
+public RingCache(String keyspace, IPartitioner? partitioner, String
addresses, int port) throws IOException
{
for (String seed : addresses.split(,))
seeds_.add(seed);
@@ -113,7 +113,6 @@ public class RingCache
}
/** ListMultimap promises to return a List for get(K) */
-@SuppressWarnings(value=unchecked)
public ListInetAddress getEndpoint(Range range)
{
return (ListInetAddress) rangeMap.get(range);
Modified:
cassandra/trunk/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java?rev=1074570r1=1074569r2=1074570view=diff
==
---
cassandra/trunk/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
(original)
+++
cassandra/trunk/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
Fri Feb 25 15:10:44 2011
@@ -80,11 +80,11 @@ public class DebuggableThreadPoolExecuto
super.afterExecute(r,t);
// exceptions wrapped by FutureTask
-if (r instanceof FutureTask)
+if (r instanceof FutureTask?)
{
try
{
-((FutureTask) r).get();
+((FutureTask?) r).get();
}
catch (InterruptedException e)
{
Modified:
cassandra/trunk/src/java/org/apache/cassandra/concurrent/RetryingScheduledThreadPoolExecutor.java
URL:
[jira] Updated: (CASSANDRA-2247) Cleanup unused imports and generics
[ https://issues.apache.org/jira/browse/CASSANDRA-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2247: -- Fix Version/s: 0.8 Assignee: Norman Maurer committed part 1 Cleanup unused imports and generics --- Key: CASSANDRA-2247 URL: https://issues.apache.org/jira/browse/CASSANDRA-2247 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.8 Attachments: CASSANDRA-2247-part1.diff In current cassandra trunk are many classes which import packages which are never used. The same is true for Loggers which are often instanced and then not used. Beside this I see many warnings related to generic usage. Would be nice to clean this up a bit. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2104) IndexOutOfBoundsException during lazy row compaction (using TimeUUID comparator)
[
https://issues.apache.org/jira/browse/CASSANDRA-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999401#comment-12999401
]
Hudson commented on CASSANDRA-2104:
---
Integrated in Cassandra-0.7 #321 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.7/321/])
IndexOutOfBoundsException during lazy row compaction (using TimeUUID
comparator)
Key: CASSANDRA-2104
URL: https://issues.apache.org/jira/browse/CASSANDRA-2104
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0
Reporter: Daniel Lundin
Assignee: Sylvain Lebresne
Fix For: 0.7.3
Attachments:
0001-Use-the-right-comparator-when-deserializing-superCol.patch,
Unit-test.patch
I ran into an exception when lazily compacting wide rows of TimeUUID columns.
It seems to trigger when a row is larger than
{{in_memory_compaction_limit_in_mb}}.
Traceback:
{noformat}
INFO [CompactionExecutor:1] 2011-02-03 10:59:59,262 CompactionIterator.java
(line 135) Compacting large row X (76999384 bytes) incrementally
ERROR [CompactionExecutor:1] 2011-02-03 10:59:59,266
AbstractCassandraDaemon.java (line 114) Fatal exception in thread T
hread[CompactionExecutor:1,1,main]
java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Buffer.java:514)
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:121)
at
org.apache.cassandra.db.marshal.TimeUUIDType.compareTimestampBytes(TimeUUIDType.java:56)
at
org.apache.cassandra.db.marshal.TimeUUIDType.compare(TimeUUIDType.java:45)
at
org.apache.cassandra.db.marshal.TimeUUIDType.compare(TimeUUIDType.java:29)
at
java.util.concurrent.ConcurrentSkipListMap$ComparableUsingComparator.compareTo(ConcurrentSkipListMap.java:606
)
at
java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:685)
at
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:864)
at
java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1893)
at
org.apache.cassandra.db.SuperColumn.addColumn(SuperColumn.java:170)
at
org.apache.cassandra.db.SuperColumn.putColumn(SuperColumn.java:195)
at
org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:221)
at
org.apache.cassandra.io.LazilyCompactedRow$LazyColumnIterator.reduce(LazilyCompactedRow.java:204)
at
org.apache.cassandra.io.LazilyCompactedRow$LazyColumnIterator.reduce(LazilyCompactedRow.java:185)
at
org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:62)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131)
at
com.google.common.collect.Iterators$7.computeNext(Iterators.java:604)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131)
at
org.apache.cassandra.db.ColumnIndexer.serializeInternal(ColumnIndexer.java:76)
at
org.apache.cassandra.db.ColumnIndexer.serialize(ColumnIndexer.java:50)
at
org.apache.cassandra.io.LazilyCompactedRow.init(LazilyCompactedRow.java:88)
at
org.apache.cassandra.io.CompactionIterator.getCompactedRow(CompactionIterator.java:137)
at
org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:108)
at
org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:43)
at
org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:73)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131)
at
org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183)
at
org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94)
at
org.apache.cassandra.db.CompactionManager.doCompaction(CompactionManager.java:426)
at
org.apache.cassandra.db.CompactionManager$1.call(CompactionManager.java:122)
at
org.apache.cassandra.db.CompactionManager$1.call(CompactionManager.java:92)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
[jira] Commented: (CASSANDRA-2237) cassandra.bat does fail when CASSANDRA_HOME contains a whitespace
[ https://issues.apache.org/jira/browse/CASSANDRA-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999398#comment-12999398 ] Hudson commented on CASSANDRA-2237: --- Integrated in Cassandra-0.7 #321 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/321/]) cassandra.bat does fail when CASSANDRA_HOME contains a whitespace - Key: CASSANDRA-2237 URL: https://issues.apache.org/jira/browse/CASSANDRA-2237 Project: Cassandra Issue Type: Bug Components: Packaging Environment: windows Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.7.3 Attachments: CASSANDRA-2237.diff If you try to start cassandra from a directory with whitespaces you will see a stacktrace similar to this: Starting Cassandra Server Exception in thread main java.lang.NoClassDefFoundError: and Caused by: java.lang.ClassNotFoundException: and at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:303) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316) Could not find the main class: and. Program will exit. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2241) BRAF read can loop infinitely instead of detecting EOF
[ https://issues.apache.org/jira/browse/CASSANDRA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999399#comment-12999399 ] Hudson commented on CASSANDRA-2241: --- Integrated in Cassandra-0.7 #321 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/321/]) fix BufferedRandomAccessFile bugs patch by jbellis; reviewed by tjake for CASSANDRA-2241 BRAF read can loop infinitely instead of detecting EOF -- Key: CASSANDRA-2241 URL: https://issues.apache.org/jira/browse/CASSANDRA-2241 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.3 Attachments: 2241.txt (marking this Minor since normally we never try to read past the end of an SSTable, but CASSANDRA-2240 is running into it.) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2232) Clean up and document EstimatedHistogram
[ https://issues.apache.org/jira/browse/CASSANDRA-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999400#comment-12999400 ] Hudson commented on CASSANDRA-2232: --- Integrated in Cassandra-0.7 #321 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/321/]) Clean up and document EstimatedHistogram Key: CASSANDRA-2232 URL: https://issues.apache.org/jira/browse/CASSANDRA-2232 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.3 Attachments: 2232.txt EstimatedHistogram treats adding value n as adding a value infinitesimally greater than n. This barely made sense for the original goal of latency tracking but is clearly broken for inherently integral data like sstables-per-read. Also, median() is broken, but even a non-broken median() would not be correct to use in mean row size reporting which is its only caller. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2248) ant javadoc fails on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999408#comment-12999408 ] Hudson commented on CASSANDRA-2248: --- Integrated in Cassandra-0.7 #322 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/322/]) fix ant javadoc on Windows patch by Norman Maurer; reviewed by jbellis for CASSANDRA-2248 ant javadoc fails on windows Key: CASSANDRA-2248 URL: https://issues.apache.org/jira/browse/CASSANDRA-2248 Project: Cassandra Issue Type: Bug Components: Packaging Environment: windows 7, ant 1.8.2 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.7.3 Attachments: CASSANDRA-2248.diff When try to run ant javadoc (or any task that include javadoc) on windows it fails with the error: Javadoc failed: java.io.IOException: Cannot run program c:\Program Files\Java\jdk1.6.0_17\bin\javadoc.exe: CreateProcess error=87, The parameter is incorrect -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1550) enable/disable HH via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999418#comment-12999418 ] Jonathan Ellis commented on CASSANDRA-1550: --- the StorageProxy mbean is created once requests start arriving enable/disable HH via JMX - Key: CASSANDRA-1550 URL: https://issues.apache.org/jira/browse/CASSANDRA-1550 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.6.6, 0.7 beta 3 Attachments: 1550.txt -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999426#comment-12999426 ] Vivek Mishra commented on CASSANDRA-2124: - Facing 1 issue with LongType decoder: Query i am trying: UPDATE IndexedTable SET \birthdate\ = 1000L WHERE KEY = 100L. Was giving issue for long type. Looking further i can see that QueryProcessor-batchUpdate() method. validateColumn is called with column.getKey().getByteBuffer() as a parameter. Should it be column.getValue().getByteBuffer()? Not sure but i was able to parse query successfully with this change. Should we validate column value rather than it's name? But still for selectquery SELECT \birthdate\ FROM IndexedTable WHERE KEY=100L. It is same error. Again it is same thing, Should we validate column value rather than it's name? QueryProcessor-getSlice method is doing the same. Suggest, if i am trying with CQL in incorrect way. JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074616 - in /cassandra/branches/cassandra-0.7: conf/log4j-server.properties src/java/org/apache/cassandra/db/CompactionManager.java
Author: jbellis
Date: Fri Feb 25 16:22:14 2011
New Revision: 1074616
URL: http://svn.apache.org/viewvc?rev=1074616view=rev
Log:
add some debug logging to scrub
Modified:
cassandra/branches/cassandra-0.7/conf/log4j-server.properties
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java
Modified: cassandra/branches/cassandra-0.7/conf/log4j-server.properties
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/conf/log4j-server.properties?rev=1074616r1=1074615r2=1074616view=diff
==
--- cassandra/branches/cassandra-0.7/conf/log4j-server.properties (original)
+++ cassandra/branches/cassandra-0.7/conf/log4j-server.properties Fri Feb 25
16:22:14 2011
@@ -18,7 +18,7 @@
# (%l is slower.)
# output messages into a rolling log file as well as stdout
-log4j.rootLogger=INFO,stdout,R
+log4j.rootLogger=DEBUG,stdout,R
# stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java?rev=1074616r1=1074615r2=1074616view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/CompactionManager.java
Fri Feb 25 16:22:14 2011
@@ -514,11 +514,8 @@ public class CompactionManager implement
String compactionFileLocation =
cfs.table.getDataFileLocation(sstable.length());
if (compactionFileLocation == null)
throw new IOException(disk full);
-
int expectedBloomFilterSize =
Math.max(DatabaseDescriptor.getIndexInterval(),
(int)(SSTableReader.getApproximateKeyCount(Arrays.asList(sstable;
-if (logger.isDebugEnabled())
- logger.debug(Expected bloom filter size : +
expectedBloomFilterSize);
// loop through each row, deserializing to check for damage.
// we'll also loop through the index at the same time, using the
position from the index to recover if the
@@ -536,6 +533,8 @@ public class CompactionManager implement
while (!dataFile.isEOF())
{
long rowStart = dataFile.getFilePointer();
+if (logger.isDebugEnabled())
+logger.debug(Reading row at + rowStart);
DecoratedKey key =
SSTableReader.decodeKey(sstable.partitioner, sstable.descriptor,
ByteBufferUtil.readWithShortLength(dataFile));
ByteBuffer currentIndexKey = nextIndexKey;
nextIndexKey = indexFile.isEOF() ? null :
ByteBufferUtil.readWithShortLength(indexFile);
@@ -543,6 +542,8 @@ public class CompactionManager implement
long dataSize = sstable.descriptor.hasIntRowSize ?
dataFile.readInt() : dataFile.readLong();
long dataStart = dataFile.getFilePointer();
+if (logger.isDebugEnabled())
+logger.debug(String.format(row %s is %s bytes,
ByteBufferUtil.bytesToHex(key.key), dataSize));
SSTableIdentityIterator row = new
SSTableIdentityIterator(sstable, dataFile, key, dataStart, dataSize, true);
writer.mark();
svn commit: r1074617 - /cassandra/branches/cassandra-0.7/conf/log4j-server.properties
Author: jbellis Date: Fri Feb 25 16:22:35 2011 New Revision: 1074617 URL: http://svn.apache.org/viewvc?rev=1074617view=rev Log: revert log level commit Modified: cassandra/branches/cassandra-0.7/conf/log4j-server.properties Modified: cassandra/branches/cassandra-0.7/conf/log4j-server.properties URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/conf/log4j-server.properties?rev=1074617r1=1074616r2=1074617view=diff == --- cassandra/branches/cassandra-0.7/conf/log4j-server.properties (original) +++ cassandra/branches/cassandra-0.7/conf/log4j-server.properties Fri Feb 25 16:22:35 2011 @@ -18,7 +18,7 @@ # (%l is slower.) # output messages into a rolling log file as well as stdout -log4j.rootLogger=DEBUG,stdout,R +log4j.rootLogger=INFO,stdout,R # stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender
[jira] Updated: (CASSANDRA-2240) nodetool scrub hangs or throws an exception
[ https://issues.apache.org/jira/browse/CASSANDRA-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2240: -- Affects Version/s: 0.7.3 Fix Version/s: 0.7.3 Couldn't reproduce by scrubbing sstables produced by 0.6 stress.py nodetool scrub hangs or throws an exception --- Key: CASSANDRA-2240 URL: https://issues.apache.org/jira/browse/CASSANDRA-2240 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.3 Environment: using build #314 from hudson Reporter: Yaniv Kunda Assignee: Jonathan Ellis Fix For: 0.7.3 Attachments: test-0.6.x-tables.tar.gz trying to run nodetool scrub hung or (only happened one time) threw the following exception: Error occured while scrubbing keyspace mykeyspace java.util.concurrent.ExecutionException: java.lang.AssertionError at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) at java.util.concurrent.FutureTask.get(FutureTask.java:111) at org.apache.cassandra.db.CompactionManager.performScrub(CompactionManager.java:203) at org.apache.cassandra.db.ColumnFamilyStore.scrub(ColumnFamilyStore.java:934) at org.apache.cassandra.service.StorageService.scrub(StorageService.java:1247) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.AssertionError at org.apache.cassandra.dht.RandomPartitioner.convertFromDiskFormat(RandomPartitioner.java:62) at org.apache.cassandra.io.sstable.SSTableReader.decodeKey(SSTableReader.java:627) at org.apache.cassandra.db.CompactionManager.doScrub(CompactionManager.java:541) at org.apache.cassandra.db.CompactionManager.access$600(CompactionManager.java:55) at org.apache.cassandra.db.CompactionManager$3.call(CompactionManager.java:194) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) ... 3 more -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2176) Add configuration setting to cap the number of Thrift connections
[ https://issues.apache.org/jira/browse/CASSANDRA-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999451#comment-12999451 ] Jonathan Ellis commented on CASSANDRA-2176: --- There's three options for capping the number of connections: - close the listening socket - leave the socket open but stop accept()ing connections - accept new connections, send an error message, then close them The third option is generally seen as best (some discussion: http://fixunix.com/unix/379049-server-socket-how-limit-number-connections.html) but Thrift doesn't give us a way to send an error w/o first processing a request. So I'm wondering if we should go with option 2 instead -- timed out trying to connect seems more straightforward than option 1 (indistinguishable from cassandra not running) or option 3 (which makes it easy to do the wrong thing on the client side -- i.e. a naive client may immediately try to reconnect). Thoughts? Add configuration setting to cap the number of Thrift connections - Key: CASSANDRA-2176 URL: https://issues.apache.org/jira/browse/CASSANDRA-2176 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.3 Attachments: 0001-CASSANDRA-2176-limit-connected-clients-and-config.txt Original Estimate: 4h Remaining Estimate: 4h At least until CASSANDRA-1405 is done, it's useful to have a connection cap to prevent misbehaving clients from DOSing the server. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1311) Support (asynchronous) triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999453#comment-12999453 ] Maxim Grinev commented on CASSANDRA-1311: - Jonathan, are we right that you are mainly concerned about the inconsistency problem we were discussing earlier? To repeat, the problem was that if a write has not been acknowledged, it may still have succeeded in the base columnfamily (Table.apply) but the trigger is stored durably (TriggerSlave.storeDanglingTrigger). It is because trigger execution is not part of log replay. So we can end up with data that never had the trigger fire. As Stu said, using entity groups to solve this problem is suboptimal. We want to propose an improvement of our approach that also solves this problem but does not introduce the restrictions of entity groups. Our solution is to make the storage of dangling trigger at replicas also part of log replay. Whenever a replica (slave) node receives a write request, it will durably log that it has to fire a trigger in case of a failure of the update coordinator (master). In case this slave node fails, it will come back up replaying the logs, installing any data item, and also firing triggers. Once again, our point is to avoid entity group whenever possible for the following two reasons. (1) Entity groups are restrictive because they require co-location of data. This is hard to achieve in practice and not all application can be implemented this. For example, it is not possible to implement Twitter as it would require to co-locate users with their followers ending up with a single, big entity group. (2) Even in case when you can use entity groups, you usually need to update redundant data stored in other entity groups as well. In this case, triggers may be used to keep redundant data consistent across entity groups. Support (asynchronous) triggers --- Key: CASSANDRA-1311 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 Project: Cassandra Issue Type: New Feature Components: Contrib Reporter: Maxim Grinev Fix For: 0.8 Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf, ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Please find the motivation, triggers description and list of applications: http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ An example of using triggers for indexing: http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ Implementation details are attached. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2176) Add configuration setting to cap the number of Thrift connections
[ https://issues.apache.org/jira/browse/CASSANDRA-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999466#comment-12999466 ] Nate McCall commented on CASSANDRA-2176: I think I would prefer to get a TimeoutException back as this falls into the general category of that node is pretty busy right now and I would take the same avoidance strategy as with other TimeoutException cases. Add configuration setting to cap the number of Thrift connections - Key: CASSANDRA-2176 URL: https://issues.apache.org/jira/browse/CASSANDRA-2176 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.3 Attachments: 0001-CASSANDRA-2176-limit-connected-clients-and-config.txt Original Estimate: 4h Remaining Estimate: 4h At least until CASSANDRA-1405 is done, it's useful to have a connection cap to prevent misbehaving clients from DOSing the server. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2250) BufferedRandomAccessFile.read(byte[], int, int) method reads max DEFAULT_BUFFER_SIZE
BufferedRandomAccessFile.read(byte[], int, int) method reads max
DEFAULT_BUFFER_SIZE
Key: CASSANDRA-2250
URL: https://issues.apache.org/jira/browse/CASSANDRA-2250
Project: Cassandra
Issue Type: Sub-task
Reporter: Pavel Yaskevich
Assignee: Jonathan Ellis
Test to reproduce:
{code}
File tempFile = File.createTempFile(braf, null);
tempFile.deleteOnExit();
BufferedRandomAccessFile file = new BufferedRandomAccessFile(tempFile, rw);
byte[] bigData = new byte[BufferedRandomAccessFile.DEFAULT_BUFFER_SIZE + 10];
for (int i = 0; i bigData.length; i++)
bigData[i] = 'd';
long initialPosition = file.getFilePointer();
file.write(bigData); // writing data
assert file.getFilePointer() == initialPosition + bigData.length;
assert file.length() == initialPosition + bigData.length; // file size should
equals to last position
// reading written buffer
file.seek(initialPosition);
data = new byte[bigData.length];
assert file.read(data) == data.length; -- Fails (returns DEFAULT_BUFFER_SIZE
as file.read(..) result)
{code}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2176) Add configuration setting to cap the number of Thrift connections
[ https://issues.apache.org/jira/browse/CASSANDRA-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999471#comment-12999471 ] Jonathan Ellis commented on CASSANDRA-2176: --- If we could return an exception then we would make a separate exception class for it. But we can't, because Thrift RPC isn't designed to allow returning anything (an exception is just a special return value over the socket) except in response to a method call. Add configuration setting to cap the number of Thrift connections - Key: CASSANDRA-2176 URL: https://issues.apache.org/jira/browse/CASSANDRA-2176 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.3 Attachments: 0001-CASSANDRA-2176-limit-connected-clients-and-config.txt Original Estimate: 4h Remaining Estimate: 4h At least until CASSANDRA-1405 is done, it's useful to have a connection cap to prevent misbehaving clients from DOSing the server. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CASSANDRA-2250) BufferedRandomAccessFile.read(byte[], int, int) method reads max DEFAULT_BUFFER_SIZE
[
https://issues.apache.org/jira/browse/CASSANDRA-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-2250.
---
Resolution: Invalid
Fix Version/s: (was: 0.7.3)
Assignee: (was: Jonathan Ellis)
BRAF's behavior is acceptable. RAF.read javadoc says reads *up to* len bytes
of data from this file... returns the total number of bytes read into the
buffer.
If you want keep issuing read() calls until the requested length is satisfied
you need to use readFully(). read() is for give me whatever you can most
efficiently.
BufferedRandomAccessFile.read(byte[], int, int) method reads max
DEFAULT_BUFFER_SIZE
Key: CASSANDRA-2250
URL: https://issues.apache.org/jira/browse/CASSANDRA-2250
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Pavel Yaskevich
Test to reproduce:
{code}
File tempFile = File.createTempFile(braf, null);
tempFile.deleteOnExit();
BufferedRandomAccessFile file = new BufferedRandomAccessFile(tempFile, rw);
byte[] bigData = new byte[BufferedRandomAccessFile.DEFAULT_BUFFER_SIZE + 10];
for (int i = 0; i bigData.length; i++)
bigData[i] = 'd';
long initialPosition = file.getFilePointer();
file.write(bigData); // writing data
assert file.getFilePointer() == initialPosition + bigData.length;
assert file.length() == initialPosition + bigData.length; // file size should
equals to last position
// reading written buffer
file.seek(initialPosition);
data = new byte[bigData.length];
assert file.read(data) == data.length; -- Fails (returns DEFAULT_BUFFER_SIZE
as file.read(..) result)
{code}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999475#comment-12999475
]
Eric Evans commented on CASSANDRA-2124:
---
{quote}
Facing 1 issue with LongType decoder:
Query i am trying:
UPDATE IndexedTable SET \birthdate\ = 1000L WHERE KEY = 100L.
Was giving issue for long type. Looking further i can see that
{quote}
What kind of issue are you having? What is the comparator for this column
family (applied to column names)? What is the default validator, or the
specific one for column birthdate (applies to column values)?
{quote}
QueryProcessor-batchUpdate() method.
validateColumn is called with column.getKey().getByteBuffer() as a parameter.
Should it be
column.getValue().getByteBuffer()? Not sure but i was able to parse query
successfully with this change.
{quote}
This is looping over {{Map.Entry}} columns, so {{getKey()}} is returning the
column name, and {{getValue()}} the column value.
{quote}
Should we validate column value rather than it's name?
But still for selectquery
SELECT \birthdate\ FROM IndexedTable WHERE KEY=100L. It is same error.
Again it is same thing, Should we validate column value rather than it's name?
QueryProcessor-getSlice method is doing the same.
Suggest, if i am trying with CQL in incorrect way.
{quote}
Both column names and values are validated against subclasses of
{{o.a.c.marshal.AbstractType}}, configured as comparators or validators
respectively.
JDBC driver for CQL
---
Key: CASSANDRA-2124
URL: https://issues.apache.org/jira/browse/CASSANDRA-2124
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Eric Evans
Assignee: Vivek Mishra
Priority: Minor
Labels: cql
Attachments: Cassandra-2124_v1.0, cassandra-0.7.1-2124_v2.0,
cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch
A simple connection class and corresponding pool was created for CQL as a
part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a
replacement for) would also be interesting.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2250) BufferedRandomAccessFile.read(byte[], int, int) method reads max DEFAULT_BUFFER_SIZE
[
https://issues.apache.org/jira/browse/CASSANDRA-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999478#comment-12999478
]
Pavel Yaskevich commented on CASSANDRA-2250:
On my opinion return less than length bytes is acceptable if file does not
contain all required length, relying on DEFAULT_BUFFER_SIZE as max length makes
bytes(byte[], int, int) and bytes(byte[]) useless
BufferedRandomAccessFile.read(byte[], int, int) method reads max
DEFAULT_BUFFER_SIZE
Key: CASSANDRA-2250
URL: https://issues.apache.org/jira/browse/CASSANDRA-2250
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Pavel Yaskevich
Test to reproduce:
{code}
File tempFile = File.createTempFile(braf, null);
tempFile.deleteOnExit();
BufferedRandomAccessFile file = new BufferedRandomAccessFile(tempFile, rw);
byte[] bigData = new byte[BufferedRandomAccessFile.DEFAULT_BUFFER_SIZE + 10];
for (int i = 0; i bigData.length; i++)
bigData[i] = 'd';
long initialPosition = file.getFilePointer();
file.write(bigData); // writing data
assert file.getFilePointer() == initialPosition + bigData.length;
assert file.length() == initialPosition + bigData.length; // file size should
equals to last position
// reading written buffer
file.seek(initialPosition);
data = new byte[bigData.length];
assert file.read(data) == data.length; -- Fails (returns DEFAULT_BUFFER_SIZE
as file.read(..) result)
{code}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2250) BufferedRandomAccessFile.read(byte[], int, int) method reads max DEFAULT_BUFFER_SIZE
[
https://issues.apache.org/jira/browse/CASSANDRA-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999482#comment-12999482
]
Jonathan Ellis commented on CASSANDRA-2250:
---
I don't see a point in introducing non-standard differences in the contract
BRAF provides vs RAF.
Again, use readFully (the DataInput api) if you want that behavior. read is
deliberately not defined that way.
BufferedRandomAccessFile.read(byte[], int, int) method reads max
DEFAULT_BUFFER_SIZE
Key: CASSANDRA-2250
URL: https://issues.apache.org/jira/browse/CASSANDRA-2250
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Pavel Yaskevich
Test to reproduce:
{code}
File tempFile = File.createTempFile(braf, null);
tempFile.deleteOnExit();
BufferedRandomAccessFile file = new BufferedRandomAccessFile(tempFile, rw);
byte[] bigData = new byte[BufferedRandomAccessFile.DEFAULT_BUFFER_SIZE + 10];
for (int i = 0; i bigData.length; i++)
bigData[i] = 'd';
long initialPosition = file.getFilePointer();
file.write(bigData); // writing data
assert file.getFilePointer() == initialPosition + bigData.length;
assert file.length() == initialPosition + bigData.length; // file size should
equals to last position
// reading written buffer
file.seek(initialPosition);
data = new byte[bigData.length];
assert file.read(data) == data.length; -- Fails (returns DEFAULT_BUFFER_SIZE
as file.read(..) result)
{code}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2100) Restart required to change cache_save_period
[
https://issues.apache.org/jira/browse/CASSANDRA-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999489#comment-12999489
]
Jon Hermes commented on CASSANDRA-2100:
---
2100-2.txt works fine when the schema changes.
`if (!clientMode) { CFS.reload() }` will reset the config appropriately, and
it's good we don't do anything when clientMode because we don't apply() from
migration in that case as well (and there would be nothing to reset).
From your comment I thought that something didn't work. Don't scare me like
that. :P
Restart required to change cache_save_period
Key: CASSANDRA-2100
URL: https://issues.apache.org/jira/browse/CASSANDRA-2100
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0
Reporter: Nick Bailey
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.3
Attachments: 2100-2.txt, 2100-3.txt, 2100.txt
Original Estimate: 2h
Remaining Estimate: 2h
The cache_save_period is set in the schema for each column family. However
this value is only checked when a node starts up so changing this value isn't
really dynamic.
We should actually change this when the schema changes instead of having to
restart.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2151) StorageService MBean has operations with byte[] in signature and can not be called from JConsole
[ https://issues.apache.org/jira/browse/CASSANDRA-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2151: -- Attachment: v1-0001-CASSANDRA-2151-raise-IRE-for-null-keyspace-argument.txt StorageService MBean has operations with byte[] in signature and can not be called from JConsole Key: CASSANDRA-2151 URL: https://issues.apache.org/jira/browse/CASSANDRA-2151 Project: Cassandra Issue Type: New Feature Reporter: Edward Capriolo Assignee: Edward Capriolo Priority: Minor Attachments: v1-0001-CASSANDRA-2151-raise-IRE-for-null-keyspace-argument.txt Many operations in storageService have byte[] or String[] in there method signature. This makes them not usable from JConsole. Ideally having access to all of these functions would be idea, but for starters I would like to have access to getNaturalEndoints to be able to determine where keys are stored. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2251:
--
Attachment: v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace-argument.txt
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
Attachments:
v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace-argument.txt
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2151) StorageService MBean has operations with byte[] in signature and can not be called from JConsole
[ https://issues.apache.org/jira/browse/CASSANDRA-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2151: -- Attachment: (was: v1-0001-CASSANDRA-2151-raise-IRE-for-null-keyspace-argument.txt) StorageService MBean has operations with byte[] in signature and can not be called from JConsole Key: CASSANDRA-2151 URL: https://issues.apache.org/jira/browse/CASSANDRA-2151 Project: Cassandra Issue Type: New Feature Reporter: Edward Capriolo Assignee: Edward Capriolo Priority: Minor Many operations in storageService have byte[] or String[] in there method signature. This makes them not usable from JConsole. Ideally having access to all of these functions would be idea, but for starters I would like to have access to getNaturalEndoints to be able to determine where keys are stored. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2250) BufferedRandomAccessFile.read(byte[], int, int) method reads max DEFAULT_BUFFER_SIZE
[
https://issues.apache.org/jira/browse/CASSANDRA-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999491#comment-12999491
]
Pavel Yaskevich commented on CASSANDRA-2250:
I just want to point out that in this situation using RAF and BRAF you will get
different result as RAF.read(byte[]) will read data.length (expected by
developer as you know how match data you wrote) even if it's not guarantied
directly by documentation.
BufferedRandomAccessFile.read(byte[], int, int) method reads max
DEFAULT_BUFFER_SIZE
Key: CASSANDRA-2250
URL: https://issues.apache.org/jira/browse/CASSANDRA-2250
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Pavel Yaskevich
Test to reproduce:
{code}
File tempFile = File.createTempFile(braf, null);
tempFile.deleteOnExit();
BufferedRandomAccessFile file = new BufferedRandomAccessFile(tempFile, rw);
byte[] bigData = new byte[BufferedRandomAccessFile.DEFAULT_BUFFER_SIZE + 10];
for (int i = 0; i bigData.length; i++)
bigData[i] = 'd';
long initialPosition = file.getFilePointer();
file.write(bigData); // writing data
assert file.getFilePointer() == initialPosition + bigData.length;
assert file.length() == initialPosition + bigData.length; // file size should
equals to last position
// reading written buffer
file.seek(initialPosition);
data = new byte[bigData.length];
assert file.read(data) == data.length; -- Fails (returns DEFAULT_BUFFER_SIZE
as file.read(..) result)
{code}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1967) commit log replay shouldn't end with a flush
[ https://issues.apache.org/jira/browse/CASSANDRA-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999496#comment-12999496 ] Norman Maurer commented on CASSANDRA-1967: -- Maybe related to this.. I think if we keep the flush we should remove the commitlog file (segement) as soon as it was replayed. At the moment the file get deleted after all segements was replayed. At the moment it would be possible to have 19 segements replayed then on the 20th segement it throw an exception and so no file would get deleted. Which would lead to a complete replay of the previous 19 files on next start. commit log replay shouldn't end with a flush Key: CASSANDRA-1967 URL: https://issues.apache.org/jira/browse/CASSANDRA-1967 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.3 Reporter: Robert Coli (Apologies in advance if there is some very compelling reason to flush after replay, of which I am not currently aware. ;D) Currently, when a node restarts, the following sequence occurs : a) commitlog is replayed b) any memtables resulting from a) are flushed c) a new commitlog is opened, new memtables are switched in ... (other stuff happens) d) node starts taking traffic This has side effects, perhaps most seriously the potential of triggering compaction. As a node is likely to struggle performance-wise after restarting, triggering compaction at that time seems like something we might wish to avoid. I propose that the sequence be : a) commitlog is replayed b) a new commitlog is opened, new memtables are switched in ... (other stuff happens) c) node starts taking traffic Looking through the relevant code, the only code that appears to depend on this flush is at src/java/org/apache/cassandra/db/commitlog/CommitLog.java:112 : // all old segments are recovered and deleted before CommitLog is instantiated. // All we need to do is create a new one. segments.add(new CommitLogSegment()); Presumably this code would have to be refactored to be aware of the currently open commitlog. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999494#comment-12999494
]
Vivek Mishra commented on CASSANDRA-2124:
-
This is the definition for columnFamily.
- name: IndexedTable
compare_with: LongType
issue is:
{why: expected 8 or 0 long(9)}. something like this.
Yes. i can see that both are validated. but from batchUpdate method, call is
validateColumn(keyspace, update.getColumnFamily(),
column.getKey().getByteBuffer());
giving me error like
{why: expected 8 or 0 long(9)}.
I belive this is only validating column name not it's value.
JDBC driver for CQL
---
Key: CASSANDRA-2124
URL: https://issues.apache.org/jira/browse/CASSANDRA-2124
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Eric Evans
Assignee: Vivek Mishra
Priority: Minor
Labels: cql
Attachments: Cassandra-2124_v1.0, cassandra-0.7.1-2124_v2.0,
cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch
A simple connection class and corresponding pool was created for CQL as a
part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a
replacement for) would also be interesting.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2176) Add configuration setting to cap the number of Thrift connections
[ https://issues.apache.org/jira/browse/CASSANDRA-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2176: -- Attachment: 2176-v2.txt v2 implements option 2 and adds an explanation to cassandra.yaml Add configuration setting to cap the number of Thrift connections - Key: CASSANDRA-2176 URL: https://issues.apache.org/jira/browse/CASSANDRA-2176 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.3 Attachments: 0001-CASSANDRA-2176-limit-connected-clients-and-config.txt, 2176-v2.txt Original Estimate: 4h Remaining Estimate: 4h At least until CASSANDRA-1405 is done, it's useful to have a connection cap to prevent misbehaving clients from DOSing the server. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2176) Add configuration setting to cap the number of Thrift connections
[ https://issues.apache.org/jira/browse/CASSANDRA-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2176: -- Attachment: 2176-v2.txt oops, didn't remove the original post-accept check there. better v2 attached. Add configuration setting to cap the number of Thrift connections - Key: CASSANDRA-2176 URL: https://issues.apache.org/jira/browse/CASSANDRA-2176 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.3 Attachments: 0001-CASSANDRA-2176-limit-connected-clients-and-config.txt, 2176-v2.txt Original Estimate: 4h Remaining Estimate: 4h At least until CASSANDRA-1405 is done, it's useful to have a connection cap to prevent misbehaving clients from DOSing the server. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2176) Add configuration setting to cap the number of Thrift connections
[ https://issues.apache.org/jira/browse/CASSANDRA-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2176: -- Attachment: (was: 2176-v2.txt) Add configuration setting to cap the number of Thrift connections - Key: CASSANDRA-2176 URL: https://issues.apache.org/jira/browse/CASSANDRA-2176 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.3 Attachments: 0001-CASSANDRA-2176-limit-connected-clients-and-config.txt, 2176-v2.txt Original Estimate: 4h Remaining Estimate: 4h At least until CASSANDRA-1405 is done, it's useful to have a connection cap to prevent misbehaving clients from DOSing the server. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999520#comment-12999520
]
Jonathan Ellis commented on CASSANDRA-2251:
---
maybe we should move the check into getKeyspace? there's a bunch of callers
that don't call vCF afterwards.
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
Attachments:
v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace-argument.txt
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1967) commit log replay shouldn't end with a flush
[ https://issues.apache.org/jira/browse/CASSANDRA-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999522#comment-12999522 ] Jonathan Ellis commented on CASSANDRA-1967: --- Right. What we have now is sort of a compromise between never flush at all and flush after each segment is replayed. commit log replay shouldn't end with a flush Key: CASSANDRA-1967 URL: https://issues.apache.org/jira/browse/CASSANDRA-1967 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.3 Reporter: Robert Coli (Apologies in advance if there is some very compelling reason to flush after replay, of which I am not currently aware. ;D) Currently, when a node restarts, the following sequence occurs : a) commitlog is replayed b) any memtables resulting from a) are flushed c) a new commitlog is opened, new memtables are switched in ... (other stuff happens) d) node starts taking traffic This has side effects, perhaps most seriously the potential of triggering compaction. As a node is likely to struggle performance-wise after restarting, triggering compaction at that time seems like something we might wish to avoid. I propose that the sequence be : a) commitlog is replayed b) a new commitlog is opened, new memtables are switched in ... (other stuff happens) c) node starts taking traffic Looking through the relevant code, the only code that appears to depend on this flush is at src/java/org/apache/cassandra/db/commitlog/CommitLog.java:112 : // all old segments are recovered and deleted before CommitLog is instantiated. // All we need to do is create a new one. segments.add(new CommitLogSegment()); Presumably this code would have to be refactored to be aware of the currently open commitlog. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2250) BufferedRandomAccessFile.read(byte[], int, int) method reads max DEFAULT_BUFFER_SIZE
[
https://issues.apache.org/jira/browse/CASSANDRA-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999521#comment-12999521
]
Jonathan Ellis commented on CASSANDRA-2250:
---
That's fine.
I suspect that even RAF.read will return less than requested if the underlying
read system call is interrupted, for instance, but I don't care to dig deeper.
Correct code shouldn't rely on read == readFully.
BufferedRandomAccessFile.read(byte[], int, int) method reads max
DEFAULT_BUFFER_SIZE
Key: CASSANDRA-2250
URL: https://issues.apache.org/jira/browse/CASSANDRA-2250
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Pavel Yaskevich
Test to reproduce:
{code}
File tempFile = File.createTempFile(braf, null);
tempFile.deleteOnExit();
BufferedRandomAccessFile file = new BufferedRandomAccessFile(tempFile, rw);
byte[] bigData = new byte[BufferedRandomAccessFile.DEFAULT_BUFFER_SIZE + 10];
for (int i = 0; i bigData.length; i++)
bigData[i] = 'd';
long initialPosition = file.getFilePointer();
file.write(bigData); // writing data
assert file.getFilePointer() == initialPosition + bigData.length;
assert file.length() == initialPosition + bigData.length; // file size should
equals to last position
// reading written buffer
file.seek(initialPosition);
data = new byte[bigData.length];
assert file.read(data) == data.length; -- Fails (returns DEFAULT_BUFFER_SIZE
as file.read(..) result)
{code}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999525#comment-12999525
]
Eric Evans commented on CASSANDRA-2124:
---
{quote}
- name: IndexedTable
compare_with: LongType
issue is:
{why: expected 8 or 0 long(9)}. something like this.
{quote}
Right, the comparator is for the column _name_, which in your previous example
was birthdate. It fails to validate because a long is 8 bytes in length and
birthdate is 9 bytes. Validators apply to column values, if you have not
configured a default validator, _or_ a column specific one (using
column_metadata), then it is {{BytesType}} (i.e. no validation).
{quote}
Yes. i can see that both are validated. but from batchUpdate method, call is
validateColumn(keyspace, update.getColumnFamily(),
column.getKey().getByteBuffer());
{quote}
{{getKey()}} is a method of {{java.util.Map.Entry}}, it returns the column name
(the key in this entry), because we're iterating over a map of columns. This
code is working correctly.
JDBC driver for CQL
---
Key: CASSANDRA-2124
URL: https://issues.apache.org/jira/browse/CASSANDRA-2124
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Eric Evans
Assignee: Vivek Mishra
Priority: Minor
Labels: cql
Attachments: Cassandra-2124_v1.0, cassandra-0.7.1-2124_v2.0,
cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch
A simple connection class and corresponding pool was created for CQL as a
part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a
replacement for) would also be interesting.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2250) BufferedRandomAccessFile.read(byte[], int, int) method reads max DEFAULT_BUFFER_SIZE
[
https://issues.apache.org/jira/browse/CASSANDRA-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999523#comment-12999523
]
Pavel Yaskevich commented on CASSANDRA-2250:
Gotcha, thanks!
BufferedRandomAccessFile.read(byte[], int, int) method reads max
DEFAULT_BUFFER_SIZE
Key: CASSANDRA-2250
URL: https://issues.apache.org/jira/browse/CASSANDRA-2250
Project: Cassandra
Issue Type: Sub-task
Components: Core
Reporter: Pavel Yaskevich
Test to reproduce:
{code}
File tempFile = File.createTempFile(braf, null);
tempFile.deleteOnExit();
BufferedRandomAccessFile file = new BufferedRandomAccessFile(tempFile, rw);
byte[] bigData = new byte[BufferedRandomAccessFile.DEFAULT_BUFFER_SIZE + 10];
for (int i = 0; i bigData.length; i++)
bigData[i] = 'd';
long initialPosition = file.getFilePointer();
file.write(bigData); // writing data
assert file.getFilePointer() == initialPosition + bigData.length;
assert file.length() == initialPosition + bigData.length; // file size should
equals to last position
// reading written buffer
file.seek(initialPosition);
data = new byte[bigData.length];
assert file.read(data) == data.length; -- Fails (returns DEFAULT_BUFFER_SIZE
as file.read(..) result)
{code}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074685 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/db/ColumnFamilyStore.java src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java
Author: jbellis
Date: Fri Feb 25 20:31:12 2011
New Revision: 1074685
URL: http://svn.apache.org/viewvc?rev=1074685view=rev
Log:
add [get|set][row|key]cacheSavePeriod to JMX
patch by Jon Hermes; reviewed by jbellis for CASSANDRA-2100
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1074685r1=1074684r2=1074685view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Fri Feb 25 20:31:12 2011
@@ -33,6 +33,7 @@
from supercolumn's (CASSANDRA-2104)
* fix starting up on Windows when CASSANDRA_HOME contains whitespace
(CASSANDRA-2237)
+ * add [get|set][row|key]cacheSavePeriod to JMX (CASSANDRA-2100)
0.7.2
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnFamilyStore.java?rev=1074685r1=1074684r2=1074685view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
Fri Feb 25 20:31:12 2011
@@ -26,6 +26,7 @@ import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicReference;
import java.util.regex.Pattern;
+import javax.management.JMX;
import javax.management.MBeanServer;
import javax.management.ObjectName;
@@ -133,6 +134,12 @@ public class ColumnFamilyStore implement
private volatile DefaultInteger memtime;
private volatile DefaultInteger memsize;
private volatile DefaultDouble memops;
+private volatile DefaultInteger rowCacheSaveInSeconds;
+private volatile DefaultInteger keyCacheSaveInSeconds;
+
+// Locally held row/key cache scheduled tasks
+private volatile ScheduledFuture? saveRowCacheTask;
+private volatile ScheduledFuture? saveKeyCacheTask;
public void reload()
{
@@ -149,8 +156,13 @@ public class ColumnFamilyStore implement
memsize = new DefaultInteger(metadata.getMemtableThroughputInMb());
if (!memops.isModified())
memops = new
DefaultDouble(metadata.getMemtableOperationsInMillions());
+if (!rowCacheSaveInSeconds.isModified())
+rowCacheSaveInSeconds = new
DefaultInteger(metadata.getRowCacheSavePeriodInSeconds());
+if (!keyCacheSaveInSeconds.isModified())
+keyCacheSaveInSeconds = new
DefaultInteger(metadata.getKeyCacheSavePeriodInSeconds());
ssTables.updateCacheSizes();
+scheduleCacheSaving(rowCacheSaveInSeconds.value(),
keyCacheSaveInSeconds.value());
// figure out what needs to be added and dropped.
// future: if/when we have modifiable settings for secondary indexes,
they'll need to be handled here.
@@ -186,6 +198,8 @@ public class ColumnFamilyStore implement
this.memtime = new
DefaultInteger(metadata.getMemtableFlushAfterMins());
this.memsize = new
DefaultInteger(metadata.getMemtableThroughputInMb());
this.memops = new
DefaultDouble(metadata.getMemtableOperationsInMillions());
+this.rowCacheSaveInSeconds = new
DefaultInteger(metadata.getRowCacheSavePeriodInSeconds());
+this.keyCacheSaveInSeconds = new
DefaultInteger(metadata.getKeyCacheSavePeriodInSeconds());
this.partitioner = partitioner;
fileIndexGenerator.set(generation);
memtable = new Memtable(this);
@@ -529,6 +543,16 @@ public class ColumnFamilyStore implement
ssTables.getRowCache().getSize(),
table.name,
columnFamily));
+scheduleCacheSaving(rowCacheSavePeriodInSeconds,
keyCacheSavePeriodInSeconds);
+}
+
+public void scheduleCacheSaving(int rowCacheSavePeriodInSeconds, int
keyCacheSavePeriodInSeconds)
+{
+if (saveRowCacheTask != null)
+{
+saveRowCacheTask.cancel(false); // Do not interrupt an in-progress
save
+saveRowCacheTask = null;
+}
if (rowCacheSavePeriodInSeconds 0)
{
Runnable runnable = new WrappedRunnable()
@@ -538,12 +562,17 @@ public class ColumnFamilyStore implement
submitRowCacheWrite();
}
};
-StorageService.scheduledTasks.scheduleWithFixedDelay(runnable,
-
svn commit: r1074692 - in /cassandra/branches/cassandra-0.7: build.xml debian/changelog
Author: eevans
Date: Fri Feb 25 20:41:43 2011
New Revision: 1074692
URL: http://svn.apache.org/viewvc?rev=1074692view=rev
Log:
update versioning for 0.7.3 release
Modified:
cassandra/branches/cassandra-0.7/build.xml
cassandra/branches/cassandra-0.7/debian/changelog
Modified: cassandra/branches/cassandra-0.7/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/build.xml?rev=1074692r1=1074691r2=1074692view=diff
==
--- cassandra/branches/cassandra-0.7/build.xml (original)
+++ cassandra/branches/cassandra-0.7/build.xml Fri Feb 25 20:41:43 2011
@@ -49,7 +49,7 @@
property name=test.long.src value=${test.dir}/long/
property name=test.distributed.src value=${test.dir}/distributed/
property name=dist.dir value=${build.dir}/dist/
-property name=base.version value=0.7.1/
+property name=base.version value=0.7.3/
condition property=version value=${base.version}
isset property=release/
/condition
Modified: cassandra/branches/cassandra-0.7/debian/changelog
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/debian/changelog?rev=1074692r1=1074691r2=1074692view=diff
==
--- cassandra/branches/cassandra-0.7/debian/changelog (original)
+++ cassandra/branches/cassandra-0.7/debian/changelog Fri Feb 25 20:41:43 2011
@@ -1,3 +1,9 @@
+cassandra (0.7.3) unstable; urgency=low
+
+ * New stable point release.
+
+ -- Eric Evans eev...@apache.org Fri, 25 Feb 2011 14:20:50 -0600
+
cassandra (0.7.1) unstable; urgency=low
* New stable point release.
svn commit: r1074693 - in /cassandra/branches/cassandra-0.7: src/java/org/apache/cassandra/service/ test/unit/org/apache/cassandra/db/
Author: eevans Date: Fri Feb 25 20:41:50 2011 New Revision: 1074693 URL: http://svn.apache.org/viewvc?rev=1074693view=rev Log: prepend missing license headers Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/IReadCommand.java cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/KeyCacheTest.java cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/ScrubTest.java Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java?rev=1074693r1=1074692r2=1074693view=diff == --- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java (original) +++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java Fri Feb 25 20:41:50 2011 @@ -1,4 +1,25 @@ package org.apache.cassandra.service; +/* + * + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * License); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + * + */ + import java.io.ByteArrayInputStream; import java.io.DataInputStream; Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java?rev=1074693r1=1074692r2=1074693view=diff == --- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java (original) +++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java Fri Feb 25 20:41:50 2011 @@ -1,4 +1,25 @@ package org.apache.cassandra.service; +/* + * + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * License); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + * + */ + import java.io.IOException; Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/IReadCommand.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/IReadCommand.java?rev=1074693r1=1074692r2=1074693view=diff == --- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/IReadCommand.java (original) +++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/IReadCommand.java Fri Feb 25 20:41:50 2011 @@ -1,4 +1,25 @@ package org.apache.cassandra.service; +/* + * + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * License); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * AS IS BASIS,
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999547#comment-12999547 ] Vivek Mishra commented on CASSANDRA-2124: - Thanks Eric. I got it clarified now. One quick question, column name and column value both should be decoded in CassandraResultSet?. Decoding a column name will be an advantage(thinking from jdbc perspective) JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1969) Use BB for row cache - To Improve GC performance.
[ https://issues.apache.org/jira/browse/CASSANDRA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-1969: -- Attachment: 1969-rollup-and-config.txt Adds row_cache_provider to CFMetaData. When it's coming in via YAML/thrift/avro, it's a string. It then creates an IRowCacheProvider in FBUtils like IPartitioner, et al. Doesn't handle changes at runtime, but a new ticket should be opened for that. Use BB for row cache - To Improve GC performance. - Key: CASSANDRA-1969 URL: https://issues.apache.org/jira/browse/CASSANDRA-1969 Project: Cassandra Issue Type: Improvement Components: Core Environment: Linux and Mac Reporter: Vijay Assignee: Vijay Priority: Minor Attachments: 0001-Config-1969.txt, 0001-introduce-ICache-InstrumentingCache-IRowCacheProvider.txt, 0002-Update_existing-1965.txt, 0002-implement-SerializingCache.txt, 0002-implement-SerializingCacheV2.txt, 0003-New_Cache_Providers-1969.txt, 0003-add-ICache.isCopying-method.txt, 0004-Null-Check-and-duplicate-bb.txt, 0004-TestCase-1969.txt, 1969-rollup-and-config.txt, BB_Cache-1945.png, JMX-Cache-1945.png, Old_Cahce-1945.png, POC-0001-Config-1945.txt, POC-0002-Update_existing-1945.txt, POC-0003-New_Cache_Providers-1945.txt Java BB.allocateDirect() will allocate native memory out of the JVM and will help reducing the GC pressure in the JVM with a large Cache. From some of the basic tests it shows around 50% improvement than doing a normal Object cache. In addition this patch provide the users an option to choose BB.allocateDirect or store everything in the heap. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999563#comment-12999563 ] Eric Evans commented on CASSANDRA-2124: --- bq. One quick question, column name and column value both should be decoded in CassandraResultSet?. Decoding a column name will be an advantage(thinking from jdbc perspective) Both, yes. JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2100) Restart required to change cache_save_period
[ https://issues.apache.org/jira/browse/CASSANDRA-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999566#comment-12999566 ] Hudson commented on CASSANDRA-2100: --- Integrated in Cassandra-0.7 #324 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/324/]) add [get|set][row|key]cacheSavePeriod to JMX patch by Jon Hermes; reviewed by jbellis for CASSANDRA-2100 Restart required to change cache_save_period Key: CASSANDRA-2100 URL: https://issues.apache.org/jira/browse/CASSANDRA-2100 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Nick Bailey Assignee: Jon Hermes Priority: Minor Fix For: 0.7.3 Attachments: 2100-2.txt, 2100-3.txt, 2100.txt Original Estimate: 2h Remaining Estimate: 2h The cache_save_period is set in the schema for each column family. However this value is only checked when a node starts up so changing this value isn't really dynamic. We should actually change this when the schema changes instead of having to restart. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2251:
--
Attachment: v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace.txt
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
Attachments:
v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace-argument.txt,
v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace.txt
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999585#comment-12999585
]
Eric Evans commented on CASSANDRA-2251:
---
bq. maybe we should move the check into getKeyspace? there's a bunch of callers
that don't call vCF afterwards.
That'll work too. New patch attached.
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
Attachments: v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace.txt
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2251:
--
Attachment: (was:
v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace-argument.txt)
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
Attachments: v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace.txt
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074709 - in /cassandra/trunk: doc/cql/CQL.html doc/cql/CQL.textile src/java/org/apache/cassandra/cql/Cql.g test/system/test_cql.py
Author: eevans Date: Fri Feb 25 21:38:53 2011 New Revision: 1074709 URL: http://svn.apache.org/viewvc?rev=1074709view=rev Log: CASSANDRA-2025 updated consistency level spec (removed '.') Patch by eevans for CASSANDRA-2025 Modified: cassandra/trunk/doc/cql/CQL.html cassandra/trunk/doc/cql/CQL.textile cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g cassandra/trunk/test/system/test_cql.py Modified: cassandra/trunk/doc/cql/CQL.html URL: http://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?rev=1074709r1=1074708r2=1074709view=diff == --- cassandra/trunk/doc/cql/CQL.html (original) +++ cassandra/trunk/doc/cql/CQL.html Fri Feb 25 21:38:53 2011 @@ -8,7 +8,7 @@ SELECT [FIRST N] [REVERSED] name1..nameN /code/prepFollowing the column family clause is an optional a href=#consistencyconsistency level specification/a./ph3 id=FilteringrowsFiltering rows/h3precodeSELECT ... WHERE KEY = keyname AND name1 = value1 SELECT ... WHERE KEY gt;= startkey and KEY =lt; endkey AND name1 = value1 /code/prepThe WHERE clause provides for filtering the rows that appear in results. The clause can filter on a key name, or range of keys, and in the case of indexed columns, on column values. Key filters are specified using the codeKEY/code keyword, a relational operator, (one of code=/code, codegt;/code, codegt;=/code, codelt;/code, and codelt;=/code), and a term value. When terms appear on both sides of a relational operator it is assumed the filter applies to an indexed column. With column index filters, the term on the left of the operator is the name, the term on the right is the value to filter ion/i./ppiNote: The greater-than and less-than operators (codegt;/code and codelt;/code) result in key ranges that are inclusive of the terms. There is no supported notion of #8220;strictly#8221; greater-than or less-than; these operators are merely supported as aliases to codegt;=/code and codelt;=/code./i /ph3 id=LimitsLimits/h3precodeSELECT ... WHERE lt;CLAUSEgt; [LIMIT N] ... -/code/prepLimiting the number of rows returned can be achieved by adding the codeLIMIT/code option to a codeSELECT/code expression. codeLIMIT/code defaults to 10,000 when left unset./ph2 id=UPDATEUPDATE/h2pemSynopsis:/em/pprecodeUPDATE lt;COLUMN FAMILYgt; [USING CONSISTENCY.lt;CLgt;] +/code/prepLimiting the number of rows returned can be achieved by adding the codeLIMIT/code option to a codeSELECT/code expression. codeLIMIT/code defaults to 10,000 when left unset./ph2 id=UPDATEUPDATE/h2pemSynopsis:/em/pprecodeUPDATE lt;COLUMN FAMILYgt; [USING CONSISTENCY lt;CLgt;] SET name1 = value1, name2 = value2 WHERE KEY = keyname; /code/prepAn codeUPDATE/code is used to write one or more columns to a record in a Cassandra column family. No results are returned./ph3 id=ColumnFamily2Column Family/h3precodeUPDATE lt;COLUMN FAMILYgt; ... /code/prepStatements begin with the codeUPDATE/code keyword followed by a Cassandra column family name./ph3 id=ConsistencyLevel2Consistency Level/h3precodeUPDATE ... [USING lt;CONSISTENCYgt;] ... @@ -34,4 +34,4 @@ UPDATE ... WHERE KEY IN (keyname1, keyna /code/prepIt is possible to assign columns a type during column family creation. Columns configured with a type are validated accordingly when a write occurs. Column types are specified as a parenthesized, comma-separated list of column term and type pairs. The list of recognized types are:/ptabletrthtype/ththdescription/th/trtrtdbytes/tdtdArbitrary bytes (no validation)/td/trtrtdascii/tdtdASCII character string/td/trtrtdutf8/tdtdUTF8 encoded string/td/trtrtdtimeuuid/tdtdType 1 UUID/td/trtrtduuid/tdtdType 4 UUID/td/trtrtdint/tdtd4-byte integer/td/trtrtdlong/tdtd8-byte long/td/tr/tablepemNote: In addition to the recognized types listed above, it is also possible to supply a string containing the name of a class (a sub-class of codeAbstractType/code), either fully qualified, or relative to the codeorg.apache.cassandra.db.marshal/code package./em/ph3 id =ColumnFamilyOptionsoptionalColumn Family Options (optional)/h3precodeCREATE COLUMNFAMILY ... WITH keyword1 = arg1 AND keyword2 = arg2; /code/prepA number of optional keyword arguments can be supplied to control the configuration of a new column family./ptabletrthkeyword/ththdefault/ththdescription/th/trtrtdcomparator/tdtdbytes/tdtdDetermines sorting and validation of column names. Valid values are identical to the types listed in a href=#columntypesSpecifying Column Type/a above./td/trtrtdcomment/tdtdnone/tdtdA free-form, human-readable comment./td/trtrtdrow_cache_size/tdtd0/tdtdNumber of rows whose entire contents to cache in memory./td/trtrtdkey_cache_size/tdtd20/tdtdNumber of keys per SSTable whose locations are kept in memory in #8220;mostly LRU#8221; order./td/trtrtdread_repair_chance/tdtd1.0/tdtdThe probability with which read repairs should be invoked
[jira] Commented: (CASSANDRA-2025) generalized way of expressing hierarchical values
[
https://issues.apache.org/jira/browse/CASSANDRA-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999589#comment-12999589
]
Eric Evans commented on CASSANDRA-2025:
---
The patch to remove the '.' from consistency level specs is committed. I
believe that's all that's remaining for this issue. Closing.
generalized way of expressing hierarchical values
-
Key: CASSANDRA-2025
URL: https://issues.apache.org/jira/browse/CASSANDRA-2025
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 0.8
Attachments:
v1-0001-CASSANDRA-2025-updated-consistency-level-spec-removed.txt
Original Estimate: 0h
Remaining Estimate: 0h
While hashing out {{CREATE KEYSPACE}}, it became obvious that we needed a
syntax for expressing hierarchical values. Properties like
{{replication_factor}} can be expressed simply using keyword arguments like
({{replication_factor = 3}}), but {{strategy_options}} is a map of strings.
The solution I took in CASSANDRA-1709 was to dot-delimit map name and
option key, so for example:
{code:style=SQL}
CREATE KEYSPACE keyspace WITH ... AND strategy_options.DC1 = 1 ...
{code}
This led me to wonder if this was a general enough approach for any future
cases that might come up. One example might be compound/composite column
names. Dot-delimiting is a bad choice here since it rules out ever
introducing a float literal.
One suggestion would be to colon-delimit, so for example:
{code:style=SQL}
CREATE KEYSPACE keyspace WITH ... AND strategy_options:DC1 = 1 ...
{code}
Or in the case of composite column names:
{code:style=SQL}
SELECT columnA:columnB,column1:column2 FROM Standard2 USING
CONSISTENCY.QUORUM WHERE KEY = key;
UPDATE Standard2 SET columnA:columnB = valueC, column1:column2 = value3 WHERE
KEY = key;
{code}
As an aside, this also led me to the conclusion that {{CONSISTENCY.LEVEL}}
is probably a bad choice for consistency level specification. It mirrors the
underlying enum for no good reason and should probably be changed to
{{CONSISTENCY LEVEL}} (i.e. omitting the separator). For example:
{code:style=SQL}
SELECT column FROM Standard2 USING CONSISTENCY QUORUM WHERE KEY = key;
{code}
Thoughts?
*Edit: improved final example*
*Edit: restore final example, create new one (gah).*
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999590#comment-12999590
]
Jonathan Ellis commented on CASSANDRA-2251:
---
+1
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
Attachments: v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace.txt
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074711 - /cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
Author: eevans
Date: Fri Feb 25 21:47:25 2011
New Revision: 1074711
URL: http://svn.apache.org/viewvc?rev=1074711view=rev
Log:
raise IRE for null keyspace argument
Patch by eevans; reviewed by jbellis for CASSANDRA-2251
Modified:
cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
Modified:
cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java?rev=1074711r1=1074710r2=1074711view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
Fri Feb 25 21:47:25 2011
@@ -69,6 +69,8 @@ public class ThriftValidation
public static ColumnFamilyType validateColumnFamily(String tablename,
String cfName) throws InvalidRequestException
{
+if (tablename == null)
+throw new InvalidRequestException(no keyspace has been
specified);
if (cfName.isEmpty())
{
throw new InvalidRequestException(non-empty columnfamily is
required);
svn commit: r1074712 - /cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
Author: eevans
Date: Fri Feb 25 21:50:46 2011
New Revision: 1074712
URL: http://svn.apache.org/viewvc?rev=1074712view=rev
Log:
revert, committed from the wrong git branch!
Modified:
cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
Modified:
cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java?rev=1074712r1=1074711r2=1074712view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
Fri Feb 25 21:50:46 2011
@@ -69,8 +69,6 @@ public class ThriftValidation
public static ColumnFamilyType validateColumnFamily(String tablename,
String cfName) throws InvalidRequestException
{
-if (tablename == null)
-throw new InvalidRequestException(no keyspace has been
specified);
if (cfName.isEmpty())
{
throw new InvalidRequestException(non-empty columnfamily is
required);
svn commit: r1074714 - in /cassandra/trunk: interface/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/cql/ src/java/org/apache/cassandra/service/ src/java/org/apa
Author: eevans
Date: Fri Feb 25 22:06:24 2011
New Revision: 1074714
URL: http://svn.apache.org/viewvc?rev=1074714view=rev
Log:
raise IRE for null keyspace
Patch by eevans; reviewed by jbellis for CASSANDRA-2251
Modified:
cassandra/trunk/interface/cassandra.thrift
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
cassandra/trunk/src/java/org/apache/cassandra/service/ClientState.java
cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java
Modified: cassandra/trunk/interface/cassandra.thrift
URL:
http://svn.apache.org/viewvc/cassandra/trunk/interface/cassandra.thrift?rev=1074714r1=1074713r2=1074714view=diff
==
--- cassandra/trunk/interface/cassandra.thrift (original)
+++ cassandra/trunk/interface/cassandra.thrift Fri Feb 25 22:06:24 2011
@@ -633,7 +633,8 @@ service Cassandra {
liststring describe_splits(1:required string cfName,
2:required string start_token,
3:required string end_token,
- 4:required i32 keys_per_split),
+ 4:required i32 keys_per_split)
+throws (1:InvalidRequestException ire),
/** adds a column family. returns the new schema id. */
string system_add_column_family(1:required CfDef cf_def)
Modified:
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java?rev=1074714r1=1074713r2=1074714view=diff
==
---
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
(original)
+++
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
Fri Feb 25 22:06:24 2011
@@ -143,6 +143,11 @@ public class Cassandra {
* that all the values in column_path besides column_path.column_family
are truly optional: you can remove the entire
* row by just specifying the ColumnFamily, or you can remove a
SuperColumn or a single Column by specifying those levels too.
*
+ * Note that counters have limited support for deletes: if you remove
+ * a counter, you must wait to issue any following update until the
+ * delete has reached all the nodes and all of them have been fully
+ * compacted.
+ *
* @param key
* @param column_path
* @param timestamp
@@ -294,7 +299,7 @@ public class Cassandra {
* @param end_token
* @param keys_per_split
*/
-public ListString describe_splits(String cfName, String start_token,
String end_token, int keys_per_split) throws TException;
+public ListString describe_splits(String cfName, String start_token,
String end_token, int keys_per_split) throws InvalidRequestException,
TException;
/**
* adds a column family. returns the new schema id.
@@ -1620,7 +1625,7 @@ public class Cassandra {
throw new TApplicationException(TApplicationException.MISSING_RESULT,
describe_keyspace failed: unknown result);
}
-public ListString describe_splits(String cfName, String start_token,
String end_token, int keys_per_split) throws TException
+public ListString describe_splits(String cfName, String start_token,
String end_token, int keys_per_split) throws InvalidRequestException, TException
{
send_describe_splits(cfName, start_token, end_token, keys_per_split);
return recv_describe_splits();
@@ -1639,7 +1644,7 @@ public class Cassandra {
oprot_.getTransport().flush();
}
-public ListString recv_describe_splits() throws TException
+public ListString recv_describe_splits() throws InvalidRequestException,
TException
{
TMessage msg = iprot_.readMessageBegin();
if (msg.type == TMessageType.EXCEPTION) {
@@ -1656,6 +1661,9 @@ public class Cassandra {
if (result.isSetSuccess()) {
return result.success;
}
+ if (result.ire != null) {
+throw result.ire;
+ }
throw new TApplicationException(TApplicationException.MISSING_RESULT,
describe_splits failed: unknown result);
}
@@ -2929,7 +2937,7 @@ public class Cassandra {
prot.writeMessageEnd();
}
- public ListString getResult() throws TException {
+ public ListString getResult() throws InvalidRequestException,
TException {
if (getState() != State.RESPONSE_READ) {
throw new IllegalStateException(Method call not finished!);
}
@@ -4298,7 +4306,19 @@ public class Cassandra {
}
iprot.readMessageEnd();
describe_splits_result result = new describe_splits_result();
-result.success = iface_.describe_splits(args.cfName,
[jira] Updated: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2251:
--
Remaining Estimate: 0h
Original Estimate: 0h
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
Attachments: v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace.txt
Original Estimate: 0h
Remaining Estimate: 0h
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2251) unhelpful exception when failing to set keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999620#comment-12999620
]
Hudson commented on CASSANDRA-2251:
---
Integrated in Cassandra #745 (See
[https://hudson.apache.org/hudson/job/Cassandra/745/])
raise IRE for null keyspace
Patch by eevans; reviewed by jbellis for CASSANDRA-2251
raise IRE for null keyspace argument
Patch by eevans; reviewed by jbellis for CASSANDRA-2251
unhelpful exception when failing to set keyspace
Key: CASSANDRA-2251
URL: https://issues.apache.org/jira/browse/CASSANDRA-2251
Project: Cassandra
Issue Type: Bug
Reporter: Eric Evans
Assignee: Eric Evans
Attachments: v1-0001-CASSANDRA-2251-raise-IRE-for-null-keyspace.txt
Original Estimate: 0h
Remaining Estimate: 0h
If you fail to set the keyspace, {{ThriftValidation.validateColumnFamily()}}
raises an {{AssertionError}}, which remotely results in a
{{TApplicationException}}.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CASSANDRA-2196) Hyphenated index names cause problems
[ https://issues.apache.org/jira/browse/CASSANDRA-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans reopened CASSANDRA-2196: --- Hyphenated index names cause problems - Key: CASSANDRA-2196 URL: https://issues.apache.org/jira/browse/CASSANDRA-2196 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Environment: Cassandra 0.7.2 Windows 7 64-bit java version 1.6.0_23 Java(TM) SE Runtime Environment (build 1.6.0_23-b05) Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) Reporter: Stephen Pope Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.3 Attachments: 2196.txt Original Estimate: 1h Remaining Estimate: 1h When inserting a large number of entries with batch_insert (10) using thrift compiled into C# there's a NumberFormatException that occurs. The first logged entry that tipped me off was this: INFO 10:53:52,171 Writing Memtable-TransactionLogs.client-hostname@350930888(1171371 bytes, 32787 o perations) ERROR 10:53:52,171 Error in ThreadPoolExecutor java.lang.RuntimeException: java.lang.NumberFormatException: For input string: tmp at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NumberFormatException: For input string: tmp at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:449) at java.lang.Integer.parseInt(Integer.java:499) at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:154) at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:119) at org.apache.cassandra.io.sstable.SSTableWriter.init(SSTableWriter.java:67) at org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:156) at org.apache.cassandra.db.Memtable.access$000(Memtable.java:49) at org.apache.cassandra.db.Memtable$1.runMayThrow(Memtable.java:174) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) ... 3 more Which points to the suspect piece of code in Descriptor.java:154 (browse at https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/Descriptor.java) The file I believe it's trying to parse is mentioned in my logs as: INFO 10:51:31,231 Compacted to C:\cassandra\apache-cassandra-0.7.2\bin\..\Storage\data\system\Index Info-tmp-f-6-Data.db. 384 to 225 (~58% of original) bytes for 1 keys. Time: 281ms. I'm new here, so I'm not sure what needs fixing here (the filename, or the parsing of it). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1205) Unify Partitioners and AbstractTypes
[ https://issues.apache.org/jira/browse/CASSANDRA-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stu Hood updated CASSANDRA-1205: Priority: Critical (was: Major) This has gotten a bit scary with the addition of LocalPartitioner: bumping priority. Unify Partitioners and AbstractTypes Key: CASSANDRA-1205 URL: https://issues.apache.org/jira/browse/CASSANDRA-1205 Project: Cassandra Issue Type: Improvement Reporter: Stu Hood Priority: Critical Fix For: 0.8 There is no good reason for Partitioners to have different semantics than AbstractTypes. Instead, we should probably have 2 partitioners: Random and Ordered, where the Ordered partitioner requires an AbstractType to be specified, defaulting to BytesType. One solution [suggested by jbellis|https://issues.apache.org/jira/browse/CASSANDRA-767?focusedCommentId=12841565page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12841565] is to have AbstractType generate a collation id (essentially, a Token) for a set of bytes. Looking forward, we should probably consider laying the groundwork to add native support for compound row keys here as well. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2196) Hyphenated index names cause problems
[
https://issues.apache.org/jira/browse/CASSANDRA-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999642#comment-12999642
]
Eric Evans commented on CASSANDRA-2196:
---
r1072123 broke the CQL system tests with the following logged exception:
{noformat}
java.lang.ClassCastException: org.apache.avro.util.Utf8 cannot be cast to
java.lang.String
at
org.apache.cassandra.db.migration.UpdateColumnFamily.init(UpdateColumnFamily.java:52)
at
org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:638)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1209)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.process(Cassandra.java:4576)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:3235)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:188)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
{noformat}
(Trivial )patch attached.
Hyphenated index names cause problems
-
Key: CASSANDRA-2196
URL: https://issues.apache.org/jira/browse/CASSANDRA-2196
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0
Environment: Cassandra 0.7.2
Windows 7 64-bit
java version 1.6.0_23
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)
Reporter: Stephen Pope
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7.3
Attachments: 2196.txt
Original Estimate: 1h
Remaining Estimate: 1h
When inserting a large number of entries with batch_insert (10) using
thrift compiled into C# there's a NumberFormatException that occurs.
The first logged entry that tipped me off was this:
INFO 10:53:52,171 Writing
Memtable-TransactionLogs.client-hostname@350930888(1171371 bytes, 32787 o
perations)
ERROR 10:53:52,171 Error in ThreadPoolExecutor
java.lang.RuntimeException: java.lang.NumberFormatException: For input
string: tmp
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NumberFormatException: For input string: tmp
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:449)
at java.lang.Integer.parseInt(Integer.java:499)
at
org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:154)
at
org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:119)
at
org.apache.cassandra.io.sstable.SSTableWriter.init(SSTableWriter.java:67)
at
org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:156)
at org.apache.cassandra.db.Memtable.access$000(Memtable.java:49)
at org.apache.cassandra.db.Memtable$1.runMayThrow(Memtable.java:174)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
... 3 more
Which points to the suspect piece of code in Descriptor.java:154 (browse at
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/Descriptor.java)
The file I believe it's trying to parse is mentioned in my logs as:
INFO 10:51:31,231 Compacted to
C:\cassandra\apache-cassandra-0.7.2\bin\..\Storage\data\system\Index
Info-tmp-f-6-Data.db. 384 to 225 (~58% of original) bytes for 1 keys. Time:
281ms.
I'm new here, so I'm not sure what needs fixing here (the filename, or the
parsing of it).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2196) Hyphenated index names cause problems
[ https://issues.apache.org/jira/browse/CASSANDRA-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999648#comment-12999648 ] Gary Dusbabek commented on CASSANDRA-2196: -- +1 Hyphenated index names cause problems - Key: CASSANDRA-2196 URL: https://issues.apache.org/jira/browse/CASSANDRA-2196 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Environment: Cassandra 0.7.2 Windows 7 64-bit java version 1.6.0_23 Java(TM) SE Runtime Environment (build 1.6.0_23-b05) Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) Reporter: Stephen Pope Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.3 Attachments: 2196.txt, v1-0001-CASSANDRA-2196-invoke-toString-instead-of-casting.txt Original Estimate: 1h Remaining Estimate: 1h When inserting a large number of entries with batch_insert (10) using thrift compiled into C# there's a NumberFormatException that occurs. The first logged entry that tipped me off was this: INFO 10:53:52,171 Writing Memtable-TransactionLogs.client-hostname@350930888(1171371 bytes, 32787 o perations) ERROR 10:53:52,171 Error in ThreadPoolExecutor java.lang.RuntimeException: java.lang.NumberFormatException: For input string: tmp at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NumberFormatException: For input string: tmp at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:449) at java.lang.Integer.parseInt(Integer.java:499) at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:154) at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:119) at org.apache.cassandra.io.sstable.SSTableWriter.init(SSTableWriter.java:67) at org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:156) at org.apache.cassandra.db.Memtable.access$000(Memtable.java:49) at org.apache.cassandra.db.Memtable$1.runMayThrow(Memtable.java:174) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) ... 3 more Which points to the suspect piece of code in Descriptor.java:154 (browse at https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/Descriptor.java) The file I believe it's trying to parse is mentioned in my logs as: INFO 10:51:31,231 Compacted to C:\cassandra\apache-cassandra-0.7.2\bin\..\Storage\data\system\Index Info-tmp-f-6-Data.db. 384 to 225 (~58% of original) bytes for 1 keys. Time: 281ms. I'm new here, so I'm not sure what needs fixing here (the filename, or the parsing of it). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074773 - /cassandra/trunk/src/java/org/apache/cassandra/db/migration/UpdateColumnFamily.java
Author: eevans
Date: Sat Feb 26 01:19:04 2011
New Revision: 1074773
URL: http://svn.apache.org/viewvc?rev=1074773view=rev
Log:
invoke toString() instead of casting
Patch by eevans; reviewed by gdusbabek for CASSANDRA-2196
Modified:
cassandra/trunk/src/java/org/apache/cassandra/db/migration/UpdateColumnFamily.java
Modified:
cassandra/trunk/src/java/org/apache/cassandra/db/migration/UpdateColumnFamily.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/db/migration/UpdateColumnFamily.java?rev=1074773r1=1074772r2=1074773view=diff
==
---
cassandra/trunk/src/java/org/apache/cassandra/db/migration/UpdateColumnFamily.java
(original)
+++
cassandra/trunk/src/java/org/apache/cassandra/db/migration/UpdateColumnFamily.java
Sat Feb 26 01:19:04 2011
@@ -49,7 +49,7 @@ public class UpdateColumnFamily extends
{
for (ColumnDef entry : cf_def.column_metadata)
{
-if (entry.index_name != null
!Migration.isLegalName((String) entry.index_name))
+if (entry.index_name != null
!Migration.isLegalName(entry.index_name.toString()))
throw new ConfigurationException(Invalid index name: +
entry.index_name);
}
}
[jira] Resolved: (CASSANDRA-2196) Hyphenated index names cause problems
[ https://issues.apache.org/jira/browse/CASSANDRA-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans resolved CASSANDRA-2196. --- Resolution: Fixed Hyphenated index names cause problems - Key: CASSANDRA-2196 URL: https://issues.apache.org/jira/browse/CASSANDRA-2196 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Environment: Cassandra 0.7.2 Windows 7 64-bit java version 1.6.0_23 Java(TM) SE Runtime Environment (build 1.6.0_23-b05) Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) Reporter: Stephen Pope Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.3 Attachments: 2196.txt, v1-0001-CASSANDRA-2196-invoke-toString-instead-of-casting.txt Original Estimate: 1h Remaining Estimate: 1h When inserting a large number of entries with batch_insert (10) using thrift compiled into C# there's a NumberFormatException that occurs. The first logged entry that tipped me off was this: INFO 10:53:52,171 Writing Memtable-TransactionLogs.client-hostname@350930888(1171371 bytes, 32787 o perations) ERROR 10:53:52,171 Error in ThreadPoolExecutor java.lang.RuntimeException: java.lang.NumberFormatException: For input string: tmp at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NumberFormatException: For input string: tmp at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:449) at java.lang.Integer.parseInt(Integer.java:499) at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:154) at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:119) at org.apache.cassandra.io.sstable.SSTableWriter.init(SSTableWriter.java:67) at org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:156) at org.apache.cassandra.db.Memtable.access$000(Memtable.java:49) at org.apache.cassandra.db.Memtable$1.runMayThrow(Memtable.java:174) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) ... 3 more Which points to the suspect piece of code in Descriptor.java:154 (browse at https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/Descriptor.java) The file I believe it's trying to parse is mentioned in my logs as: INFO 10:51:31,231 Compacted to C:\cassandra\apache-cassandra-0.7.2\bin\..\Storage\data\system\Index Info-tmp-f-6-Data.db. 384 to 225 (~58% of original) bytes for 1 keys. Time: 281ms. I'm new here, so I'm not sure what needs fixing here (the filename, or the parsing of it). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2196) Hyphenated index names cause problems
[ https://issues.apache.org/jira/browse/CASSANDRA-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999698#comment-12999698 ] Hudson commented on CASSANDRA-2196: --- Integrated in Cassandra #746 (See [https://hudson.apache.org/hudson/job/Cassandra/746/]) invoke toString() instead of casting Patch by eevans; reviewed by gdusbabek for CASSANDRA-2196 Hyphenated index names cause problems - Key: CASSANDRA-2196 URL: https://issues.apache.org/jira/browse/CASSANDRA-2196 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Environment: Cassandra 0.7.2 Windows 7 64-bit java version 1.6.0_23 Java(TM) SE Runtime Environment (build 1.6.0_23-b05) Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) Reporter: Stephen Pope Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.3 Attachments: 2196.txt, v1-0001-CASSANDRA-2196-invoke-toString-instead-of-casting.txt Original Estimate: 1h Remaining Estimate: 1h When inserting a large number of entries with batch_insert (10) using thrift compiled into C# there's a NumberFormatException that occurs. The first logged entry that tipped me off was this: INFO 10:53:52,171 Writing Memtable-TransactionLogs.client-hostname@350930888(1171371 bytes, 32787 o perations) ERROR 10:53:52,171 Error in ThreadPoolExecutor java.lang.RuntimeException: java.lang.NumberFormatException: For input string: tmp at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NumberFormatException: For input string: tmp at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:449) at java.lang.Integer.parseInt(Integer.java:499) at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:154) at org.apache.cassandra.io.sstable.Descriptor.fromFilename(Descriptor.java:119) at org.apache.cassandra.io.sstable.SSTableWriter.init(SSTableWriter.java:67) at org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:156) at org.apache.cassandra.db.Memtable.access$000(Memtable.java:49) at org.apache.cassandra.db.Memtable$1.runMayThrow(Memtable.java:174) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) ... 3 more Which points to the suspect piece of code in Descriptor.java:154 (browse at https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/Descriptor.java) The file I believe it's trying to parse is mentioned in my logs as: INFO 10:51:31,231 Compacted to C:\cassandra\apache-cassandra-0.7.2\bin\..\Storage\data\system\Index Info-tmp-f-6-Data.db. 384 to 225 (~58% of original) bytes for 1 keys. Time: 281ms. I'm new here, so I'm not sure what needs fixing here (the filename, or the parsing of it). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1954) Double-check or replace RRW memtable lock
[
https://issues.apache.org/jira/browse/CASSANDRA-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999716#comment-12999716
]
Jonathan Ellis commented on CASSANDRA-1954:
---
Sorry, I was too slow -- already needs rebase
Double-check or replace RRW memtable lock
-
Key: CASSANDRA-1954
URL: https://issues.apache.org/jira/browse/CASSANDRA-1954
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Attachments:
0001-Double-check-in-maybeSwitchMemtable-to-minimize-writeL.txt,
0001-Remove-flusherLock-readLock.patch, 1954-v2.txt, 1954_trunk.patch
{quote}...when a Memtable reaches its threshold, up to (all) N write threads
will often notice, and race to acquire the writeLock in order to freeze the
memtable. This means that we do way more writeLock acquisitions than we need
to...{quote}
See CASSANDRA-1930 for backstory, but adding double checking inside a read
lock before trying to re-entrantly acquire the writelock would eliminate most
of these excess writelock acquisitions.
Alternatively, we should explore removing locking from these structures
entirely, and replacing the writeLock acquisition with a per-memtable counter
of active threads.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1074795 - /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
Author: eevans
Date: Sat Feb 26 05:20:06 2011
New Revision: 1074795
URL: http://svn.apache.org/viewvc?rev=1074795view=rev
Log:
apply authorization to queries
Patch by eevans for CASSANDRA-1708
Modified:
cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java?rev=1074795r1=1074794r2=1074795view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java Sat
Feb 26 05:20:06 2011
@@ -33,6 +33,7 @@ import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.antlr.runtime.*;
+import org.apache.cassandra.auth.Permission;
import org.apache.cassandra.concurrent.Stage;
import org.apache.cassandra.concurrent.StageManager;
import org.apache.cassandra.config.CFMetaData;
@@ -199,13 +200,22 @@ public class QueryProcessor
return rows;
}
-private static void batchUpdate(String keyspace, ListUpdateStatement
updateStatements, ConsistencyLevel consistency)
+private static void batchUpdate(ClientState clientState,
ListUpdateStatement updateStatements, ConsistencyLevel consistency)
throws InvalidRequestException, UnavailableException, TimedOutException
{
+String keyspace = clientState.getKeyspace();
ListRowMutation rowMutations = new ArrayListRowMutation();
+ListString cfamsSeen = new ArrayListString();
for (UpdateStatement update : updateStatements)
{
+// Avoid unnecessary authorizations.
+if (!(cfamsSeen.contains(update.getColumnFamily(
+{
+clientState.hasColumnFamilyAccess(update.getColumnFamily(),
Permission.WRITE);
+cfamsSeen.add(update.getColumnFamily());
+}
+
ByteBuffer key = update.getKey().getByteBuffer();
validateKey(key);
validateColumnFamily(keyspace, update.getColumnFamily());
@@ -396,6 +406,7 @@ public class QueryProcessor
{
case SELECT:
SelectStatement select = (SelectStatement)statement.statement;
+clientState.hasColumnFamilyAccess(select.getColumnFamily(),
Permission.READ);
validateColumnFamily(keyspace, select.getColumnFamily());
validateSelect(keyspace, select);
@@ -468,7 +479,7 @@ public class QueryProcessor
case UPDATE:
UpdateStatement update = (UpdateStatement)statement.statement;
-batchUpdate(keyspace, Collections.singletonList(update),
update.getConsistencyLevel());
+batchUpdate(clientState, Collections.singletonList(update),
update.getConsistencyLevel());
avroResult.type = CqlResultType.VOID;
return avroResult;
@@ -480,7 +491,7 @@ public class QueryProcessor
throw new InvalidRequestException(
Consistency level must be set on the BATCH,
not individual UPDATE statements);
-batchUpdate(keyspace, batch.getUpdates(),
batch.getConsistencyLevel());
+batchUpdate(clientState, batch.getUpdates(),
batch.getConsistencyLevel());
avroResult.type = CqlResultType.VOID;
return avroResult;
@@ -492,6 +503,7 @@ public class QueryProcessor
case TRUNCATE:
String columnFamily = (String)statement.statement;
+clientState.hasColumnFamilyAccess(columnFamily,
Permission.WRITE);
try
{
@@ -511,6 +523,7 @@ public class QueryProcessor
case DELETE:
DeleteStatement delete = (DeleteStatement)statement.statement;
+clientState.hasColumnFamilyAccess(delete.getColumnFamily(),
Permission.WRITE);
ListRowMutation rowMutations = new ArrayListRowMutation();
for (Term key : delete.getKeys())
@@ -545,6 +558,7 @@ public class QueryProcessor
case CREATE_KEYSPACE:
CreateKeyspaceStatement create =
(CreateKeyspaceStatement)statement.statement;
create.validate();
+clientState.hasKeyspaceListAccess(Permission.WRITE);
try
{
@@ -572,6 +586,7 @@ public class QueryProcessor
case CREATE_COLUMNFAMILY:
CreateColumnFamilyStatement createCf =
(CreateColumnFamilyStatement)statement.statement;
+clientState.hasColumnFamilyListAccess(Permission.WRITE);
[jira] Commented: (CASSANDRA-1708) CQL authentication
[
https://issues.apache.org/jira/browse/CASSANDRA-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999719#comment-12999719
]
Eric Evans commented on CASSANDRA-1708:
---
committed.
CQL authentication
--
Key: CASSANDRA-1708
URL: https://issues.apache.org/jira/browse/CASSANDRA-1708
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 0.8
Attachments: Cass_auth_changes.patch,
v1-0001-CASSANDRA-1708-apply-authorization-to-queries.txt
Original Estimate: 0h
Remaining Estimate: 0h
CQL specification and implementation for authentication, (corresponds to the
{{login()}} RPC method).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-1708) CQL authentication
[
https://issues.apache.org/jira/browse/CASSANDRA-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-1708:
--
Assignee: Eric Evans
CQL authentication
--
Key: CASSANDRA-1708
URL: https://issues.apache.org/jira/browse/CASSANDRA-1708
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 0.8
Attachments: Cass_auth_changes.patch,
v1-0001-CASSANDRA-1708-apply-authorization-to-queries.txt
Original Estimate: 0h
Remaining Estimate: 0h
CQL specification and implementation for authentication, (corresponds to the
{{login()}} RPC method).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1708) CQL authentication
[
https://issues.apache.org/jira/browse/CASSANDRA-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999725#comment-12999725
]
Hudson commented on CASSANDRA-1708:
---
Integrated in Cassandra #747 (See
[https://hudson.apache.org/hudson/job/Cassandra/747/])
apply authorization to queries
Patch by eevans for CASSANDRA-1708
CQL authentication
--
Key: CASSANDRA-1708
URL: https://issues.apache.org/jira/browse/CASSANDRA-1708
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 0.8
Attachments: Cass_auth_changes.patch,
v1-0001-CASSANDRA-1708-apply-authorization-to-queries.txt
Original Estimate: 0h
Remaining Estimate: 0h
CQL specification and implementation for authentication, (corresponds to the
{{login()}} RPC method).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2252) off-heap memtables
off-heap memtables -- Key: CASSANDRA-2252 URL: https://issues.apache.org/jira/browse/CASSANDRA-2252 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.8 The memtable design practically actively fights Java's GC design. Todd Lipcon gave a good explanation over on HBASE-3455. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2252) off-heap memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999734#comment-12999734 ] Jonathan Ellis commented on CASSANDRA-2252: --- Patches to add MemtableAllocator (based on Todd's MemStoreLAB) and off-heap allocation via FreeableMemory. I gave up on trying to do the allocation for this and interning during deserialize; the code got very tangled and felt fragile. Instead, we copy during Memtable.put, which feels right since there is no way to screw ourselves by forgetting to copy in a new code path. I think I'm willing to bite the extra copy for that. off-heap memtables -- Key: CASSANDRA-2252 URL: https://issues.apache.org/jira/browse/CASSANDRA-2252 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.8 Attachments: 0001-wip.txt, 0002-add-off-heap-MemtableAllocator-support.txt The memtable design practically actively fights Java's GC design. Todd Lipcon gave a good explanation over on HBASE-3455. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2252) off-heap memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2252: -- Attachment: 0002-add-off-heap-MemtableAllocator-support.txt 0001-wip.txt off-heap memtables -- Key: CASSANDRA-2252 URL: https://issues.apache.org/jira/browse/CASSANDRA-2252 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.8 Attachments: 0001-wip.txt, 0002-add-off-heap-MemtableAllocator-support.txt The memtable design practically actively fights Java's GC design. Todd Lipcon gave a good explanation over on HBASE-3455. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2252) off-heap memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2252: -- Attachment: 0002-add-off-heap-MemtableAllocator-support.txt 0001-add-MemtableAllocator.txt off-heap memtables -- Key: CASSANDRA-2252 URL: https://issues.apache.org/jira/browse/CASSANDRA-2252 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.8 Attachments: 0001-add-MemtableAllocator.txt, 0002-add-off-heap-MemtableAllocator-support.txt The memtable design practically actively fights Java's GC design. Todd Lipcon gave a good explanation over on HBASE-3455. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2252) off-heap memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2252: -- Attachment: (was: 0002-add-off-heap-MemtableAllocator-support.txt) off-heap memtables -- Key: CASSANDRA-2252 URL: https://issues.apache.org/jira/browse/CASSANDRA-2252 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.8 Attachments: 0001-add-MemtableAllocator.txt, 0002-add-off-heap-MemtableAllocator-support.txt The memtable design practically actively fights Java's GC design. Todd Lipcon gave a good explanation over on HBASE-3455. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2252) off-heap memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2252: -- Attachment: (was: 0001-wip.txt) off-heap memtables -- Key: CASSANDRA-2252 URL: https://issues.apache.org/jira/browse/CASSANDRA-2252 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.8 Attachments: 0001-add-MemtableAllocator.txt, 0002-add-off-heap-MemtableAllocator-support.txt The memtable design practically actively fights Java's GC design. Todd Lipcon gave a good explanation over on HBASE-3455. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1311) Support (asynchronous) triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999737#comment-12999737 ] Jonathan Ellis commented on CASSANDRA-1311: --- bq. Our solution is to make the storage of dangling trigger at replicas also part of log replay. Whenever a replica (slave) node receives a write request, it will durably log that it has to fire a trigger in case of a failure of the update coordinator (master). In case this slave node fails, it will come back up replaying the logs, installing any data item, and also firing triggers. This sounds really, really fragile. Grafting a pseudo-master onto Cassandra replication is a bad idea. Support (asynchronous) triggers --- Key: CASSANDRA-1311 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 Project: Cassandra Issue Type: New Feature Components: Contrib Reporter: Maxim Grinev Fix For: 0.8 Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf, ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Please find the motivation, triggers description and list of applications: http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ An example of using triggers for indexing: http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ Implementation details are attached. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
