[jira] [Commented] (CASSANDRA-2752) repair fails with java.io.EOFException
[ https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046984#comment-13046984 ] Muga Nishizawa commented on CASSANDRA-2752: --- It seems tmp files (e.g. XXX-tmp-XXX-Data.db) that receiver node creates during repair process are broken. EOFException occurs while RowIndexer is reading the broken files. According to result of scrub command, data files on sender nodes are not broken. > repair fails with java.io.EOFException > -- > > Key: CASSANDRA-2752 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2752 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8.0 >Reporter: Terje Marthinussen > > Issuing repair on node 1 (1.10.42.81) in a cluster quickly fails with > INFO [AntiEntropyStage:1] 2011-06-09 19:02:47,999 AntiEntropyService.java > (line 234) Queueing comparison # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306fb46e, /1 > .10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]>> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 468) Endpoints somewhere/1.10.42.81 and /1.10.42.82 have 2 range(s) out > of sync for (JP,XXX) on (Token(bytes[6e]),Token(bytes[313039])] > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 485) Performing streaming repair of 2 ranges for # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306 > fb46e, /1.10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,030 StreamOut.java (line 173) > Stream context metadata [/data/cassandra/node0/data/JP/XXX-g-3-Data.db > sections=1 progress=0/36592 - 0%], 1 sstables. > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,031 StreamOutSession.java > (line 174) Streaming to /1.10.42.82 > ERROR [CompactionExecutor:9] 2011-06-09 19:02:48,970 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:9,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > On .82 > ERROR [CompactionExecutor:12] 2011-06-09 19:02:48,051 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:12,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > ERROR [Thread-132] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line > 113) Fatal exception in thread Thread[Thread-132,5,main] > java.lang.RuntimeException: java.util.concurrent.ExecutionException: > java.io.EOFException > at > org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:152) > at > org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63) > at > org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) > Caused by: java.util.concurrent.Executi
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046981#comment-13046981 ] Jonathan Ellis commented on CASSANDRA-2474: --- 1. materialized view is a way of thinking about it, I'm not saying we require declaring special mview metadata (I would like to, but I think people will want "manual" control) 3. I like that idea 4. not sure what you mean. SQL is about "give me this projection, from this relation, where this predicate is satisfied." putting it in the FROM (relation) part requires the least special casing for the rest (projection + predicate look normal). Since the relation part is the logical part for QueryProcessor to determine "am I doing a transposed query?" it simplifies implementation too. 5. yes, you'd get the full range of expressivity, limited only by what the engine can handle (e.g., in my first example, the current supercolumn engine doesn't index subcolumns so "AND x > 100" would not be efficient). but you can see how this gives us room to add more power w/o needing more syntax or special casing in the parser. > CQL support for compound columns > > > Key: CASSANDRA-2474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 > Project: Cassandra > Issue Type: Sub-task > Components: API, Core >Reporter: Eric Evans > Labels: cql > Fix For: 1.0 > > > For the most part, this boils down to supporting the specification of > compound column names (the CQL syntax is colon-delimted terms), and then > teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046966#comment-13046966 ] T Jake Luciani commented on CASSANDRA-2474: --- I see what you mean... some more questions/ideas. 1. are you suggesting we only allow access to supercolumns in a materialized view? 2. if not, how would non-materialized view access a supercolumn? 3. should we use a UNION command to fetch many rows? 4. why do you need to use the FROM cf:key syntax? why not require parent keyword to also have a key predicate? 5. would you allow "parent >= 'a' and parent <= 'c'" > CQL support for compound columns > > > Key: CASSANDRA-2474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 > Project: Cassandra > Issue Type: Sub-task > Components: API, Core >Reporter: Eric Evans > Labels: cql > Fix For: 1.0 > > > For the most part, this boils down to supporting the specification of > compound column names (the CQL syntax is colon-delimted terms), and then > teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046950#comment-13046950 ] Jonathan Ellis commented on CASSANDRA-2474: --- bq. Doesn't this limit things to one row key? Right. This is fine, because - row is the unit of what we can do efficiently, multiget causes a lot of foot-shooting - query-within-row is exactly what you should be using mview rows for anyway, mixing data from different mviews? that has a code smell to it bq. you could use a SQL hint syntax that doesn't seem nearly as natural to me, and there is no good way distinguish between non-transposed where expressions (for keys) and transposed (for columns/subcolumns?) > CQL support for compound columns > > > Key: CASSANDRA-2474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 > Project: Cassandra > Issue Type: Sub-task > Components: API, Core >Reporter: Eric Evans > Labels: cql > Fix For: 1.0 > > > For the most part, this boils down to supporting the specification of > compound column names (the CQL syntax is colon-delimted terms), and then > teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2751) Improved Metrics collection
[ https://issues.apache.org/jira/browse/CASSANDRA-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan King updated CASSANDRA-2751: - Description: Collecting metrics in cassandra needs to be easier. Currently the amount of work required to expose one new metric in the server and consume it outside the server is way to high. In my mind, collecting a new metric in the server should be a single line of code and consuming it should be easily doable from any programming language. There are several options for better metrics collection on the JVM: https://github.com/twitter/ostrich https://github.com/codahale/metrics/ https://github.com/twitter/commons/tree/master/src/java/com/twitter/common/stats We should look at these was: Collecting metrics in cassandra needs to be easier. Currently the amount of work required to expose one new metric in the server and consume it outside the server is way to high. In my mind, collecting a new metric in the server should be a single line of code and consuming it should be easily doable from any programming language. There are several options for better metrics collection on the JVM: https://github.com/twitter/ostrich https://github.com/codahale/metrics/ We should look at these > Improved Metrics collection > --- > > Key: CASSANDRA-2751 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2751 > Project: Cassandra > Issue Type: Improvement >Reporter: Ryan King >Assignee: Ryan King > > Collecting metrics in cassandra needs to be easier. Currently the amount of > work required to expose one new metric in the server and consume it outside > the server is way to high. > In my mind, collecting a new metric in the server should be a single line of > code and consuming it should be easily doable from any programming language. > There are several options for better metrics collection on the JVM: > https://github.com/twitter/ostrich > https://github.com/codahale/metrics/ > https://github.com/twitter/commons/tree/master/src/java/com/twitter/common/stats > We should look at these -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2753) Capture the max client timestamp for an SSTable
[ https://issues.apache.org/jira/browse/CASSANDRA-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046939#comment-13046939 ] Alan Liang commented on CASSANDRA-2753: --- In this patch, I've captured the max timestamp and stored it as part of the stats file. I've encapsulated this file through a class called SSTableMetadata. Estimated histograms for row size and column counts and replay positions will also be available via this class. > Capture the max client timestamp for an SSTable > --- > > Key: CASSANDRA-2753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2753 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Alan Liang >Assignee: Alan Liang >Priority: Minor > Attachments: > 0003-capture-max-timestamp-for-sstable-and-introduced-SST.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046937#comment-13046937 ] T Jake Luciani commented on CASSANDRA-2474: --- Doesn't this limit things to one row key? If I have a CF of wide rows it would be nice to get back a transposed view of all rows.. you could use a SQL hint syntax like: select /*+TRANSPOSED*/ key, column, subcolumn, value from foo; > CQL support for compound columns > > > Key: CASSANDRA-2474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 > Project: Cassandra > Issue Type: Sub-task > Components: API, Core >Reporter: Eric Evans > Labels: cql > Fix For: 1.0 > > > For the most part, this boils down to supporting the specification of > compound column names (the CQL syntax is colon-delimted terms), and then > teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046937#comment-13046937
]
T Jake Luciani edited comment on CASSANDRA-2474 at 6/10/11 12:33 AM:
-
Doesn't this limit things to one row key?
If I have a CF of wide rows it would be nice to get back a transposed view of
all rows..
you could use a SQL hint syntax like:
{noformat}
select /*+TRANSPOSED*/ key, column, subcolumn, value from foo;
{noformat}
was (Author: tjake):
Doesn't this limit things to one row key?
If I have a CF of wide rows it would be nice to get back a transposed view of
all rows..
you could use a SQL hint syntax like:
select /*+TRANSPOSED*/ key, column, subcolumn, value from foo;
> CQL support for compound columns
>
>
> Key: CASSANDRA-2474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
> Labels: cql
> Fix For: 1.0
>
>
> For the most part, this boils down to supporting the specification of
> compound column names (the CQL syntax is colon-delimted terms), and then
> teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2735) Timestamp Based Compaction Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Liang updated CASSANDRA-2735: -- Attachment: (was: 0003-implemented-timestamp-bucketed-compaction-strategy-a.patch) > Timestamp Based Compaction Strategy > --- > > Key: CASSANDRA-2735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2735 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Alan Liang >Assignee: Alan Liang >Priority: Minor > Labels: compaction > Attachments: 0004-timestamp-bucketed-compaction-strategy.patch > > > Compaction strategy implementation based on max timestamp ordering of the > sstables while satisfying max sstable size, min and max compaction > thresholds. It also handles expiration of sstables based on a timestamp. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2735) Timestamp Based Compaction Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Liang updated CASSANDRA-2735: -- Attachment: (was: 0002-timestamp-bucketed-compaction-strategy.patch) > Timestamp Based Compaction Strategy > --- > > Key: CASSANDRA-2735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2735 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Alan Liang >Assignee: Alan Liang >Priority: Minor > Labels: compaction > Attachments: 0004-timestamp-bucketed-compaction-strategy.patch > > > Compaction strategy implementation based on max timestamp ordering of the > sstables while satisfying max sstable size, min and max compaction > thresholds. It also handles expiration of sstables based on a timestamp. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2735) Timestamp Based Compaction Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Liang updated CASSANDRA-2735: -- Attachment: 0004-timestamp-bucketed-compaction-strategy.patch New patch has code just for timestamp compaction strategy. > Timestamp Based Compaction Strategy > --- > > Key: CASSANDRA-2735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2735 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Alan Liang >Assignee: Alan Liang >Priority: Minor > Labels: compaction > Attachments: 0004-timestamp-bucketed-compaction-strategy.patch > > > Compaction strategy implementation based on max timestamp ordering of the > sstables while satisfying max sstable size, min and max compaction > thresholds. It also handles expiration of sstables based on a timestamp. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2753) Capture the max client timestamp for an SSTable
[ https://issues.apache.org/jira/browse/CASSANDRA-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Liang updated CASSANDRA-2753: -- Attachment: 0003-capture-max-timestamp-for-sstable-and-introduced-SST.patch > Capture the max client timestamp for an SSTable > --- > > Key: CASSANDRA-2753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2753 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Alan Liang >Assignee: Alan Liang >Priority: Minor > Attachments: > 0003-capture-max-timestamp-for-sstable-and-introduced-SST.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1610) Pluggable Compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Liang updated CASSANDRA-1610: -- Attachment: 0002-rename-major-minor-to-maximal-background-in-Compacti.patch 0001-pluggable-compaction.patch new patch incorporates suggestions by jbellis, also, renamed minor/major -> background/maximal > Pluggable Compaction > > > Key: CASSANDRA-1610 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1610 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Goffinet >Assignee: Alan Liang >Priority: Minor > Labels: compaction > Fix For: 1.0 > > Attachments: 0001-move-compaction-code-into-own-package.patch, > 0001-move-compaction-code-into-own-package.patch, > 0001-move-compaction-code-into-own-package.patch, > 0001-move-compaction-code-into-own-package.patch, > 0001-move-compaction-code-into-own-package.patch, > 0001-move-compaction-code-into-own-package.patch, > 0001-pluggable-compaction.patch, 0001-pluggable-compaction.patch, > 0002-Pluggable-Compaction-and-Expiration.patch, > 0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch, > 0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch, > 0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch, > 0002-pluggable-compaction.patch, > 0002-rename-major-minor-to-maximal-background-in-Compacti.patch > > > In CASSANDRA-1608, I proposed some changes on how compaction works. I think > it also makes sense to allow the ability to have pluggable compaction per CF. > There could be many types of workloads where this makes sense. One example we > had at Digg was to completely throw away certain SSTables after N days. > This ticket addresses making compaction pluggable only. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2743) add TABLE as a CQL alias for COLUMNFAMILY
[ https://issues.apache.org/jira/browse/CASSANDRA-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046919#comment-13046919 ] Hudson commented on CASSANDRA-2743: --- Integrated in Cassandra-0.8 #162 (See [https://builds.apache.org/job/Cassandra-0.8/162/]) add SCHEMA/TABLE as aliases for KS/CF patch by pyaskevich; reviewed by jbellis for CASSANDRA-2743 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1134110 Files : * /cassandra/branches/cassandra-0.8/test/system/test_cql.py * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g > add TABLE as a CQL alias for COLUMNFAMILY > - > > Key: CASSANDRA-2743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2743 > Project: Cassandra > Issue Type: Improvement > Components: API >Affects Versions: 0.8.0 >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.8.1 > > Attachments: CASSANDRA-2743.patch > > > This will make it easier on tools that support multiple databases like > SQLAlchemy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2744) stress.jar is not executable
[
https://issues.apache.org/jira/browse/CASSANDRA-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046917#comment-13046917
]
Hudson commented on CASSANDRA-2744:
---
Integrated in Cassandra-0.8 #162 (See
[https://builds.apache.org/job/Cassandra-0.8/162/])
Stress.java creates a jar by default.
Patch by Pavel Yaskevich, reviewed by brandonwilliams for CASSANDRA-2744
brandonwilliams :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1134108
Files :
* /cassandra/branches/cassandra-0.8/tools/stress/build.xml
> stress.jar is not executable
>
>
> Key: CASSANDRA-2744
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2744
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 0.8.0
>Reporter: Tyler Hobbs
>Assignee: Pavel Yaskevich
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-2744.patch
>
>
> If you build stress.jar by running 'ant jar' from tools/stress/ and try to
> execute it with 'java -jar stress.jar', you get the following error:
> {noformat}
> Failed to load Main-Class manifest attribute from
> stress.jar
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files
[
https://issues.apache.org/jira/browse/CASSANDRA-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046918#comment-13046918
]
Hudson commented on CASSANDRA-2386:
---
Integrated in Cassandra-0.8 #162 (See
[https://builds.apache.org/job/Cassandra-0.8/162/])
support sstable2json against snapshot sstables
patch by Patricio Echague; reviewed by jbellis for CASSANDRA-2386
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1134120
Files :
*
/cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/io/sstable/DescriptorTest.java
* /cassandra/branches/cassandra-0.8/CHANGES.txt
* /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/Descriptor.java
> sstable2json does not work on snapshot without moving the files
> ---
>
> Key: CASSANDRA-2386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2386
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Environment: Redhat Linux
>Reporter: Aslak Dirdal
>Assignee: Patricio Echague
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-trunk-2386-1.patch, CASSANDRA-trunk-2386.patch
>
>
> sstable2json
> ../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
> {
> Exception in thread "main" java.lang.NullPointerException: Unknown
> ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
> at
> org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
> at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
> at
> org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
> at
> org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
> at
> org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
> at
> org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
> sstable2json seem to think that the foldername "1301066898131-mysnapshot" is
> the Keyspace name.
> Moving the *.db files to a folder with the same name as the Keyspace is a
> workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-2480:
---
Attachment: CASSANDRA-2480-v3.patch
removed KEY special case.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480-v3.patch,
> CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2752) repair fails with java.io.EOFException
[ https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046897#comment-13046897 ] Chris Goffinet commented on CASSANDRA-2752: --- I am trying to track down a similar issue. Instead was bootstrapping a new node in my case. > repair fails with java.io.EOFException > -- > > Key: CASSANDRA-2752 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2752 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8.0 >Reporter: Terje Marthinussen > > Issuing repair on node 1 (1.10.42.81) in a cluster quickly fails with > INFO [AntiEntropyStage:1] 2011-06-09 19:02:47,999 AntiEntropyService.java > (line 234) Queueing comparison # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306fb46e, /1 > .10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]>> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 468) Endpoints somewhere/1.10.42.81 and /1.10.42.82 have 2 range(s) out > of sync for (JP,XXX) on (Token(bytes[6e]),Token(bytes[313039])] > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 485) Performing streaming repair of 2 ranges for # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306 > fb46e, /1.10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,030 StreamOut.java (line 173) > Stream context metadata [/data/cassandra/node0/data/JP/XXX-g-3-Data.db > sections=1 progress=0/36592 - 0%], 1 sstables. > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,031 StreamOutSession.java > (line 174) Streaming to /1.10.42.82 > ERROR [CompactionExecutor:9] 2011-06-09 19:02:48,970 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:9,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > On .82 > ERROR [CompactionExecutor:12] 2011-06-09 19:02:48,051 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:12,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > ERROR [Thread-132] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line > 113) Fatal exception in thread Thread[Thread-132,5,main] > java.lang.RuntimeException: java.util.concurrent.ExecutionException: > java.io.EOFException > at > org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:152) > at > org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63) > at > org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) > Caused by: java.util.concurrent.ExecutionException: java.io.EOFException > at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) > at java.util.concurrent.FutureTask.get(FutureT
[jira] [Updated] (CASSANDRA-2740) nodetool decommission should throw an error when there are extra params
[ https://issues.apache.org/jira/browse/CASSANDRA-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2740: -- Attachment: 2740.txt All zero-arg commands now complain when there's extra args. > nodetool decommission should throw an error when there are extra params > --- > > Key: CASSANDRA-2740 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2740 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Jon Hermes >Priority: Trivial > Fix For: 0.7.7 > > Attachments: 2740.txt > > > removetoken takes a token parameter, but decommission works against the node > where the call is issued. This allows confusion such as 'nodetool -h > localhost decommission ' actually decommissioning the local > node, instead of whatever was passed to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2740) nodetool decommission should throw an error when there are extra params
[ https://issues.apache.org/jira/browse/CASSANDRA-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046880#comment-13046880 ] Jonathan Ellis commented on CASSANDRA-2740: --- why add token param? > nodetool decommission should throw an error when there are extra params > --- > > Key: CASSANDRA-2740 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2740 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Jon Hermes >Priority: Trivial > Fix For: 0.7.7 > > > removetoken takes a token parameter, but decommission works against the node > where the call is issued. This allows confusion such as 'nodetool -h > localhost decommission ' actually decommissioning the local > node, instead of whatever was passed to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2500: -- Reviewer: rwjblue Robert, would you like to take a stab at reviewing this? > Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter > --- > > Key: CASSANDRA-2500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 > Project: Cassandra > Issue Type: Task >Reporter: Jon Hermes >Assignee: Jon Hermes > Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz > > > Create a ruby driver for CQL. > Lacking something standard (such as py-dbapi), going with something common > instead -- RoR ActiveRecord Connection Adapter > (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2740) nodetool decommission should throw an error when there are extra params
[ https://issues.apache.org/jira/browse/CASSANDRA-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046877#comment-13046877 ] Brandon Williams commented on CASSANDRA-2740: - For 1.0 I'd like to see decom work like rt, and take a token parameter, but I don't want to break existing jmx tools for 0.8, so let's just error on extra params there. > nodetool decommission should throw an error when there are extra params > --- > > Key: CASSANDRA-2740 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2740 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Jon Hermes >Priority: Trivial > Fix For: 0.7.7 > > > removetoken takes a token parameter, but decommission works against the node > where the call is issued. This allows confusion such as 'nodetool -h > localhost decommission ' actually decommissioning the local > node, instead of whatever was passed to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1134120 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/db/Table.java src/java/org/apache/cassandra/io/sstable/Descriptor.java test/unit/org/apache/cassa
Author: jbellis
Date: Thu Jun 9 22:37:05 2011
New Revision: 1134120
URL: http://svn.apache.org/viewvc?rev=1134120&view=rev
Log:
support sstable2json against snapshot sstables
patch by Patricio Echague; reviewed by jbellis for CASSANDRA-2386
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/Descriptor.java
cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/io/sstable/DescriptorTest.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1134120&r1=1134119&r2=1134120&view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Jun 9 22:37:05 2011
@@ -45,6 +45,7 @@
* fix nodetool ring use with Ec2Snitch (CASSANDRA-2733)
* fix removing columns and subcolumns that are supressed by a row or
supercolumn tombstone during replica resolution (CASSANDRA-2590)
+ * support sstable2json against snapshot sstables (CASSANDRA-2386)
0.8.0-final
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java?rev=1134120&r1=1134119&r2=1134120&view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
Thu Jun 9 22:37:05 2011
@@ -55,8 +55,9 @@ public class Table
{
public static final String SYSTEM_TABLE = "system";
+public static final String SNAPSHOT_SUBDIR_NAME = "snapshots";
+
private static final Logger logger = LoggerFactory.getLogger(Table.class);
-private static final String SNAPSHOT_SUBDIR_NAME = "snapshots";
/**
* accesses to CFS.memtable should acquire this for thread safety.
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/Descriptor.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/Descriptor.java?rev=1134120&r1=1134119&r2=1134120&view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/Descriptor.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/Descriptor.java
Thu Jun 9 22:37:05 2011
@@ -26,6 +26,7 @@ import java.util.StringTokenizer;
import com.google.common.base.Objects;
+import org.apache.cassandra.db.Table;
import org.apache.cassandra.utils.Pair;
/**
@@ -131,7 +132,7 @@ public class Descriptor
public static Pair fromFilename(File directory, String
name)
{
// name of parent directory is keyspace name
-String ksname = directory.getName();
+String ksname = extractKeyspaceName(directory);
// tokenize the filename
StringTokenizer st = new StringTokenizer(name, "-");
@@ -165,6 +166,43 @@ public class Descriptor
}
/**
+ * Extracts the keyspace name out of the directory name. Snapshot
directories have a slightly different
+ * path structure and need to be treated differently.
+ *
+ * Regular path: "/-[tmp-][-]-"
+ * Snapshot path:
"/snapshots//-[tmp-][-]-"
+ *
+ * @param directory a directory containing SSTables
+ * @return the keyspace name
+ */
+public static String extractKeyspaceName(File directory) {
+
+if (isSnapshotInPath(directory))
+{
+// We need to move backwards. If this is a snapshot, first parent
takes us to:
+// /snapshots/ and second call to parent takes us to
.
+return directory.getParentFile().getParentFile().getName();
+}
+return directory.getName();
+}
+
+/**
+ * @return TRUE if this directory represents a snapshot
directory. FALSE otherwise.
+ */
+private static boolean isSnapshotInPath(File directory) {
+File curDirectory = directory;
+while (curDirectory != null)
+{
+if (curDirectory.getName().equals(Table.SNAPSHOT_SUBDIR_NAME))
+return true;
+curDirectory = curDirectory.getParentFile();
+}
+
+// The directory does not represent a snapshot directory.
+return false;
+}
+
+/**
* @return A clone of this descriptor with the given 'temporary' status.
*/
public Descriptor asTemporary(boolean temporary)
Modified:
cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/io/sstable/DescriptorTest.java
URL:
http://svn.apache.
[jira] [Updated] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files
[
https://issues.apache.org/jira/browse/CASSANDRA-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patricio Echague updated CASSANDRA-2386:
Attachment: CASSANDRA-trunk-2386-1.patch
> sstable2json does not work on snapshot without moving the files
> ---
>
> Key: CASSANDRA-2386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2386
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Environment: Redhat Linux
>Reporter: Aslak Dirdal
>Assignee: Patricio Echague
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-trunk-2386-1.patch, CASSANDRA-trunk-2386.patch
>
>
> sstable2json
> ../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
> {
> Exception in thread "main" java.lang.NullPointerException: Unknown
> ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
> at
> org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
> at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
> at
> org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
> at
> org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
> at
> org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
> at
> org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
> sstable2json seem to think that the foldername "1301066898131-mysnapshot" is
> the Keyspace name.
> Moving the *.db files to a folder with the same name as the Keyspace is a
> workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2740) nodetool decommission should throw an error when there are extra params
[ https://issues.apache.org/jira/browse/CASSANDRA-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes reassigned CASSANDRA-2740: - Assignee: Jon Hermes > nodetool decommission should throw an error when there are extra params > --- > > Key: CASSANDRA-2740 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2740 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Jon Hermes >Priority: Trivial > Fix For: 0.7.7 > > > removetoken takes a token parameter, but decommission works against the node > where the call is issued. This allows confusion such as 'nodetool -h > localhost decommission ' actually decommissioning the local > node, instead of whatever was passed to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2743) add TABLE as a CQL alias for COLUMNFAMILY
[ https://issues.apache.org/jira/browse/CASSANDRA-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046856#comment-13046856 ] Jonathan Ellis edited comment on CASSANDRA-2743 at 6/9/11 10:16 PM: sounds good, committed was (Author: jbellis): committed > add TABLE as a CQL alias for COLUMNFAMILY > - > > Key: CASSANDRA-2743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2743 > Project: Cassandra > Issue Type: Improvement > Components: API >Affects Versions: 0.8.0 >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.8.1 > > Attachments: CASSANDRA-2743.patch > > > This will make it easier on tools that support multiple databases like > SQLAlchemy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1134110 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/cql/Cql.g test/system/test_cql.py
Author: jbellis
Date: Thu Jun 9 22:16:07 2011
New Revision: 1134110
URL: http://svn.apache.org/viewvc?rev=1134110&view=rev
Log:
add SCHEMA/TABLE as aliases for KS/CF
patch by pyaskevich; reviewed by jbellis for CASSANDRA-2743
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g
cassandra/branches/cassandra-0.8/test/system/test_cql.py
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1134110&r1=1134109&r2=1134110&view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Jun 9 22:16:07 2011
@@ -8,6 +8,7 @@
- improve JDBC spec compliance (CASSANDRA-2720)
- ALTER COLUMNFAMILY (CASSANDRA-1709)
- DROP INDEX (CASSANDRA-2617)
+ - add SCHEMA/TABLE as aliases for KS/CF (CASSANDRA-2743)
* add support for comparator parameters and a generic ReverseType
(CASSANDRA-2355)
* add CompositeType and DynamicCompositeType (CASSANDRA-2231)
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g?rev=1134110&r1=1134109&r2=1134110&view=diff
==
--- cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g
(original)
+++ cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g
Thu Jun 9 22:16:07 2011
@@ -498,8 +498,10 @@ K_TRUNCATE:T R U N C A T E;
K_DELETE: D E L E T E;
K_IN: I N;
K_CREATE: C R E A T E;
-K_KEYSPACE:K E Y S P A C E;
-K_COLUMNFAMILY: C O L U M N F A M I L Y;
+K_KEYSPACE:( K E Y S P A C E
+ | S C H E M A );
+K_COLUMNFAMILY:( C O L U M N F A M I L Y
+ | T A B L E );
K_INDEX: I N D E X;
K_ON: O N;
K_DROP:D R O P;
Modified: cassandra/branches/cassandra-0.8/test/system/test_cql.py
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/test/system/test_cql.py?rev=1134110&r1=1134109&r2=1134110&view=diff
==
--- cassandra/branches/cassandra-0.8/test/system/test_cql.py (original)
+++ cassandra/branches/cassandra-0.8/test/system/test_cql.py Thu Jun 9
22:16:07 2011
@@ -44,7 +44,7 @@ def load_sample(dbconn):
WITH comparator = ascii AND default_validation = ascii;
""")
dbconn.execute("""
-CREATE COLUMNFAMILY StandardString2 (KEY text PRIMARY KEY)
+CREATE TABLE StandardString2 (KEY text PRIMARY KEY)
WITH comparator = ascii AND default_validation = ascii;
""")
dbconn.execute("""
@@ -56,7 +56,7 @@ def load_sample(dbconn):
WITH comparator = bigint AND default_validation = ascii;
""")
dbconn.execute("""
-CREATE COLUMNFAMILY StandardIntegerA (KEY text PRIMARY KEY)
+CREATE TABLE StandardIntegerA (KEY text PRIMARY KEY)
WITH comparator = varint AND default_validation = ascii;
""")
dbconn.execute("""
@@ -76,7 +76,7 @@ def load_sample(dbconn):
WITH comparator = ascii AND default_validation = ascii;
""")
dbconn.execute("""
-CREATE COLUMNFAMILY CounterCF (KEY text PRIMARY KEY, count_me counter)
+CREATE TABLE CounterCF (KEY text PRIMARY KEY, count_me counter)
WITH comparator = ascii AND default_validation = counter;
""")
dbconn.execute("CREATE INDEX ON IndexedA (birthdate)")
@@ -414,7 +414,7 @@ class TestCql(ThriftTester):
"create a new keyspace"
cursor = init()
cursor.execute("""
-CREATE KEYSPACE TestKeyspace42 WITH strategy_options:DC1 = '1'
+CREATE SCHEMA TestKeyspace42 WITH strategy_options:DC1 = '1'
AND strategy_class = 'NetworkTopologyStrategy'
""")
@@ -436,7 +436,7 @@ class TestCql(ThriftTester):
# TODO: temporary (until this can be done with CQL).
thrift_client.describe_keyspace("Keyspace4Drop")
-cursor.execute('DROP KEYSPACE Keyspace4Drop;')
+cursor.execute('DROP SCHEMA Keyspace4Drop;')
# Technically this should throw a ttypes.NotFound(), but this is
# temporary and so not worth requiring it on PYTHONPATH.
@@ -448,7 +448,7 @@ class TestCql(ThriftTester):
"create a new column family"
cursor = init()
cursor.execute("""
- CREATE KEYSPACE CreateCFKeyspace WITH
strategy_options:replication_factor = '1'
+ CREATE SCHEMA CreateCFKeyspace WITH
strategy_options:replication_factor = '1'
AND strategy_class = 'SimpleStrategy';
""")
cursor.execute("USE CreateCFKeyspace;")
svn commit: r1134109 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/service/ test/unit/org/apache/cassandra/ t
Author: jbellis Date: Thu Jun 9 22:15:25 2011 New Revision: 1134109 URL: http://svn.apache.org/viewvc?rev=1134109&view=rev Log: merge from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/CHANGES.txt cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RowRepairResolver.java cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/Util.java cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/TableTest.java cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/service/RowResolverTest.java Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jun 9 22:15:25 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7:1026516-1133391 +/cassandra/branches/cassandra-0.7:1026516-1133874 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/branches/cassandra-0.8:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0:1125021-1130369 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1134109&r1=1134108&r2=1134109&view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Jun 9 22:15:25 2011 @@ -42,6 +42,8 @@ by nio sockets (CASSANDRA-2654) * restrict repair streaming to specific columnfamilies (CASSANDRA-2280) * fix nodetool ring use with Ec2Snitch (CASSANDRA-2733) + * fix removing columns and subcolumns that are supressed by a row or + supercolumn tombstone during replica resolution (CASSANDRA-2590) 0.8.0-final Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jun 9 22:15:25 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-1133391 +/cassandra/branches/cassandra-0.7/contrib:1026516-1133874 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jun 9 22:15:25 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1133391 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1133874 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jun 9 22:15:25 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1133391 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1133
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046853#comment-13046853 ] Jonathan Ellis commented on CASSANDRA-2474: --- Remember that the point of this is to support materialized-view-in-a-row use cases. So essentially, we're turning a wide row into a skinny table -- foo:bar is then the materialized view represented by one row of the original CF. > CQL support for compound columns > > > Key: CASSANDRA-2474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 > Project: Cassandra > Issue Type: Sub-task > Components: API, Core >Reporter: Eric Evans > Labels: cql > Fix For: 1.0 > > > For the most part, this boils down to supporting the specification of > compound column names (the CQL syntax is colon-delimted terms), and then > teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046852#comment-13046852
]
Pavel Yaskevich commented on CASSANDRA-2480:
Ok, if you think that this is a good idea I will do it.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1134108 - /cassandra/branches/cassandra-0.8/tools/stress/build.xml
Author: brandonwilliams Date: Thu Jun 9 22:10:19 2011 New Revision: 1134108 URL: http://svn.apache.org/viewvc?rev=1134108&view=rev Log: Stress.java creates a jar by default. Patch by Pavel Yaskevich, reviewed by brandonwilliams for CASSANDRA-2744 Modified: cassandra/branches/cassandra-0.8/tools/stress/build.xml Modified: cassandra/branches/cassandra-0.8/tools/stress/build.xml URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/tools/stress/build.xml?rev=1134108&r1=1134107&r2=1134108&view=diff == --- cassandra/branches/cassandra-0.8/tools/stress/build.xml (original) +++ cassandra/branches/cassandra-0.8/tools/stress/build.xml Thu Jun 9 22:10:19 2011 @@ -17,7 +17,7 @@ ~ specific language governing permissions and limitations ~ under the License. --> - + @@ -49,9 +49,19 @@ + + + + + - + + + + + + +
[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046849#comment-13046849
]
Jonathan Ellis commented on CASSANDRA-2480:
---
bq. if we will try to compare without check it will fail
well, yes, but that's why I just wrote that "all the key and column name
comparisons should be case insensitive" :)
bq. you will need to convert it to string before uppercase/downcase and then
uppercase/downcase key given by user and compare them.
Right. (It may well be that we want to keep a String version of the key name in
CFMD as well for efficiency.)
bq. We can't uppercase user given key automatically.
Why not? It originates as a string, so either (1) we can just leave it as a
string or (2) if we convert to bytebuffer we know what the encoding is so we
can convert back to string.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2744) stress.jar is not executable
[
https://issues.apache.org/jira/browse/CASSANDRA-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-2744:
---
Attachment: (was: CASSANDRA-2744.patch)
> stress.jar is not executable
>
>
> Key: CASSANDRA-2744
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2744
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 0.8.0
>Reporter: Tyler Hobbs
>Assignee: Pavel Yaskevich
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-2744.patch
>
>
> If you build stress.jar by running 'ant jar' from tools/stress/ and try to
> execute it with 'java -jar stress.jar', you get the following error:
> {noformat}
> Failed to load Main-Class manifest attribute from
> stress.jar
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2744) stress.jar is not executable
[
https://issues.apache.org/jira/browse/CASSANDRA-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-2744:
---
Attachment: CASSANDRA-2744.patch
jar is default task now.
> stress.jar is not executable
>
>
> Key: CASSANDRA-2744
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2744
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 0.8.0
>Reporter: Tyler Hobbs
>Assignee: Pavel Yaskevich
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-2744.patch
>
>
> If you build stress.jar by running 'ant jar' from tools/stress/ and try to
> execute it with 'java -jar stress.jar', you get the following error:
> {noformat}
> Failed to load Main-Class manifest attribute from
> stress.jar
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046843#comment-13046843 ] Rick Shaw commented on CASSANDRA-2474: -- seeing a key value (bar) in a FROM clause seems pretty unnatural for "SQL-like". And a column value in a WHERE clause? I see you are trying to make it cleaner and simpler to declare but it really stretches the semantics of the FROM and the WHERE clauses. > CQL support for compound columns > > > Key: CASSANDRA-2474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 > Project: Cassandra > Issue Type: Sub-task > Components: API, Core >Reporter: Eric Evans > Labels: cql > Fix For: 1.0 > > > For the most part, this boils down to supporting the specification of > compound column names (the CQL syntax is colon-delimted terms), and then > teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2744) stress.jar is not executable
[
https://issues.apache.org/jira/browse/CASSANDRA-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-2744:
---
Reviewer: brandon.williams (was: jbellis)
> stress.jar is not executable
>
>
> Key: CASSANDRA-2744
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2744
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 0.8.0
>Reporter: Tyler Hobbs
>Assignee: Pavel Yaskevich
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-2744.patch
>
>
> If you build stress.jar by running 'ant jar' from tools/stress/ and try to
> execute it with 'java -jar stress.jar', you get the following error:
> {noformat}
> Failed to load Main-Class manifest attribute from
> stress.jar
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046834#comment-13046834
]
Jonathan Ellis commented on CASSANDRA-2474:
---
I now think the original idea from CASSANDRA-2025 of "SELECT columnA:x,
columnA:y FROM foo WHERE key = 'bar'" is the wrong way to go. Instead, moving
the compoundness-specifier to the "column parent" is a better fit:
{quote}
SELECT x, y, FROM foo:bar WHERE parent='columnA'
{quote}
(Note that "parent" would be a configurable alias, a la key_alias today.) This
generalizes to deeper nesting, if we wish to support that:
{quote}
select a, b FROM foo:bar:columnA where subparent='x'
{quote}
This is both a better match for existing supercolumn semantics (so translation
to StorageProxy requests is straightforward) as well as a better fit for APIs
designed for SQL like JDBC.
> CQL support for compound columns
>
>
> Key: CASSANDRA-2474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
> Labels: cql
> Fix For: 1.0
>
>
> For the most part, this boils down to supporting the specification of
> compound column names (the CQL syntax is colon-delimted terms), and then
> teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046831#comment-13046831
]
Pavel Yaskevich commented on CASSANDRA-2480:
good but for example user writes "SELECT * FROM users WHERE key = 1",
DEFAULT_KEY_NAME is KEY (uppercase) so if we will try to compare without check
it will fail because key != KEY also don't forget that getKeyName() returns
ByteBuffer so to compare case insensitive CFMetaData.getKeyName() you will need
to convert it to string before uppercase/downcase and then uppercase/downcase
key given by user and compare them. We can't uppercase user given key
automatically.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2728) Update the JDBC semantics contained in the class CResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2728:
-
Summary: Update the JDBC semantics contained in the class CResultSet (was:
0)
> Update the JDBC semantics contained in the class CResultSet
> ---
>
> Key: CASSANDRA-2728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2728
> Project: Cassandra
> Issue Type: Sub-task
>Affects Versions: 0.8.0
>Reporter: Rick Shaw
>Assignee: Rick Shaw
>Priority: Minor
> Labels: cql, jdbc
> Fix For: 0.8.1
>
>
> {{CResultSet}} is the Cassandra implementation class for the JDBC
> {{ResultSet}} interface.
> This key class needs to strictly adhere to the semantics laid down for a JDBC
> implementation.
> All required methods that will _not_ be implemented in some way by this class
> are placed in the {{AbstractResultSet}} class and are extended by this
> implementation class. Modifications to {{AbstractResultSet}} are covered by
> [CASSANDRA-2725|https://issues.apache.org/jira/browse/CASSANDRA-2725].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-2720) The current implementation of CassandraConnection does not always follow documented semantics for a JDBC Connection interface
[
https://issues.apache.org/jira/browse/CASSANDRA-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw reopened CASSANDRA-2720:
--
Adding additional functionality to the URL Processing and connection to the
Authentication and Authorization features of the {{Connection}}
> The current implementation of CassandraConnection does not always follow
> documented semantics for a JDBC Connection interface
> -
>
> Key: CASSANDRA-2720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2720
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Affects Versions: 0.8.0 beta 2
>Reporter: Rick Shaw
>Assignee: Rick Shaw
>Priority: Minor
> Labels: cql, drivers, jdbc
> Fix For: 0.8.1
>
> Attachments: Cleanup-semantics for-a JDBC-Connection-v1.txt,
> Cleanup-semantics-for-a-JDBC-Connection-v2.txt
>
>
> While the current implementation of many of the classes in the JDBC driver
> implementation are practical to get the driver to work they do not always
> obey the documented semantics for the associated interfaces. I am proposing
> making a pass over the involved implementation members to start the
> "tightening" process that will need to happen to use this driver in other
> tools an programs that expect stricter adherence than is currently present.
> Broad areas of attention are:
> - Use of {{SQLFeatureNotSupportedException}} not
> {{UnsupportedOperationException}} for methods that The Cassandra
> Implementation does not support.
> - Checking in appropriate methods for the prescribed throwing of
> {{SQLException}} if the method is called on a closed connection.
> - providing method implementations for all methods that are not optional even
> it it is to return NULL (as prescribed in the Interface description.)
> I will cut additional JIRA tickets for other components in the suite.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046824#comment-13046824
]
Jonathan Ellis edited comment on CASSANDRA-2480 at 6/9/11 9:33 PM:
---
all the key and column name comparisons should be case insensitive (and we
force keyAlias to be ascii, so you don't need to worry about it being some
weird bytes stuff). so shouldn't need special cases.
was (Author: jbellis):
all the key comparisons should be case insensitive (and we force keyAlias
to be ascii, so you don't need to worry about it being some weird bytes stuff).
so shouldn't need special cases.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046824#comment-13046824
]
Jonathan Ellis commented on CASSANDRA-2480:
---
all the key comparisons should be case insensitive (and we force keyAlias to be
ascii, so you don't need to worry about it being some weird bytes stuff). so
shouldn't need special cases.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046820#comment-13046820
]
Pavel Yaskevich commented on CASSANDRA-2480:
I'd like to do that too but you should not forget that user can spell KEY in
different ways - key, KEY, etc. so we will need to do a check anyway because
DEFAUL_KEY_NAME is KEY, so I have decided that this way will be the most
elegant solution to make it a special case with only one check.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046813#comment-13046813
]
Jonathan Ellis commented on CASSANDRA-2480:
---
I'd like to get rid of the special casing around "if it's KEY treat it
differently". KEY should just be the default alias and otherwise treated the
same.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2728) 0
[
https://issues.apache.org/jira/browse/CASSANDRA-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2728:
-
Component/s: (was: API)
Priority: Minor (was: Major)
Affects Version/s: (was: 0.8.0 beta 2)
0.8.0
Labels: cql jdbc (was: )
Summary: 0 (was: Update the JDBC semantics contained in the
class CResultSet)
> 0
> -
>
> Key: CASSANDRA-2728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2728
> Project: Cassandra
> Issue Type: Sub-task
>Affects Versions: 0.8.0
>Reporter: Rick Shaw
>Assignee: Rick Shaw
>Priority: Minor
> Labels: cql, jdbc
> Fix For: 0.8.1
>
>
> {{CResultSet}} is the Cassandra implementation class for the JDBC
> {{ResultSet}} interface.
> This key class needs to strictly adhere to the semantics laid down for a JDBC
> implementation.
> All required methods that will _not_ be implemented in some way by this class
> are placed in the {{AbstractResultSet}} class and are extended by this
> implementation class. Modifications to {{AbstractResultSet}} are covered by
> [CASSANDRA-2725|https://issues.apache.org/jira/browse/CASSANDRA-2725].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046810#comment-13046810
]
Pavel Yaskevich commented on CASSANDRA-2480:
If you mean keyName variable and constructors taking a keyAlias in there - that
is used to store a keyAlias which comes from statement to compare it with a
real keyAlias stored in CFMetaData.
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046806#comment-13046806
]
Jonathan Ellis commented on CASSANDRA-2480:
---
why do we need to duplicate keyalias in the AbstractModification? Shouldn't
that come from the CF metadata?
> Named keys / virtual columns
>
>
> Key: CASSANDRA-2480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Pavel Yaskevich
> Labels: cql
> Fix For: 0.8.1, 1.0
>
> Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to
> keys (column family-wide). This could be utilized to introduce the concept
> of "virtual columns" in CQL. Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for
> example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of
> this issue it should also be possible to assign a name to the key and treat
> as if it were another column. For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read:
> when using the {{KEY}} keyword), but if the key is named, and the name is
> used in a {{SELECT}}, the key's name and value will be returned in the column
> results, sorted according to the comparator (_Note: we'll need to figure out
> what that means with respect to differently typed keys_).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2756) Make CQL CREATE KS/CF not return until the operation is complete
Make CQL CREATE KS/CF not return until the operation is complete Key: CASSANDRA-2756 URL: https://issues.apache.org/jira/browse/CASSANDRA-2756 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 0.8.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.8.1 this would be more in line with the principle of least surprise, and would avoid the need for everyone who does programmatic schema manipulation to re-invent logic like CASSANDRA-2649. CliClient.validateSchemaIsSettled is a good template for the logic we want. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2735) Timestamp Based Compaction Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046750#comment-13046750 ] Alan Liang edited comment on CASSANDRA-2735 at 6/9/11 8:01 PM: --- Splitting out the capturing of max client supplied timestamp into a separate ticket (#2753) so that other tickets can benefit. was (Author: alanliang): Splitting out the capturing of max client supplied timestamp into a separate ticket so that other tickets can benefit. > Timestamp Based Compaction Strategy > --- > > Key: CASSANDRA-2735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2735 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Alan Liang >Assignee: Alan Liang >Priority: Minor > Labels: compaction > Attachments: 0002-timestamp-bucketed-compaction-strategy.patch, > 0003-implemented-timestamp-bucketed-compaction-strategy-a.patch > > > Compaction strategy implementation based on max timestamp ordering of the > sstables while satisfying max sstable size, min and max compaction > thresholds. It also handles expiration of sstables based on a timestamp. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2500: -- Attachment: (was: rbcql-0.0.0.tgz) > Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter > --- > > Key: CASSANDRA-2500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 > Project: Cassandra > Issue Type: Task >Reporter: Jon Hermes >Assignee: Jon Hermes > Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz > > > Create a ruby driver for CQL. > Lacking something standard (such as py-dbapi), going with something common > instead -- RoR ActiveRecord Connection Adapter > (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2500: -- Attachment: rbcql-0.0.0.tgz Oops, left some comments in. > Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter > --- > > Key: CASSANDRA-2500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 > Project: Cassandra > Issue Type: Task >Reporter: Jon Hermes >Assignee: Jon Hermes > Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz > > > Create a ruby driver for CQL. > Lacking something standard (such as py-dbapi), going with something common > instead -- RoR ActiveRecord Connection Adapter > (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[
https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2500:
--
Attachment: rbcql-0.0.0.tgz
v2.
Attaching rbcql ("CassDBD" in DBI parlance). No longer takes the `old JDBC`
approach of returning thrift objects, conforms to DBI return standards of array
of values and a matching array of column_info containing type info and column
names, the marshalling etc. is handled by DBI.
Now also correctly tracks schema changes by REing queries as they come in (what
pycql does). Should drop into a Rails system by including the package, changing
the DBI-URLs to prefix with "Cass", and making sure the input code is CQL, not
SQL.
Still not sure how best to require ruby c* bindings. (Looking at the
cassandra-rubygem, they include the bindings in a vendor dir and keep them up
to date.) Right now this expects interface/thrift/gen-rb/ to be in the same
directory.
2622 problem is fixed by including key_alias info in the internal metadata
(rubycql's copy of the schema).
> Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
> ---
>
> Key: CASSANDRA-2500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2500
> Project: Cassandra
> Issue Type: Task
>Reporter: Jon Hermes
>Assignee: Jon Hermes
> Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz
>
>
> Create a ruby driver for CQL.
> Lacking something standard (such as py-dbapi), going with something common
> instead -- RoR ActiveRecord Connection Adapter
> (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2754) Consolidating Ticket for JDBC Semantic Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046775#comment-13046775 ] Rick Shaw edited comment on CASSANDRA-2754 at 6/9/11 7:56 PM: -- The v1 patch assumes the JDBC package is located at o.a.c.cql.jdbc. was (Author: ardot): The v1 patch assume the JDBC package is located at o.a.c.cql.jdbc. > Consolidating Ticket for JDBC Semantic Improvements > --- > > Key: CASSANDRA-2754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2754 > Project: Cassandra > Issue Type: Improvement >Reporter: Rick Shaw >Assignee: Rick Shaw >Priority: Minor > Labels: CQL, JDBC > Fix For: 0.7.7 > > Attachments: jdbc-consoidated-v1.txt > > > First round of improved semantics for the JDBC Suite require a coordinated > patch that covers multiple Classes in o.a.c.cql.jdbc package. This ticket is > meant to house the consolidated patch and to organize the multiple existing > tickets as sub-tickets relating to this topic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2754) Consolidating Ticket for JDBC Semantic Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Shaw updated CASSANDRA-2754: - Attachment: jdbc-consoidated-v1.txt The v1 patch assume the JDBC package is located at o.a.c.cql.jdbc. > Consolidating Ticket for JDBC Semantic Improvements > --- > > Key: CASSANDRA-2754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2754 > Project: Cassandra > Issue Type: Improvement >Reporter: Rick Shaw >Assignee: Rick Shaw >Priority: Minor > Labels: CQL, JDBC > Fix For: 0.7.7 > > Attachments: jdbc-consoidated-v1.txt > > > First round of improved semantics for the JDBC Suite require a coordinated > patch that covers multiple Classes in o.a.c.cql.jdbc package. This ticket is > meant to house the consolidated patch and to organize the multiple existing > tickets as sub-tickets relating to this topic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2103) expiring counter columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046772#comment-13046772 ] Jonathan Ellis commented on CASSANDRA-2103: --- We're going to address this with pluggable compaction strategies instead, specifically CASSANDRA-2735. > expiring counter columns > > > Key: CASSANDRA-2103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2103 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 0.8 beta 1 >Reporter: Kelvin Kakugawa > Attachments: 0001-CASSANDRA-2103-expiring-counters-logic-tests.patch > > > add ttl functionality to counter columns. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2735) Timestamp Based Compaction Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046771#comment-13046771 ] Jonathan Ellis commented on CASSANDRA-2735: --- ... that would be CASSANDRA-2753. > Timestamp Based Compaction Strategy > --- > > Key: CASSANDRA-2735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2735 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Alan Liang >Assignee: Alan Liang >Priority: Minor > Labels: compaction > Attachments: 0002-timestamp-bucketed-compaction-strategy.patch, > 0003-implemented-timestamp-bucketed-compaction-strategy-a.patch > > > Compaction strategy implementation based on max timestamp ordering of the > sstables while satisfying max sstable size, min and max compaction > thresholds. It also handles expiration of sstables based on a timestamp. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2755) ColumnFamilyRecordWriter fails to throw a write exception encountered after the user begins to close the writer
ColumnFamilyRecordWriter fails to throw a write exception encountered after the
user begins to close the writer
---
Key: CASSANDRA-2755
URL: https://issues.apache.org/jira/browse/CASSANDRA-2755
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.0
Reporter: Greg Katz
There appears to be a race condition in {{ColumnFamilyRecordWriter}} that can
result in the loss of an exception. Here is how it can happen (W stands for the
{{RangeClient}}'s worker thread; U stands for the {{ColumnFamilyRecordWriter}}
user's thread):
# W: {{RangeClient}}'s {{run}} method catches an exception originating in the
Thrift client/socket, but doesn't get a chance to set it on the
{{lastException}} field before it the thread is preempted.
# U: The user calls {{close}} which calls {{stopNicely}}. Because the
{{lastException}} field is null, {{stopNicely}} does not throw anything.
{{close}} then joins on the worker thread.
# W: The {{RangeClient}}'s {{run}} method sets the {{lastException}} field and
exits.
# U: Although the thread in {{close}} is waiting for the worker thread to exit,
it has already checked the {{lastException}} field so it doesn't detect the
presence of the last exception. Instead, {{close}} returns without throwing
anything.
This race condition means that intermittently write failures will go undetected.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2729) Update the JDBC semantics contained in the interface CassandraResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2729:
-
Issue Type: Sub-task (was: Improvement)
Parent: CASSANDRA-2754
> Update the JDBC semantics contained in the interface CassandraResultSet
> ---
>
> Key: CASSANDRA-2729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2729
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Affects Versions: 0.8.0 beta 2
>Reporter: Rick Shaw
>Assignee: Rick Shaw
>Priority: Minor
> Fix For: 0.8.1
>
>
> The {{CassandraResultSet}} is an interface that defines the extended set of
> methods that are implemented in the Cassandra implementation of the JDBC
> {{ResultSet}}.
> It can be used with the {{unwrap(Class)}} method to access the extended
> methods of the Cassandra specific implementation.
> This improvement adds a "{{throws SQLException}}" clause to each additional
> method of the interface to better align with the existing semantics of
> methods in a {{ResultSet}} implementation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2720) The current implementation of CassandraConnection does not always follow documented semantics for a JDBC Connection interface
[
https://issues.apache.org/jira/browse/CASSANDRA-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2720:
-
Issue Type: Sub-task (was: Improvement)
Parent: CASSANDRA-2754
> The current implementation of CassandraConnection does not always follow
> documented semantics for a JDBC Connection interface
> -
>
> Key: CASSANDRA-2720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2720
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Affects Versions: 0.8.0 beta 2
>Reporter: Rick Shaw
>Assignee: Rick Shaw
>Priority: Minor
> Labels: cql, drivers, jdbc
> Fix For: 0.8.1
>
> Attachments: Cleanup-semantics for-a JDBC-Connection-v1.txt,
> Cleanup-semantics-for-a-JDBC-Connection-v2.txt
>
>
> While the current implementation of many of the classes in the JDBC driver
> implementation are practical to get the driver to work they do not always
> obey the documented semantics for the associated interfaces. I am proposing
> making a pass over the involved implementation members to start the
> "tightening" process that will need to happen to use this driver in other
> tools an programs that expect stricter adherence than is currently present.
> Broad areas of attention are:
> - Use of {{SQLFeatureNotSupportedException}} not
> {{UnsupportedOperationException}} for methods that The Cassandra
> Implementation does not support.
> - Checking in appropriate methods for the prescribed throwing of
> {{SQLException}} if the method is called on a closed connection.
> - providing method implementations for all methods that are not optional even
> it it is to return NULL (as prescribed in the Interface description.)
> I will cut additional JIRA tickets for other components in the suite.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2725) Update the JDBC semantics contained in the class AbstractResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2725:
-
Issue Type: Sub-task (was: Improvement)
Parent: CASSANDRA-2754
> Update the JDBC semantics contained in the class AbstractResultSet
> --
>
> Key: CASSANDRA-2725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2725
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Affects Versions: 0.8.0 beta 2
>Reporter: Rick Shaw
>Assignee: Rick Shaw
>Priority: Minor
> Labels: cql, jdbc
> Fix For: 0.8.1
>
>
> The {{AbstractResultSet}} cleverly isolates all the methods that are not
> planned to be implemented in the next release of of the JDBC Result Set
> implemented by the class {{CResultSet}}. This improvement will tighten the
> JDBC semantics for this set of methods.
> This improvement is related to
> [CASSANDRA-2720|https://issues.apache.org/jira/browse/CASSANDRA-2720] but is
> not blocked by it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2728) Update the JDBC semantics contained in the class CResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2728:
-
Issue Type: Sub-task (was: Improvement)
Parent: CASSANDRA-2754
> Update the JDBC semantics contained in the class CResultSet
> ---
>
> Key: CASSANDRA-2728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2728
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Affects Versions: 0.8.0 beta 2
>Reporter: Rick Shaw
>Assignee: Rick Shaw
> Fix For: 0.8.1
>
>
> {{CResultSet}} is the Cassandra implementation class for the JDBC
> {{ResultSet}} interface.
> This key class needs to strictly adhere to the semantics laid down for a JDBC
> implementation.
> All required methods that will _not_ be implemented in some way by this class
> are placed in the {{AbstractResultSet}} class and are extended by this
> implementation class. Modifications to {{AbstractResultSet}} are covered by
> [CASSANDRA-2725|https://issues.apache.org/jira/browse/CASSANDRA-2725].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2754) Consolidating Ticket for JDBC Semantic Improvements
Consolidating Ticket for JDBC Semantic Improvements --- Key: CASSANDRA-2754 URL: https://issues.apache.org/jira/browse/CASSANDRA-2754 Project: Cassandra Issue Type: Improvement Reporter: Rick Shaw Assignee: Rick Shaw Priority: Minor Fix For: 0.7.7 First round of improved semantics for the JDBC Suite require a coordinated patch that covers multiple Classes in o.a.c.cql.jdbc package. This ticket is meant to house the consolidated patch and to organize the multiple existing tickets as sub-tickets relating to this topic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2452) New EC2 Snitch to use public ip and hence natively support for EC2 mult-region's.
[ https://issues.apache.org/jira/browse/CASSANDRA-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2452: - Attachment: 2452-OutboundTCPConnection.patch 2452-Ec2Multi-Region.patch rebase to 2491, Snitch will automatically set the public IP by querying the AWS API Snitch will set the private IP as a Gossip application state. Snitch implements IESCS and will reset the connection if it is within the same region to communicate via private IP. Implements Ec2Snitch to inherit its functionality and extend it for Multi-Region. Operational: All the nodes in this cluster needs to be able to (modify the Security group settings in AWS) communicate via Public IP's both within the region and to the other regions. > New EC2 Snitch to use public ip and hence natively support for EC2 > mult-region's. > - > > Key: CASSANDRA-2452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2452 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 0.8 beta 1 > Environment: JVM >Reporter: Vijay >Assignee: Vijay >Priority: Minor > Fix For: 0.8.1 > > Attachments: 2452-EC2Snitch-Changes.txt, 2452-Ec2Multi-Region.patch, > 2452-Intro-EC2MultiRegionSnitch-V2.txt, 2452-OutboundTCPConnection.patch > > > Make cassandra talk identify itself using the public ip (To avoid any future > conflicts of private ips). > 1) Split the logic of identification vs listen Address in the code. > 2) Move the logic to assign IP address to the node into EndPointSnitch. > 3) Make EC2 Snitch query for its public ip and use it for identification. > 4) Make EC2 snitch to use InetAddress.getLocal to listen to the private ip. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2753) Capture the max client timestamp for an SSTable
Capture the max client timestamp for an SSTable --- Key: CASSANDRA-2753 URL: https://issues.apache.org/jira/browse/CASSANDRA-2753 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Alan Liang Assignee: Alan Liang Priority: Minor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1134030 - /cassandra/drivers/py/cqlsh
Author: jbellis
Date: Thu Jun 9 18:34:29 2011
New Revision: 1134030
URL: http://svn.apache.org/viewvc?rev=1134030&view=rev
Log:
trade ljust for rjust
Modified:
cassandra/drivers/py/cqlsh
Modified: cassandra/drivers/py/cqlsh
URL:
http://svn.apache.org/viewvc/cassandra/drivers/py/cqlsh?rev=1134030&r1=1134029&r2=1134030&view=diff
==
--- cassandra/drivers/py/cqlsh (original)
+++ cassandra/drivers/py/cqlsh Thu Jun 9 18:34:29 2011
@@ -186,7 +186,7 @@ class Shell(cmd.Cmd):
name = desc[0]
width = widths[name]
self.printout(" ", newline=False)
-self.printout(string.ljust(str(name), width), MAGENTA, False)
+self.printout(string.rjust(str(name), width), MAGENTA, False)
self.printout(" |", newline=False)
self.printout("")
@@ -196,7 +196,7 @@ class Shell(cmd.Cmd):
name = desc[0]
width = widths[desc[0]]
self.printout(" ", newline=False)
-self.printout(string.ljust(str(value), width), YELLOW, False)
+self.printout(string.rjust(str(value), width), YELLOW, False)
self.printout(" |", newline=False)
self.printout("")
svn commit: r1134028 - in /cassandra/drivers/py: cql/cursor.py cqlsh
Author: jbellis
Date: Thu Jun 9 18:32:43 2011
New Revision: 1134028
URL: http://svn.apache.org/viewvc?rev=1134028&view=rev
Log:
add print_static_result
patch by jbellis
Modified:
cassandra/drivers/py/cql/cursor.py
cassandra/drivers/py/cqlsh
Modified: cassandra/drivers/py/cql/cursor.py
URL:
http://svn.apache.org/viewvc/cassandra/drivers/py/cql/cursor.py?rev=1134028&r1=1134027&r2=1134028&view=diff
==
--- cassandra/drivers/py/cql/cursor.py (original)
+++ cassandra/drivers/py/cql/cursor.py Thu Jun 9 18:32:43 2011
@@ -31,6 +31,7 @@ from cql.cassandra.ttypes import (
SchemaDisagreementException)
_COUNT_DESCRIPTION = (None, None, None, None, None, None, None)
+_VOID_DESCRIPTION = (None)
class Cursor:
@@ -148,13 +149,19 @@ class Cursor:
self.rowcount = len(self.result)
if self.result:
self.description =
self.decoder.decode_description(self._query_ks, self._query_cf, self.result[0])
-
-if response.type == CqlResultType.INT:
+elif response.type == CqlResultType.INT:
self.result = [(response.num,)]
self.rs_idx = 0
self.rowcount = 1
# TODO: name could be the COUNT expression
self.description = _COUNT_DESCRIPTION
+elif response.type == CqlResultType.VOID:
+self.result = []
+self.rs_idx = 0
+self.rowcount = 0
+self.description = _VOID_DESCRIPTION
+else:
+raise Exception('unknown result type ' + response.type)
# 'Return values are not defined.'
return True
@@ -174,6 +181,9 @@ class Cursor:
def fetchone(self):
self.__checksock()
+if self.rs_idx == len(self.result):
+return None
+
row = self.result[self.rs_idx]
self.rs_idx += 1
if self.description != _COUNT_DESCRIPTION:
@@ -198,18 +208,22 @@ class Cursor:
return self.fetchmany(len(self.result) - self.rs_idx)
###
+# extra, for cqlsh
+###
+
+def _reset(self):
+self.rs_idx = 0
+
+###
# Iterator extension
###
def next(self):
-raise Warning("DB-API extension cursor.next() used")
-
if self.rs_idx >= len(self.result):
raise StopIteration
return self.fetchone()
def __iter__(self):
-raise Warning("DB-API extension cursor.__iter__() used")
return self
###
Modified: cassandra/drivers/py/cqlsh
URL:
http://svn.apache.org/viewvc/cassandra/drivers/py/cqlsh?rev=1134028&r1=1134027&r2=1134028&view=diff
==
--- cassandra/drivers/py/cqlsh (original)
+++ cassandra/drivers/py/cqlsh Thu Jun 9 18:32:43 2011
@@ -16,6 +16,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.
+from collections import defaultdict
from optparse import OptionParser
from StringIO import StringIO
@@ -24,6 +25,7 @@ import sys
import readline
import os
import re
+import string
import time
try:
@@ -31,7 +33,7 @@ try:
except ImportError:
sys.path.append(os.path.abspath(os.path.dirname(__file__)))
import cql
-from cql.cursor import _COUNT_DESCRIPTION
+from cql.cursor import _COUNT_DESCRIPTION, _VOID_DESCRIPTION
HISTORY = os.path.join(os.path.expanduser('~'), '.cqlsh')
CQLTYPES = ("bytes", "ascii", "utf8", "timeuuid", "uuid", "long", "int")
@@ -138,19 +140,76 @@ class Shell(cmd.Cmd):
self.printerr("Attempt #%d: %s" % (i, str(err)))
time.sleep(1*i)
-if self.cursor.description is _COUNT_DESCRIPTION:
-if self.cursor.result: print self.cursor.result[0]
+if self.cursor.description is _VOID_DESCRIPTION:
+return
+elif self.cursor.description is _COUNT_DESCRIPTION:
+self.print_count_result()
else:
-for x in range(self.cursor.rowcount):
-row = self.cursor.fetchone()
-self.printout(repr(row[0]), BLUE, False)
-for (i, value) in enumerate(row[1:]):
-name = self.cursor.description[i+1][0]
-self.printout(" | ", newline=False)
-self.printout(repr(name), MAGENTA, False)
-self.printout(",", newline=False)
-self.printout(repr(value), YELLOW, False)
-self.printout("")
+self.print_result()
+
+def print_count_result(self):
+if not self.cursor.result:
+return
+print 'count'
+print '-'
+print self.cursor.result[0]
+self.printout("")
+
+def print_result(self):
+# first pass: see if we have a static column set
+last_description = None
+for row in self.cursor:
+if last_description is not None and sel
svn commit: r1134017 - in /cassandra/branches/cassandra-0.8/examples/bmt: CassandraBulkLoader.java README.txt
Author: brandonwilliams Date: Thu Jun 9 17:53:32 2011 New Revision: 1134017 URL: http://svn.apache.org/viewvc?rev=1134017&view=rev Log: Remove BMT example Removed: cassandra/branches/cassandra-0.8/examples/bmt/CassandraBulkLoader.java cassandra/branches/cassandra-0.8/examples/bmt/README.txt
[jira] [Updated] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files
[
https://issues.apache.org/jira/browse/CASSANDRA-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patricio Echague updated CASSANDRA-2386:
Reviewer: jbellis
> sstable2json does not work on snapshot without moving the files
> ---
>
> Key: CASSANDRA-2386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2386
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Environment: Redhat Linux
>Reporter: Aslak Dirdal
>Assignee: Patricio Echague
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-trunk-2386.patch
>
>
> sstable2json
> ../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
> {
> Exception in thread "main" java.lang.NullPointerException: Unknown
> ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
> at
> org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
> at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
> at
> org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
> at
> org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
> at
> org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
> at
> org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
> sstable2json seem to think that the foldername "1301066898131-mysnapshot" is
> the Keyspace name.
> Moving the *.db files to a folder with the same name as the Keyspace is a
> workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files
[
https://issues.apache.org/jira/browse/CASSANDRA-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patricio Echague updated CASSANDRA-2386:
Attachment: CASSANDRA-trunk-2386.patch
> sstable2json does not work on snapshot without moving the files
> ---
>
> Key: CASSANDRA-2386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2386
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Environment: Redhat Linux
>Reporter: Aslak Dirdal
>Assignee: Patricio Echague
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-trunk-2386.patch
>
>
> sstable2json
> ../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
> {
> Exception in thread "main" java.lang.NullPointerException: Unknown
> ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
> at
> org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
> at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
> at
> org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
> at
> org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
> at
> org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
> at
> org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
> sstable2json seem to think that the foldername "1301066898131-mysnapshot" is
> the Keyspace name.
> Moving the *.db files to a folder with the same name as the Keyspace is a
> workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1133999 - /cassandra/drivers/py/cqlsh
Author: jbellis
Date: Thu Jun 9 16:57:39 2011
New Revision: 1133999
URL: http://svn.apache.org/viewvc?rev=1133999&view=rev
Log:
minor cleanup of printerr
Modified:
cassandra/drivers/py/cqlsh
Modified: cassandra/drivers/py/cqlsh
URL:
http://svn.apache.org/viewvc/cassandra/drivers/py/cqlsh?rev=1133999&r1=1133998&r2=1133999&view=diff
==
--- cassandra/drivers/py/cqlsh (original)
+++ cassandra/drivers/py/cqlsh Thu Jun 9 16:57:39 2011
@@ -135,7 +135,7 @@ class Shell(cmd.Cmd):
self.cursor.execute(statement)
break
except cql.IntegrityError, err:
-self.printerr("Attempt #%d: %s" % (i, str(err)), color=RED)
+self.printerr("Attempt #%d: %s" % (i, str(err)))
time.sleep(1*i)
if self.cursor.description is _COUNT_DESCRIPTION:
@@ -229,7 +229,7 @@ class Shell(cmd.Cmd):
if newline:
out.write("\n");
-def printerr(self, text, color=None, newline=True):
+def printerr(self, text, color=RED, newline=True):
self.printout(text, color, newline, sys.stderr)
if __name__ == '__main__':
@@ -260,17 +260,17 @@ if __name__ == '__main__':
color=options.color,
username=options.username,
password=options.password)
-while(True):
+while True:
try:
shell.cmdloop()
except SystemExit:
readline.write_history_file(HISTORY)
break
except cql.Error, cqlerr:
-shell.printerr(str(cqlerr), color=RED)
+shell.printerr(str(cqlerr))
except KeyboardInterrupt:
shell.reset_statement()
print
except Exception, err:
-shell.printerr("Exception: %s" % err, color=RED)
+shell.printerr("Exception: %s" % err)
[jira] [Updated] (CASSANDRA-2491) A new config parameter, broadcast_address
[ https://issues.apache.org/jira/browse/CASSANDRA-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2491: - Attachment: 2491_broadcast_address_v2.patch 1) Rebased 2) Attached patch has modification to IncomingTcpConnection (re factor) in order to support Gossiper.instance.setVersion as versions should be on broadcast IP and socket.getInetAddress will break. 3) Allow brodcastAddress to be set by snitch so we can automate via snitch (property or EC2MultiregionSnitch). > A new config parameter, broadcast_address > - > > Key: CASSANDRA-2491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2491 > Project: Cassandra > Issue Type: Improvement > Components: Core > Environment: x86_64 GNU/Linux >Reporter: Khee Chin >Assignee: Khee Chin >Priority: Trivial > Labels: patch > Fix For: 1.0 > > Attachments: 2491_broadcast_address.patch, > 2491_broadcast_address_v2.patch > > Original Estimate: 336h > Remaining Estimate: 336h > > A new config parameter, broadcast_address > In a cluster setup where one or more nodes is behind a firewall and has a > private ip address, listen_address does not allow the hosts behind the > firewalls to be discovered by other nodes. > Attached is a patch that introduces a new config parameter broadcast_address > which allows Cassandra nodes to explicitly specify their external ip address. > In addition, this allows listen_address to be set to 0.0.0.0 on the already > firewalled node. > broadcast_address fallsback to listen_address when it is not stated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2752) repair fails with java.io.EOFException
[ https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046628#comment-13046628 ] Terje Marthinussen commented on CASSANDRA-2752: --- Fresh 0.8 data. Just as a side test since the "compactionexecutor" is involved, we issued a full compaction of that CF and it completed without any error so the source SSTables seems good. I was trying to reproduce this locally on my desktop before leaving office to get it in a debugger. Quickly generated 10k random inserts into a CF with secondary index, but then I experienced that repair got stuck eating 100% on both nodes instead... I did not have time to figure out if it was due to some config issue or related to the same issue though. > repair fails with java.io.EOFException > -- > > Key: CASSANDRA-2752 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2752 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8.0 >Reporter: Terje Marthinussen > > Issuing repair on node 1 (1.10.42.81) in a cluster quickly fails with > INFO [AntiEntropyStage:1] 2011-06-09 19:02:47,999 AntiEntropyService.java > (line 234) Queueing comparison # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306fb46e, /1 > .10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]>> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 468) Endpoints somewhere/1.10.42.81 and /1.10.42.82 have 2 range(s) out > of sync for (JP,XXX) on (Token(bytes[6e]),Token(bytes[313039])] > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 485) Performing streaming repair of 2 ranges for # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306 > fb46e, /1.10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,030 StreamOut.java (line 173) > Stream context metadata [/data/cassandra/node0/data/JP/XXX-g-3-Data.db > sections=1 progress=0/36592 - 0%], 1 sstables. > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,031 StreamOutSession.java > (line 174) Streaming to /1.10.42.82 > ERROR [CompactionExecutor:9] 2011-06-09 19:02:48,970 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:9,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > On .82 > ERROR [CompactionExecutor:12] 2011-06-09 19:02:48,051 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:12,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > ERROR [Thread-132] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line > 113) Fatal exception in thread Thread[Thread-132,5,main] > java.lang.RuntimeException: java.util.concurrent.ExecutionException: > java.io.EOFException > at > org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:152) > at > org.apache.cassandra.strea
svn commit: r1133951 - in /cassandra/trunk: ./ contrib/ drivers/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/cql/ src/java/org/apache/cassandra/db/ src/java/or
Author: eevans
Date: Thu Jun 9 15:46:19 2011
New Revision: 1133951
URL: http://svn.apache.org/viewvc?rev=1133951&view=rev
Log:
merge w/ 0.8 branch
Added:
cassandra/trunk/test/unit/org/apache/cassandra/locator/EC2SnitchTest.java
- copied unchanged from r1133945,
cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/locator/EC2SnitchTest.java
Removed:
cassandra/trunk/drivers/
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/cql/Cql.g
cassandra/trunk/src/java/org/apache/cassandra/db/Table.java
cassandra/trunk/src/java/org/apache/cassandra/locator/Ec2Snitch.java
cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java
cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java
cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamIn.java
cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamOut.java
cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamRequestMessage.java
cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamRequestVerbHandler.java
cassandra/trunk/test/system/test_cql.py
cassandra/trunk/test/unit/org/apache/cassandra/streaming/SerializationsTest.java
cassandra/trunk/test/unit/org/apache/cassandra/streaming/StreamingTransferTest.java
Propchange: cassandra/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Jun 9 15:46:19 2011
@@ -1,7 +1,7 @@
/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291
-/cassandra/branches/cassandra-0.7:1026516-1131292
+/cassandra/branches/cassandra-0.7:1026516-1133391
/cassandra/branches/cassandra-0.7.0:1053690-1055654
-/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1132428
+/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1133945
/cassandra/branches/cassandra-0.8.0:1125021-1130369
/cassandra/branches/cassandra-0.8.1:1101014-1125018
/cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689
Modified: cassandra/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1133951&r1=1133950&r2=1133951&view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Thu Jun 9 15:46:19 2011
@@ -6,7 +6,7 @@
- TTL support (CASSANDRA-2476)
- counter support (CASSANDRA-2473)
- improve JDBC spec compliance (CASSANDRA-2720)
- - ALTER TABLE (CASSANDRA-1709)
+ - ALTER COLUMNFAMILY (CASSANDRA-1709)
- DROP INDEX (CASSANDRA-2617)
* add support for comparator parameters and a generic ReverseType
(CASSANDRA-2355)
@@ -36,9 +36,15 @@
* close scrub file handles (CASSANDRA-2669)
* throttle migration replay (CASSANDRA-2714)
* optimize column serializer creation (CASSANDRA-2716)
+ * Added support for making bootstrap retry if nodes flap (CASSANDRA-2644)
+ * Added statusthrift to nodetool to report if thrift server is running
+ (CASSANDRA-2722)
+ * Fixed rows being cached if they do not exist (CASSANDRA-2723)
* fix truncate/compaction race (CASSANDRA-2673)
* workaround large resultsets causing large allocation retention
by nio sockets (CASSANDRA-2654)
+ * restrict repair streaming to specific columnfamilies (CASSANDRA-2280)
+ * fix nodetool ring use with Ec2Snitch (CASSANDRA-2733)
0.8.0-final
Modified: cassandra/trunk/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/trunk/build.xml?rev=1133951&r1=1133950&r2=1133951&view=diff
==
--- cassandra/trunk/build.xml (original)
+++ cassandra/trunk/build.xml Thu Jun 9 15:46:19 2011
@@ -36,7 +36,6 @@
-
@@ -46,7 +45,6 @@
-
@@ -60,11 +58,9 @@
-
-
@@ -161,7 +157,6 @@
message="Not a source artifact, stopping here." />
-
@@ -399,7 +394,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
svn commit: r1133939 - in /cassandra: branches/cassandra-0.8/drivers/txpy/ drivers/txpy/
Author: eevans Date: Thu Jun 9 15:34:02 2011 New Revision: 1133939 URL: http://svn.apache.org/viewvc?rev=1133939&view=rev Log: relocate txpy driver Added: cassandra/drivers/txpy/ - copied from r1133924, cassandra/branches/cassandra-0.8/drivers/txpy/ Removed: cassandra/branches/cassandra-0.8/drivers/txpy/
svn commit: r1133938 - /cassandra/branches/cassandra-0.8/build.xml
Author: eevans
Date: Thu Jun 9 15:33:09 2011
New Revision: 1133938
URL: http://svn.apache.org/viewvc?rev=1133938&view=rev
Log:
remove txpy target for driver move
Modified:
cassandra/branches/cassandra-0.8/build.xml
Modified: cassandra/branches/cassandra-0.8/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/build.xml?rev=1133938&r1=1133937&r2=1133938&view=diff
==
--- cassandra/branches/cassandra-0.8/build.xml (original)
+++ cassandra/branches/cassandra-0.8/build.xml Thu Jun 9 15:33:09 2011
@@ -785,7 +785,7 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
@@ -1214,17 +1214,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
-Creating Twisted CQL driver artifact...
-
-
-
-
-
-
-
-
svn commit: r1133923 - in /cassandra: branches/cassandra-0.8/drivers/py/ drivers/py/
Author: eevans Date: Thu Jun 9 15:19:27 2011 New Revision: 1133923 URL: http://svn.apache.org/viewvc?rev=1133923&view=rev Log: relocate python driver Added: cassandra/drivers/py/ - copied from r1133915, cassandra/branches/cassandra-0.8/drivers/py/ Removed: cassandra/branches/cassandra-0.8/drivers/py/
[jira] [Commented] (CASSANDRA-2752) repair fails with java.io.EOFException
[ https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046606#comment-13046606 ] Jonathan Ellis commented on CASSANDRA-2752: --- Is this data from 0.7 that got upgraded? > repair fails with java.io.EOFException > -- > > Key: CASSANDRA-2752 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2752 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8.0 >Reporter: Terje Marthinussen > > Issuing repair on node 1 (1.10.42.81) in a cluster quickly fails with > INFO [AntiEntropyStage:1] 2011-06-09 19:02:47,999 AntiEntropyService.java > (line 234) Queueing comparison # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306fb46e, /1 > .10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]>> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 468) Endpoints somewhere/1.10.42.81 and /1.10.42.82 have 2 range(s) out > of sync for (JP,XXX) on (Token(bytes[6e]),Token(bytes[313039])] > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 485) Performing streaming repair of 2 ranges for # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306 > fb46e, /1.10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,030 StreamOut.java (line 173) > Stream context metadata [/data/cassandra/node0/data/JP/XXX-g-3-Data.db > sections=1 progress=0/36592 - 0%], 1 sstables. > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,031 StreamOutSession.java > (line 174) Streaming to /1.10.42.82 > ERROR [CompactionExecutor:9] 2011-06-09 19:02:48,970 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:9,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > On .82 > ERROR [CompactionExecutor:12] 2011-06-09 19:02:48,051 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:12,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > ERROR [Thread-132] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line > 113) Fatal exception in thread Thread[Thread-132,5,main] > java.lang.RuntimeException: java.util.concurrent.ExecutionException: > java.io.EOFException > at > org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:152) > at > org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63) > at > org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) > Caused by: java.util.concurrent.ExecutionException: java.io.EOFException > at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) > at java.util.concurrent.FutureTask.get(FutureTask.java:83) > at > org.apache.cassandra.st
svn commit: r1133918 - /cassandra/branches/cassandra-0.8/build.xml
Author: eevans
Date: Thu Jun 9 15:15:13 2011
New Revision: 1133918
URL: http://svn.apache.org/viewvc?rev=1133918&view=rev
Log:
remove py-cql target for driver move
Modified:
cassandra/branches/cassandra-0.8/build.xml
Modified: cassandra/branches/cassandra-0.8/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/build.xml?rev=1133918&r1=1133917&r2=1133918&view=diff
==
--- cassandra/branches/cassandra-0.8/build.xml (original)
+++ cassandra/branches/cassandra-0.8/build.xml Thu Jun 9 15:15:13 2011
@@ -785,7 +785,7 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
@@ -1214,17 +1214,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
-Creating Python CQL driver artifact...
-
-
-
-
-
-
-
-
Creating Twisted CQL driver artifact...
[jira] [Commented] (CASSANDRA-2752) repair fails with java.io.EOFException
[ https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046586#comment-13046586 ] Terje Marthinussen commented on CASSANDRA-2752: --- Seems confirmed, only able to reproduce this on a CF with secondary indexes. > repair fails with java.io.EOFException > -- > > Key: CASSANDRA-2752 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2752 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8.0 >Reporter: Terje Marthinussen > > Issuing repair on node 1 (1.10.42.81) in a cluster quickly fails with > INFO [AntiEntropyStage:1] 2011-06-09 19:02:47,999 AntiEntropyService.java > (line 234) Queueing comparison # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306fb46e, /1 > .10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]>> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 468) Endpoints somewhere/1.10.42.81 and /1.10.42.82 have 2 range(s) out > of sync for (JP,XXX) on (Token(bytes[6e]),Token(bytes[313039])] > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 485) Performing streaming repair of 2 ranges for # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306 > fb46e, /1.10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,030 StreamOut.java (line 173) > Stream context metadata [/data/cassandra/node0/data/JP/XXX-g-3-Data.db > sections=1 progress=0/36592 - 0%], 1 sstables. > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,031 StreamOutSession.java > (line 174) Streaming to /1.10.42.82 > ERROR [CompactionExecutor:9] 2011-06-09 19:02:48,970 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:9,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > On .82 > ERROR [CompactionExecutor:12] 2011-06-09 19:02:48,051 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:12,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > ERROR [Thread-132] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line > 113) Fatal exception in thread Thread[Thread-132,5,main] > java.lang.RuntimeException: java.util.concurrent.ExecutionException: > java.io.EOFException > at > org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:152) > at > org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63) > at > org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) > Caused by: java.util.concurrent.ExecutionException: java.io.EOFException > at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) > at java.util.concurrent.FutureTask.get(FutureTask.java
svn commit: r1133889 - /cassandra/branches/cassandra-0.8/build.xml
Author: eevans
Date: Thu Jun 9 14:29:31 2011
New Revision: 1133889
URL: http://svn.apache.org/viewvc?rev=1133889&view=rev
Log:
don't try to run tests that are no longer there
Modified:
cassandra/branches/cassandra-0.8/build.xml
Modified: cassandra/branches/cassandra-0.8/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/build.xml?rev=1133889&r1=1133888&r2=1133889&view=diff
==
--- cassandra/branches/cassandra-0.8/build.xml (original)
+++ cassandra/branches/cassandra-0.8/build.xml Thu Jun 9 14:29:31 2011
@@ -58,7 +58,6 @@
-
@@ -914,7 +913,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
@@ -991,9 +989,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
-
-
[jira] [Updated] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
[
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
donal zang updated CASSANDRA-2231:
--
Comment: was deleted
(was: No, there's no bytes remaining after 0x01.
The exception is raised in the validate(ByteBuffer bytes) function:
215 byte b = bb.get();
216 if (b != 0 && bb.remaining() != 0)
217 throw new MarshalException("Invalid bytes remaining after
an end-of-component at component" +i);
that means if the byte is not 0x00, then this Exception will be raised?
correct me if I am wrong)
> Add CompositeType comparer to the comparers provided in
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
> Issue Type: New Feature
> Components: Contrib
>Reporter: Ed Anuff
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments:
> 0001-Add-compositeType-and-DynamicCompositeType-v2.patch,
> 0001-Add-compositeType-and-DynamicCompositeType-v3.patch,
> 0001-Add-compositeType-and-DynamicCompositeType-v4.patch,
> 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch,
> CompositeType-and-DynamicCompositeType.patch,
> edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create
> comparable composite values out of the basic types that Cassandra currently
> supports, such as Long, UUID, etc. This is very useful in both the creation
> of custom inverted indexes using columns in a skinny row, where each column
> name is a composite value, and also when using Cassandra's built-in secondary
> index support, where it can be used to encode the values in the columns that
> Cassandra indexes. One scenario for the usage of these is documented here:
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html. Source for
> contribution is attached and has been previously maintained on github here:
> https://github.com/edanuff/CassandraCompositeType
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
[
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046562#comment-13046562
]
donal zang commented on CASSANDRA-2231:
---
No, there's no bytes remaining after 0x01.
The exception is raised in the validate(ByteBuffer bytes) function:
215 byte b = bb.get();
216 if (b != 0 && bb.remaining() != 0)
217 throw new MarshalException("Invalid bytes remaining after
an end-of-component at component" +i);
that means if the byte is not 0x00, then this Exception will be raised?
correct me if I am wrong
> Add CompositeType comparer to the comparers provided in
> org.apache.cassandra.db.marshal
> ---
>
> Key: CASSANDRA-2231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
> Project: Cassandra
> Issue Type: New Feature
> Components: Contrib
>Reporter: Ed Anuff
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 0.8.1
>
> Attachments:
> 0001-Add-compositeType-and-DynamicCompositeType-v2.patch,
> 0001-Add-compositeType-and-DynamicCompositeType-v3.patch,
> 0001-Add-compositeType-and-DynamicCompositeType-v4.patch,
> 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch,
> CompositeType-and-DynamicCompositeType.patch,
> edanuff-CassandraCompositeType-1e253c4.zip
>
>
> CompositeType is a custom comparer that makes it possible to create
> comparable composite values out of the basic types that Cassandra currently
> supports, such as Long, UUID, etc. This is very useful in both the creation
> of custom inverted indexes using columns in a skinny row, where each column
> name is a composite value, and also when using Cassandra's built-in secondary
> index support, where it can be used to encode the values in the columns that
> Cassandra indexes. One scenario for the usage of these is documented here:
> http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html. Source for
> contribution is attached and has been previously maintained on github here:
> https://github.com/edanuff/CassandraCompositeType
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2590) row delete breaks read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046554#comment-13046554 ] Hudson commented on CASSANDRA-2590: --- Integrated in Cassandra-0.7 #504 (See [https://builds.apache.org/job/Cassandra-0.7/504/]) fix removing columns and subcolumns that are supressed by a row orsupercolumn tombstone during replica resolution patch by Aaron Morton and jbellis; reviewed by slebresne for CASSANDRA-2590 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1133873 Files : * /cassandra/branches/cassandra-0.7/CHANGES.txt * /cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/RowResolverTest.java * /cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/Util.java * /cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/TableTest.java * /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java > row delete breaks read repair > -- > > Key: CASSANDRA-2590 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2590 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Aaron Morton >Assignee: Aaron Morton >Priority: Minor > Fix For: 0.7.7, 0.8.1 > > Attachments: 0001-2590-v3.patch, > 0001-cf-resolve-test-and-possible-solution-for-read-repai.patch, 2590-v2.txt, > 2590-v4-0.7.txt > > > related to CASSANDRA-2589 > Working at CL ALL can get inconsistent reads after row deletion. Reproduced > on the 0.7 and 0.8 source. > Steps to reproduce: > # two node cluster with rf 2 and HH turned off > # insert rows via cli > # flush both nodes > # shutdown node 1 > # connect to node 2 via cli and delete one row > # bring up node 1 > # connect to node 1 via cli and issue get with CL ALL > # first get returns the deleted row, second get returns zero rows. > RowRepairResolver.resolveSuperSet() resolves a local CF with the old row > columns, and the remote CF which is marked for deletion. CF.resolve() does > not pay attention to the deletion flags and the resolved CF has both > markedForDeletion set and a column with a lower timestamp. The return from > resolveSuperSet() is used as the return for the read without checking if the > cols are relevant. > Also when RowRepairResolver.mabeScheduleRepairs() runs it sends two > mutations. Node 1 is given the row level deletation, and Node 2 is given a > mutation to write the old (and now deleted) column from node 2. I have some > log traces for this if needed. > A quick fix is to check for relevant columns in the RowRepairResolver, will > attach shortly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2433) Failed Streams Break Repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2433: Attachment: 0004-Reports-validation-compaction-errors-back-to-repair-v3.patch 0003-Report-streaming-errors-back-to-repair-v3.patch 0002-Register-in-gossip-to-handle-node-failures-v3.patch 0001-Put-repair-session-on-a-Stage-and-add-a-method-to-re-v3.patch Attaching v3 rebased (on 0.8). bq. Since we're not trying to control throughput or monitor sessions, could we just use Stage.MISC? The thing is that repair session are very long lived. And MISC is single threaded. So that would block other task that are not supposed to block. We could make MISC multi-threaded but even then it's not a good idea to mix short lived and long lived task on the same stage. bq. I think RepairSession.exception needs to be volatile to ensure that the awoken thread sees it Done in v3. bq. Would it be better if RepairSession implemented IEndpointStateChangeSubscriber directly? Good idea, it's slightly simpler, done in v3. bq. The endpoint set needs to be threadsafe, since it will be modified by the endpoint state change thread, and the AE_STAGE thread Done in v3. That will probably change with CASSANDRA-2610 anyway (which I have to update) bq. Should StreamInSession.retries be volatile/atomic? (likely they won't retry quickly enough for it to be a problem, but...) I did not change that, but if it's a problem for retries to not be volatile, I suspect having StreamInSession.current not volatile is also a problem. But really I'd be curious to see that be a problem. bq. Playing devil's advocate: would sending a half-built tree in case of failure still be useful? I don't think it is. Or more precisely, if you do send half-built tree, you'll have to be careful that the other doesn't consider what's missing as ranges not being in sync (I don't think people will be happy with tons of data being stream just because we happen to have a bug that make compaction throw an exception during the validation). So I think you cannot do much with a half-built tree, and it will add complication. For a case where people will need to restart a repair anyway once whatever happened is fixed bq. success might need to be volatile as well Done in v3. > Failed Streams Break Repair > --- > > Key: CASSANDRA-2433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2433 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benjamin Coverston >Assignee: Sylvain Lebresne > Labels: repair > Fix For: 0.8.1 > > Attachments: > 0001-Put-repair-session-on-a-Stage-and-add-a-method-to-re-v2.patch, > 0001-Put-repair-session-on-a-Stage-and-add-a-method-to-re-v3.patch, > 0001-Put-repair-session-on-a-Stage-and-add-a-method-to-re.patch, > 0002-Register-in-gossip-to-handle-node-failures-v2.patch, > 0002-Register-in-gossip-to-handle-node-failures-v3.patch, > 0002-Register-in-gossip-to-handle-node-failures.patch, > 0003-Report-streaming-errors-back-to-repair-v2.patch, > 0003-Report-streaming-errors-back-to-repair-v3.patch, > 0003-Report-streaming-errors-back-to-repair.patch, > 0004-Reports-validation-compaction-errors-back-to-repair-v2.patch, > 0004-Reports-validation-compaction-errors-back-to-repair-v3.patch, > 0004-Reports-validation-compaction-errors-back-to-repair.patch > > > Running repair in cases where a stream fails we are seeing multiple problems. > 1. Although retry is initiated and completes, the old stream doesn't seem to > clean itself up and repair hangs. > 2. The temp files are left behind and multiple failures can end up filling up > the data partition. > These issues together are making repair very difficult for nearly everyone > running repair on a non-trivial sized data set. > This issue is also being worked on w.r.t CASSANDRA-2088, however that was > moved to 0.8 for a few reasons. This ticket is to fix the immediate issues > that we are seeing in 0.7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1133873 - in /cassandra/branches/cassandra-0.7: ./ src/java/org/apache/cassandra/service/ test/unit/org/apache/cassandra/ test/unit/org/apache/cassandra/db/ test/unit/org/apache/cassandra
Author: jbellis
Date: Thu Jun 9 13:50:27 2011
New Revision: 1133873
URL: http://svn.apache.org/viewvc?rev=1133873&view=rev
Log:
fix removing columns and subcolumns that are supressed by a row orsupercolumn
tombstone during replica resolution
patch by Aaron Morton and jbellis; reviewed by slebresne for CASSANDRA-2590
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/Util.java
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/TableTest.java
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/RowResolverTest.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1133873&r1=1133872&r2=1133873&view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Jun 9 13:50:27 2011
@@ -16,6 +16,8 @@
* workaround large resultsets causing large allocation retention
by nio sockets (CASSANDRA-2654)
* fix nodetool ring use with Ec2Snitch (CASSANDRA-2733)
+ * fix removing columns and subcolumns that are supressed by a row or
+ supercolumn tombstone during replica resolution (CASSANDRA-2590)
0.7.6
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java?rev=1133873&r1=1133872&r2=1133873&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
Thu Jun 9 13:50:27 2011
@@ -22,13 +22,17 @@ import java.io.IOError;
import java.io.IOException;
import java.net.InetAddress;
import java.nio.ByteBuffer;
-import java.util.ArrayList;
-import java.util.List;
-import java.util.Map;
+import java.util.*;
+
+import org.apache.commons.collections.iterators.CollatingIterator;
import org.apache.cassandra.db.*;
+import org.apache.cassandra.db.columniterator.IdentityQueryFilter;
+import org.apache.cassandra.db.filter.QueryFilter;
+import org.apache.cassandra.db.filter.QueryPath;
import org.apache.cassandra.net.Message;
import org.apache.cassandra.net.MessagingService;
+import org.apache.cassandra.utils.FBUtilities;
public class RowRepairResolver extends AbstractRowResolver
{
@@ -121,19 +125,30 @@ public class RowRepairResolver extends A
ColumnFamily resolved = null;
for (ColumnFamily cf : versions)
{
-if (cf != null)
-{
-resolved = cf.cloneMe();
-break;
-}
+if (cf == null)
+continue;
+
+if (resolved == null)
+resolved = cf.cloneMeShallow();
+else
+resolved.delete(cf);
}
if (resolved == null)
return null;
-for (ColumnFamily cf : versions)
-resolved.resolve(cf);
-
-return resolved;
+// mimic the collectCollatedColumn + removeDeleted path that
getColumnFamily takes.
+// this will handle removing columns and subcolumns that are supressed
by a row or
+// supercolumn tombstone.
+QueryFilter filter = new QueryFilter(null, new
QueryPath(resolved.metadata().cfName), new IdentityQueryFilter());
+CollatingIterator iter = new
CollatingIterator(resolved.metadata().comparator.columnComparator);
+for (ColumnFamily version : versions)
+{
+if (version == null)
+continue;
+iter.addIterator(version.getColumnsMap().values().iterator());
+}
+filter.collectCollatedColumns(resolved, iter, Integer.MIN_VALUE);
+return ColumnFamilyStore.removeDeleted(resolved, Integer.MIN_VALUE);
}
public Row getData() throws IOException
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/Util.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/Util.java?rev=1133873&r1=1133872&r2=1133873&view=diff
==
--- cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/Util.java
(original)
+++ cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/Util.java
Thu Jun 9 13:50:27 2011
@@ -51,6 +51,14 @@ public class Util
return new Column(ByteBufferUtil.bytes(name),
ByteBufferUtil.bytes(value), timestamp);
}
+public static SuperColumn superColumn(ColumnFami
svn commit: r1133852 - in /cassandra: branches/cassandra-0.8/drivers/java/ drivers/ drivers/java/
Author: eevans Date: Thu Jun 9 13:02:40 2011 New Revision: 1133852 URL: http://svn.apache.org/viewvc?rev=1133852&view=rev Log: move jdbc driver out to drivers/ tree Added: cassandra/drivers/ cassandra/drivers/java/ - copied from r1133798, cassandra/branches/cassandra-0.8/drivers/java/ Removed: cassandra/branches/cassandra-0.8/drivers/java/
svn commit: r1133845 - /cassandra/branches/cassandra-0.8/build.xml
Author: eevans
Date: Thu Jun 9 12:56:14 2011
New Revision: 1133845
URL: http://svn.apache.org/viewvc?rev=1133845&view=rev
Log:
remove jdbc driver build and tests in preparation for moves
Modified:
cassandra/branches/cassandra-0.8/build.xml
Modified: cassandra/branches/cassandra-0.8/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/build.xml?rev=1133845&r1=1133844&r2=1133845&view=diff
==
--- cassandra/branches/cassandra-0.8/build.xml (original)
+++ cassandra/branches/cassandra-0.8/build.xml Thu Jun 9 12:56:14 2011
@@ -36,7 +36,6 @@
-
@@ -46,7 +45,6 @@
-
@@ -64,7 +62,6 @@
-
@@ -161,7 +158,6 @@
message="Not a source artifact, stopping here." />
-
@@ -399,7 +395,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
@@ -509,22 +504,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
- http://cassandra.apache.org";
-name="Apache Cassandra">
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@@ -757,20 +731,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
-
-
-
-
-
-
-
-
-
-
@@ -834,14 +782,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
-
-
-
-
-
-
-
@@ -936,14 +876,12 @@ url=${svn.entry.url}?pathrev=${svn.entry
algorithm="MD5">
-
-
@@ -973,7 +911,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
destdir="${test.classes}">
-
@@ -1026,7 +963,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
@@ -1347,16 +1283,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
-
-
-
-
-
-
-
-
-
-
[jira] [Commented] (CASSANDRA-2752) repair fails with java.io.EOFException
[ https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046509#comment-13046509 ] Terje Marthinussen commented on CASSANDRA-2752: --- Need to test a bit more, but quite likely this is related to repair on CFs with secondary indexes. > repair fails with java.io.EOFException > -- > > Key: CASSANDRA-2752 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2752 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8.0 >Reporter: Terje Marthinussen > > Issuing repair on node 1 (1.10.42.81) in a cluster quickly fails with > INFO [AntiEntropyStage:1] 2011-06-09 19:02:47,999 AntiEntropyService.java > (line 234) Queueing comparison # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306fb46e, /1 > .10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]>> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 468) Endpoints somewhere/1.10.42.81 and /1.10.42.82 have 2 range(s) out > of sync for (JP,XXX) on (Token(bytes[6e]),Token(bytes[313039])] > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java > (line 485) Performing streaming repair of 2 ranges for # manual-repair-0c17c5f9-583f-4a31-a6d4-a9e7306 > fb46e, /1.10.42.82, (JP,XXX), (Token(bytes[6e]),Token(bytes[313039])]> > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,030 StreamOut.java (line 173) > Stream context metadata [/data/cassandra/node0/data/JP/XXX-g-3-Data.db > sections=1 progress=0/36592 - 0%], 1 sstables. > INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,031 StreamOutSession.java > (line 174) Streaming to /1.10.42.82 > ERROR [CompactionExecutor:9] 2011-06-09 19:02:48,970 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:9,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > On .82 > ERROR [CompactionExecutor:12] 2011-06-09 19:02:48,051 > AbstractCassandraDaemon.java (line 113) Fatal exception in thread > Thread[CompactionExecutor:12,1,main] > java.io.EOFException > at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) > at > org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) > at > org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) > at > org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > ERROR [Thread-132] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line > 113) Fatal exception in thread Thread[Thread-132,5,main] > java.lang.RuntimeException: java.util.concurrent.ExecutionException: > java.io.EOFException > at > org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:152) > at > org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63) > at > org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) > Caused by: java.util.concurrent.ExecutionException: java.io.EOFException > at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) > at java.util.concurrent.FutureT
[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
[ https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046500#comment-13046500 ] Sylvain Lebresne commented on CASSANDRA-2231: - The comment still applies to DynamicCompositeType, but what the comment doesn't says is that if you use a 0x01 as the end-of-component, it expects you have no remaining component. The error message tells that apparently there is some bytes remaining after that 0x01. You can look the discussion above on that ticket for why that doesn't make sense to have anything after a 0x01. > Add CompositeType comparer to the comparers provided in > org.apache.cassandra.db.marshal > --- > > Key: CASSANDRA-2231 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2231 > Project: Cassandra > Issue Type: New Feature > Components: Contrib >Reporter: Ed Anuff >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 0.8.1 > > Attachments: > 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, > 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, > 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, > 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, > CompositeType-and-DynamicCompositeType.patch, > edanuff-CassandraCompositeType-1e253c4.zip > > > CompositeType is a custom comparer that makes it possible to create > comparable composite values out of the basic types that Cassandra currently > supports, such as Long, UUID, etc. This is very useful in both the creation > of custom inverted indexes using columns in a skinny row, where each column > name is a composite value, and also when using Cassandra's built-in secondary > index support, where it can be used to encode the values in the columns that > Cassandra indexes. One scenario for the usage of these is documented here: > http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html. Source for > contribution is attached and has been previously maintained on github here: > https://github.com/edanuff/CassandraCompositeType -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
[ https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046485#comment-13046485 ] donal zang commented on CASSANDRA-2231: --- In CompositeType.java I find this: 37 * 'end-of-component' byte should always be 0 for actual column name. 38 * However, it can set to 1 for query bounds. This allows to query for the 39 * equivalent of 'give me the full super-column'. That is, if during a slice 40 * query uses: 41 * start = <3><"foo".getBytes()><0> 42 * end = <3><"foo".getBytes()><1> 43 * then he will be sure to get *all* the columns whose first component is "foo". Is this also apply to DynamicCompositeType ? When I use it in a query end with '0x01', there's an Exception "Invalid bytes remaining after an end-of-component at component0" > Add CompositeType comparer to the comparers provided in > org.apache.cassandra.db.marshal > --- > > Key: CASSANDRA-2231 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2231 > Project: Cassandra > Issue Type: New Feature > Components: Contrib >Reporter: Ed Anuff >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 0.8.1 > > Attachments: > 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, > 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, > 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, > 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, > CompositeType-and-DynamicCompositeType.patch, > edanuff-CassandraCompositeType-1e253c4.zip > > > CompositeType is a custom comparer that makes it possible to create > comparable composite values out of the basic types that Cassandra currently > supports, such as Long, UUID, etc. This is very useful in both the creation > of custom inverted indexes using columns in a skinny row, where each column > name is a composite value, and also when using Cassandra's built-in secondary > index support, where it can be used to encode the values in the columns that > Cassandra indexes. One scenario for the usage of these is documented here: > http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html. Source for > contribution is attached and has been previously maintained on github here: > https://github.com/edanuff/CassandraCompositeType -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046477#comment-13046477 ] Sylvain Lebresne commented on CASSANDRA-1034: - bq. One way to remove toSplitValue would be to use DecoratedKey everywhere; I'm not saying it's not possible, but I think this is overkill (in the changes it involves). Moreover, all the code that deals with topology really only care about token. That's the right abstraction for those part of the code. So I really (really) doubt using decorated key everywhere would be cleaner. Of course, anyone is free to actually do the experiment and prove me wrong. I also don't think it would remove the need for splitValue, it would just maybe call it differently. bq. The equivalent of today's Token is a DecoratedKey for that token with a null key This is only true today because we assume key and token are one-to-one. The goal is to change that. If multiple keys can have the same token (by definition the token is really the hash of a key), then the statement above is false. If a token correspond to an infinite set of key (with is the case with md5 btw, we just ignore it), then replacing a token by given key *cannot* work. Overall, it could be that there is better way to do this, but having spend some time on this, I have a reasonable confidence on that it fixes the issue at hand without being too disruptive (which is not saying there isn't a few points here and there that couldn't be improved). > Remove assumption that Key to Token is one-to-one > - > > Key: CASSANDRA-1034 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 > Project: Cassandra > Issue Type: Bug >Reporter: Stu Hood >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.0 > > Attachments: > 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, > 0002-LengthPartitioner.patch, 1034-1-Generify-AbstractBounds-v3.patch, > 1034-2-Remove-assumption-that-token-and-keys-are-one-to-one-v3.patch, > 1034_v1.txt > > > get_range_slices assumes that Tokens do not collide and converts a KeyRange > to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and > would lead to a very weird heisenberg. > Converting AbstractBounds to use a DecoratedKey would solve this, because the > byte[] key portion of the DecoratedKey can act as a tiebreaker. > Alternatively, we could make DecoratedKey extend Token, and then use > DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2752) repair fails with java.io.EOFException
repair fails with java.io.EOFException -- Key: CASSANDRA-2752 URL: https://issues.apache.org/jira/browse/CASSANDRA-2752 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Terje Marthinussen Issuing repair on node 1 (1.10.42.81) in a cluster quickly fails with INFO [AntiEntropyStage:1] 2011-06-09 19:02:47,999 AntiEntropyService.java (line 234) Queueing comparison #> INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java (line 468) Endpoints somewhere/1.10.42.81 and /1.10.42.82 have 2 range(s) out of sync for (JP,XXX) on (Token(bytes[6e]),Token(bytes[313039])] INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,026 AntiEntropyService.java (line 485) Performing streaming repair of 2 ranges for # INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,030 StreamOut.java (line 173) Stream context metadata [/data/cassandra/node0/data/JP/XXX-g-3-Data.db sections=1 progress=0/36592 - 0%], 1 sstables. INFO [AntiEntropyStage:1] 2011-06-09 19:02:48,031 StreamOutSession.java (line 174) Streaming to /1.10.42.82 ERROR [CompactionExecutor:9] 2011-06-09 19:02:48,970 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[CompactionExecutor:9,1,main] java.io.EOFException at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) On .82 ERROR [CompactionExecutor:12] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[CompactionExecutor:12,1,main] java.io.EOFException at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ERROR [Thread-132] 2011-06-09 19:02:48,051 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[Thread-132,5,main] java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.io.EOFException at org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:152) at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) Caused by: java.util.concurrent.ExecutionException: java.io.EOFException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:136) ... 3 more Caused by: java.io.EOFException at java.io.RandomAccessFile.readInt(RandomAccessFile.java:725) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.doIndexing(SSTableWriter.java:457) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:364) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1099) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:1090) at java.util.concurrent.FutureTas
[jira] [Updated] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-1034: Attachment: 1034-2-Remove-assumption-that-token-and-keys-are-one-to-one-v3.patch 1034-1-Generify-AbstractBounds-v3.patch Patch rebased, this is against trunk. > Remove assumption that Key to Token is one-to-one > - > > Key: CASSANDRA-1034 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 > Project: Cassandra > Issue Type: Bug >Reporter: Stu Hood >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.0 > > Attachments: > 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, > 0002-LengthPartitioner.patch, 1034-1-Generify-AbstractBounds-v3.patch, > 1034-2-Remove-assumption-that-token-and-keys-are-one-to-one-v3.patch, > 1034_v1.txt > > > get_range_slices assumes that Tokens do not collide and converts a KeyRange > to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and > would lead to a very weird heisenberg. > Converting AbstractBounds to use a DecoratedKey would solve this, because the > byte[] key portion of the DecoratedKey can act as a tiebreaker. > Alternatively, we could make DecoratedKey extend Token, and then use > DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-1034: Attachment: (was: 0002-Remove-assumption-that-token-and-keys-are-one-to-one.patch) > Remove assumption that Key to Token is one-to-one > - > > Key: CASSANDRA-1034 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 > Project: Cassandra > Issue Type: Bug >Reporter: Stu Hood >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.0 > > Attachments: > 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, > 0002-LengthPartitioner.patch, 1034_v1.txt > > > get_range_slices assumes that Tokens do not collide and converts a KeyRange > to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and > would lead to a very weird heisenberg. > Converting AbstractBounds to use a DecoratedKey would solve this, because the > byte[] key portion of the DecoratedKey can act as a tiebreaker. > Alternatively, we could make DecoratedKey extend Token, and then use > DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-1034: Attachment: (was: 0001-Generify-AbstractBounds.patch) > Remove assumption that Key to Token is one-to-one > - > > Key: CASSANDRA-1034 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 > Project: Cassandra > Issue Type: Bug >Reporter: Stu Hood >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.0 > > Attachments: > 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, > 0002-LengthPartitioner.patch, 1034_v1.txt > > > get_range_slices assumes that Tokens do not collide and converts a KeyRange > to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and > would lead to a very weird heisenberg. > Converting AbstractBounds to use a DecoratedKey would solve this, because the > byte[] key portion of the DecoratedKey can act as a tiebreaker. > Alternatively, we could make DecoratedKey extend Token, and then use > DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-1034: Attachment: (was: 0002-Remove-assumption-that-token-and-keys-are-one-to-one-v2.patch) > Remove assumption that Key to Token is one-to-one > - > > Key: CASSANDRA-1034 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 > Project: Cassandra > Issue Type: Bug >Reporter: Stu Hood >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.0 > > Attachments: > 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, > 0002-LengthPartitioner.patch, 1034_v1.txt > > > get_range_slices assumes that Tokens do not collide and converts a KeyRange > to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and > would lead to a very weird heisenberg. > Converting AbstractBounds to use a DecoratedKey would solve this, because the > byte[] key portion of the DecoratedKey can act as a tiebreaker. > Alternatively, we could make DecoratedKey extend Token, and then use > DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046450#comment-13046450 ] Mck SembWever commented on CASSANDRA-2388: -- I have tested this now on data w/ RF=2. Seems to work ~ok as far as i can see. One side-effect of this patch is where once one could configure ConfigHelper.setInitialAddress(conf, "localhost") this will no longer work for tasks trying to run on the down node. ColumnFamilyRecordReader.getLocations() will ConnectException trying to call describe_datacenter(..). This will lead to the task failing. Hadoop re-runs the task then on another node and eventually the job will complete. But the fall back to replica never is used. If the initialAddress is hardcoded to one node then we no longer have a decentralised job. I would like to allow a comma-separated in initialAddress, for example it could be "localhost, node01, node02, node03". This would give preference to localhost and avoid any centralisation. I would also like to make ColumnFamilyRecordReader.getLocations() return an iterator instead of an array. The createConnection(..) and client.describe_datacenter(..) calls are an unnecessary overhead when all nodes (or first endpoint location) are up, and could be avoided by lazy-loading the list. > ColumnFamilyRecordReader fails for a given split because a host is down, even > if records could reasonably be read from other replica. > - > > Key: CASSANDRA-2388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Eldon Stegall >Assignee: Mck SembWever > Labels: hadoop, inputformat > Fix For: 0.8.1 > > Attachments: 0002_On_TException_try_next_split.patch, > CASSANDRA-2388.patch > > > ColumnFamilyRecordReader only tries the first location for a given split. We > should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2590) row delete breaks read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046398#comment-13046398 ] Sylvain Lebresne commented on CASSANDRA-2590: - +1 on v4, we do need both calls. That being said, we should probably refactor that part of the code someday because it is not the cleanest thing ever. And there is probably ways to avoid those two phases (which does do some duplicate works I believe). > row delete breaks read repair > -- > > Key: CASSANDRA-2590 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2590 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Aaron Morton >Assignee: Aaron Morton >Priority: Minor > Fix For: 0.7.7, 0.8.1 > > Attachments: 0001-2590-v3.patch, > 0001-cf-resolve-test-and-possible-solution-for-read-repai.patch, 2590-v2.txt, > 2590-v4-0.7.txt > > > related to CASSANDRA-2589 > Working at CL ALL can get inconsistent reads after row deletion. Reproduced > on the 0.7 and 0.8 source. > Steps to reproduce: > # two node cluster with rf 2 and HH turned off > # insert rows via cli > # flush both nodes > # shutdown node 1 > # connect to node 2 via cli and delete one row > # bring up node 1 > # connect to node 1 via cli and issue get with CL ALL > # first get returns the deleted row, second get returns zero rows. > RowRepairResolver.resolveSuperSet() resolves a local CF with the old row > columns, and the remote CF which is marked for deletion. CF.resolve() does > not pay attention to the deletion flags and the resolved CF has both > markedForDeletion set and a column with a lower timestamp. The return from > resolveSuperSet() is used as the return for the read without checking if the > cols are relevant. > Also when RowRepairResolver.mabeScheduleRepairs() runs it sends two > mutations. Node 1 is given the row level deletation, and Node 2 is given a > mutation to write the old (and now deleted) column from node 2. I have some > log traces for this if needed. > A quick fix is to check for relevant columns in the RowRepairResolver, will > attach shortly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2743) add TABLE as a CQL alias for COLUMNFAMILY
[ https://issues.apache.org/jira/browse/CASSANDRA-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046391#comment-13046391 ] Eric Evans commented on CASSANDRA-2743: --- I wasn't (still aren't) fond of the idea of CQL driving some general shift in terminology, but I was under the impression that this ticket was about creating an alias to be friendlier to existing tools. So long as we continue to use consistent terminology in public discussions, documentation, etc, I don't see a problem with having an alias. If I've misunderstood "alias" here, and it _is_ about changing the terminology, then we should probably move this to the mailing list. If that happens you should probably be prepared to clear your schedule for the next few days. :) > add TABLE as a CQL alias for COLUMNFAMILY > - > > Key: CASSANDRA-2743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2743 > Project: Cassandra > Issue Type: Improvement > Components: API >Affects Versions: 0.8.0 >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.8.1 > > Attachments: CASSANDRA-2743.patch > > > This will make it easier on tools that support multiple databases like > SQLAlchemy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
