date:20110609

[
https://issues.apache.org/jira/browse/CASSANDRA-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.

2011-06-09 Thread Mck SembWever (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [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: 
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] [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 #Differencer #TreeRequest 
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 #TreeRequest 
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.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

[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-tabpanelfocusedCommentId=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] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-06-09 Thread donal zang (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 = 3foo.getBytes()0
 42  *   end   = 3foo.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-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-tabpanelfocusedCommentId=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-2752) repair fails with java.io.EOFException


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 #Differencer #TreeRequest 
 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 #TreeRequest 
 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

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=1133845view=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=1133845r1=1133844r2=1133845view=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 @@
 property name=build.src value=${basedir}/src/
 property name=build.src.java value=${basedir}/src/java/
 property name=build.src.resources value=${basedir}/src/resources/
-property name=build.src.driver value=${basedir}/drivers/java/src /
 property name=avro.src value=${basedir}/src/avro/
 property name=build.src.gen-java value=${basedir}/src/gen-java/
 property name=build.lib value=${basedir}/lib/
@@ -46,7 +45,6 @@
 property name=build.classes value=${build.dir}/classes/
 property name=build.classes.main value=${build.classes}/main /
 property name=build.classes.thrift value=${build.classes}/thrift /
-property name=build.classes.cql value=${build.classes}/cql /
 property name=javadoc.dir value=${build.dir}/javadoc/
 property name=javadoc.jars.dir value=${build.dir}/javadocs/
 property name=interface.dir value=${basedir}/interface/
@@ -64,7 +62,6 @@
 property name=test.long.src value=${test.dir}/long/
 property name=test.distributed.src value=${test.dir}/distributed/
 property name=dist.dir value=${build.dir}/dist/
-property name=cql.driver.version value=1.0.3 /
 condition property=version value=${base.version}
   isset property=release/
 /condition
@@ -161,7 +158,6 @@
 message=Not a source artifact, stopping here. /
 mkdir dir=${build.classes.main}/
 mkdir dir=${build.classes.thrift}/
-mkdir dir=${build.classes.cql}/
 mkdir dir=${test.lib}/
 mkdir dir=${test.classes}/
 mkdir dir=${build.src.gen-java}/
@@ -399,7 +395,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
   dependency groupId=log4j artifactId=log4j version=1.2.16 /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-all version=${version} /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-thrift version=${version} /
-  dependency groupId=org.apache.cassandra 
artifactId=cassandra-cql version=${version} /
 /dependencyManagement
 developer id=alakshman name=Avinash Lakshman/
 developer id=antelder name=Anthony Elder/
@@ -509,22 +504,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
 dependency groupId=org.slf4j artifactId=slf4j-api/
 dependency groupId=org.apache.thrift artifactId=libthrift/
   /artifact:pom
-  artifact:pom id=cql-pom
-artifactId=cassandra-cql
-url=http://cassandra.apache.org;
-name=Apache Cassandra
-parent groupId=org.apache.cassandra
-artifactId=cassandra-parent
-version=${version}/
-scm connection=${scm.connection} 
developerConnection=${scm.developerConnection} url=${scm.url}/
-dependency groupId=com.google.guava artifactId=guava/
-dependency groupId=org.slf4j artifactId=slf4j-api/
-dependency groupId=org.apache.thrift artifactId=libthrift/
-dependency groupId=org.apache.cassandra 
artifactId=cassandra-thrift/
-dependency groupId=org.apache.cassandra artifactId=cassandra-all/
-!-- because cassandra-all uses log4j, and we need cassandra-all, 
consumers must use log4j, so force log4j version of slf4j --
-dependency groupId=org.slf4j artifactId=slf4j-log4j12 
scope=runtime/
-  /artifact:pom
 
   artifact:pom id=dist-pom
 artifactId=apache-cassandra
@@ -695,11 +674,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
 src path=${build.src.gen-java}/
 classpath refid=cassandra.classpath/
 /javac
-javac debug=true debuglevel=${debuglevel}
-   destdir=${build.classes.cql} includeantruntime=false
-src path=${build.src.driver} /
-classpath refid=cassandra.classpath/
-/javac
 copy todir=${build.classes.main}
 fileset dir=${build.src.resources} /
 /copy
@@ -757,20 +731,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
 !-- /section --
 /manifest
   /jar
-
-  !-- CQL driver Jar --
-  artifact:writepom pomRefId=cql-pom 
-  
file=${build.dir}/${ant.project.name}-cql-${cql.driver.version}.pom/
-  jar 
jarfile=${build.dir}/${ant.project.name}-cql-${cql.driver.version}.jar
-   basedir=${build.classes.cql}
-manifest
-

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=1133852view=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: 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=1133873view=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=1133873r1=1133872r2=1133873view=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=1133873r1=1133872r2=1133873view=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=1133873r1=1133872r2=1133873view=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(ColumnFamily cf,

[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

[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-tabpanelfocusedCommentId=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-SVNview=revrev=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] [Commented] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-06-09 Thread donal zang (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Updated] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-06-09 Thread donal zang (JIRA)


 [ 
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

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=1133889view=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=1133889r1=1133888r2=1133889view=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 @@
 property name=test.data value=${test.dir}/data/
 property name=test.name value=*Test/
 property name=test.unit.src value=${test.dir}/unit/
-property name=test.src.driver value=${basedir}/drivers/java/test/
 property name=test.long.src value=${test.dir}/long/
 property name=test.distributed.src value=${test.dir}/distributed/
 property name=dist.dir value=${build.dir}/dist/
@@ -914,7 +913,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
   /classpath
   src path=${test.unit.src}/
   src path=${test.long.src}/
-  src path=${test.src.driver}/
 /javac
 
 !-- Non-java resources needed by the test suite --
@@ -991,9 +989,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
   jvmarg value=-Dlegacy-sstable-root=${test.data}/legacy-sstables/
   jvmarg value=-Dcorrupt-sstable-root=${test.data}/corrupt-sstables/
 /testmacro
-testmacro suitename=driverunit inputdir=${test.src.driver} 
timeout=6
-  jvmarg value=-Dlegacy-sstable-root=${test.data}/legacy-sstables/
-/testmacro
   /target
 
   target name=msg-ser-gen-test depends=build-test description=Generates 
message serializations

[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-tabpanelfocusedCommentId=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 #Differencer #TreeRequest 
 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 #TreeRequest 
 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

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=1133918view=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=1133918r1=1133917r2=1133918view=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
 /target
 
 !-- creates release tarballs --
-target name=artifacts depends=jar,javadoc,py-cql-driver,tx-cql-driver
+target name=artifacts depends=jar,javadoc,tx-cql-driver
 description=Create Cassandra release artifacts
   mkdir dir=${dist.dir}/
   copy todir=${dist.dir}/lib
@@ -1214,17 +1214,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
delete dir=build/eclipse-classes /
   /target
 
-  target name=py-cql-driver
-  description=Generate Python CQL driver artifact
-echoCreating Python CQL driver artifact.../echo
-exec executable=python dir=${basedir}/drivers/py failonerror=true
-  arg line=setup.py /
-  arg line=sdist /
-  arg line=--dist-dir /
-  arg line=${build.dir} /
-/exec
-  /target
-
   target name=tx-cql-driver
   description=Generate Twisted CQL driver artifact
 echoCreating Twisted CQL driver artifact.../echo

[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-tabpanelfocusedCommentId=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 #Differencer #TreeRequest 
 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 #TreeRequest 
 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

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=1133923view=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/

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=1133938view=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=1133938r1=1133937r2=1133938view=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
 /target
 
 !-- creates release tarballs --
-target name=artifacts depends=jar,javadoc,tx-cql-driver
+target name=artifacts depends=jar,javadoc
 description=Create Cassandra release artifacts
   mkdir dir=${dist.dir}/
   copy todir=${dist.dir}/lib
@@ -1214,17 +1214,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
delete dir=build/eclipse-classes /
   /target
 
-  target name=tx-cql-driver
-  description=Generate Twisted CQL driver artifact
-echoCreating Twisted CQL driver artifact.../echo
-exec executable=python dir=${basedir}/drivers/txpy failonerror=true
-  arg line=setup.py /
-  arg line=sdist /
-  arg line=--dist-dir /
-  arg line=${build.dir} /
-/exec
-  /target
-
   !-- Publish artifacts to Maven repositories --
   target name=mvn-install
   
depends=maven-declare-dependencies,artifacts,jar,sources-jar,javadoc-jar

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=1133939view=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: 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=1133951view=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=1133951r1=1133950r2=1133951view=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=1133951r1=1133950r2=1133951view=diff
==
--- cassandra/trunk/build.xml (original)
+++ cassandra/trunk/build.xml Thu Jun  9 15:46:19 2011
@@ -36,7 +36,6 @@
 property name=build.src value=${basedir}/src/
 property name=build.src.java value=${basedir}/src/java/
 property name=build.src.resources value=${basedir}/src/resources/
-property name=build.src.driver value=${basedir}/drivers/java/src /
 property name=avro.src value=${basedir}/src/avro/
 property name=build.src.gen-java value=${basedir}/src/gen-java/
 property name=build.lib value=${basedir}/lib/
@@ -46,7 +45,6 @@

[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-tabpanelfocusedCommentId=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 #Differencer #TreeRequest 
 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 #TreeRequest 
 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

[jira] [Updated] (CASSANDRA-2491) A new config parameter, broadcast_address

2011-06-09 Thread Vijay (JIRA)


 [ 
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

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=1133999view=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=1133999r1=1133998r2=1133999view=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-2386) sstable2json does not work on snapshot without moving the files

2011-06-09 Thread Patricio Echague (JIRA)


 [ 
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

[jira] [Updated] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files

2011-06-09 Thread Patricio Echague (JIRA)


 [ 
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

svn commit: r1134017 - in /cassandra/branches/cassandra-0.8/examples/bmt: CassandraBulkLoader.java README.txt

2011-06-09 Thread brandonwilliams

Author: brandonwilliams
Date: Thu Jun  9 17:53:32 2011
New Revision: 1134017

URL: http://svn.apache.org/viewvc?rev=1134017view=rev
Log:
Remove BMT example

Removed:
cassandra/branches/cassandra-0.8/examples/bmt/CassandraBulkLoader.java
cassandra/branches/cassandra-0.8/examples/bmt/README.txt

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=1134028view=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=1134028r1=1134027r2=1134028view=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=1134028r1=1134027r2=1134028view=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 self.cursor.description !=

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=1134030view=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=1134030r1=1134029r2=1134030view=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()

[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

[jira] [Updated] (CASSANDRA-2452) New EC2 Snitch to use public ip and hence natively support for EC2 mult-region's.

2011-06-09 Thread Vijay (JIRA)


 [ 
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-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-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] [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-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-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(ClassT)}} 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-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] [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] [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] [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-tabpanelfocusedCommentId=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] [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] [Commented] (CASSANDRA-2480) Named keys / virtual columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (CASSANDRA-2480) Named keys / virtual columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [Commented] (CASSANDRA-2480) Named keys / virtual columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [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] [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] [Commented] (CASSANDRA-2480) Named keys / virtual columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (CASSANDRA-2474) CQL support for compound columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-2474) CQL support for compound columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [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] [Commented] (CASSANDRA-2480) Named keys / virtual columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

svn commit: r1134108 - /cassandra/branches/cassandra-0.8/tools/stress/build.xml

2011-06-09 Thread brandonwilliams

Author: brandonwilliams
Date: Thu Jun  9 22:10:19 2011
New Revision: 1134108

URL: http://svn.apache.org/viewvc?rev=1134108view=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=1134108r1=1134107r2=1134108view=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.
  --
-project basedir=. default=build name=stress
+project basedir=. default=jar name=stress
 property name=cassandra.dir value=../.. /
 property name=cassandra.lib value=${cassandra.dir}/lib /
 property name=build.src value=${basedir}/src /
@@ -49,9 +49,19 @@
 /target
 
 target name=jar depends=build
+manifest file=MANIFEST.MF
+attribute name=Built-By value=Pavel Yaskevich/
+attribute name=Main-Class 
value=org.apache.cassandra.stress.Stress/
+/manifest
+
 mkdir dir=${build.classes}/META-INF /
-jar jarfile=${build.out}/${final.name}.jar
-basedir=${build.classes} /
+
+jar destfile=${build.out}/${final.name}.jar manifest=MANIFEST.MF
+fileset dir=${build.classes}/
+fileset dir=${cassandra.dir}/build/classes/main /
+fileset dir=${cassandra.dir}/build/classes/thrift /
+zipgroupfileset dir=${cassandra.lib} includes=*.jar /
+/jar
 /target
 
 target name=clean

[jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[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-tabpanelfocusedCommentId=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

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=1134109view=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=1134109r1=1134108r2=1134109view=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-1133874

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=1134110view=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=1134110r1=1134109r2=1134110view=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=1134110r1=1134109r2=1134110view=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=1134110r1=1134109r2=1134110view=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;)

[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-tabpanelfocusedCommentId=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

[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 ip or token' 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-2386) sstable2json does not work on snapshot without moving the files

2011-06-09 Thread Patricio Echague (JIRA)


 [ 
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

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=1134120view=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=1134120r1=1134119r2=1134120view=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=1134120r1=1134119r2=1134120view=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=1134120r1=1134119r2=1134120view=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 PairDescriptor,String 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:   ksname/cfname-[tmp-][version-]gen-component
+ * Snapshot path: 
ksname/snapshots/snapshot-name/cfname-[tmp-][version-]gen-component
+ *
+ * @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:
+// ksname/snapshots/ and second call to parent takes us to 
ksname.
+return directory.getParentFile().getParentFile().getName();
+}
+return directory.getName();
+}
+
+/**
+ * @return codeTRUE/code if this directory represents a snapshot 
directory. codeFALSE/code 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:

[jira] [Commented] (CASSANDRA-2740) nodetool decommission should throw an error when there are extra params

2011-06-09 Thread Brandon Williams (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 ip or token' 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-tabpanelfocusedCommentId=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 ip or token' 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] [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 ip or token' 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-2752) repair fails with java.io.EOFException

2011-06-09 Thread Chris Goffinet (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 #Differencer #TreeRequest 
 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 #TreeRequest 
 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

[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-2744) stress.jar is not executable


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-SVNview=revrev=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-tabpanelfocusedCommentId=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-SVNview=revrev=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] [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-tabpanelfocusedCommentId=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-SVNview=revrev=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] [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] [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-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-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] [Issue Comment Edited] (CASSANDRA-2474) CQL support for compound columns

2011-06-09 Thread T Jake Luciani (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (CASSANDRA-2474) CQL support for compound columns

2011-06-09 Thread T Jake Luciani (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [Updated] (CASSANDRA-2751) Improved Metrics collection

2011-06-09 Thread Ryan King (JIRA)


 [ 
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-2474) CQL support for compound columns


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (CASSANDRA-2474) CQL support for compound columns

2011-06-09 Thread T Jake Luciani (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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