date:20130227


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588230#comment-13588230
 ] 

Sylvain Lebresne commented on CASSANDRA-5293:
-

Let's play the devil's advocate a bit.

I think that for CQL3, this is already more or less formalized, as timestamp 
are optional and are epoch-in-micros when not provided. And I'm clearly fine 
being ever move vocal in the documentation that timestamp *have to be* 
epoch-in-micros and using that fact (for CQL3 specific features that is).

On the thrift/lower-level storage engine side however, I'm not exactly sure 
what you have in mind, but I think it would be nice to at least not break the 
existing. Typically, if we're talking of starting to use client timestamps to 
do tombstone GC, I'm not sure I'm sold.

Typically, if we're talking of adding a new compaction strategy, and for some 
reason, being able to assume epoch-in-micros timestamp really helps, then I'd 
be totally fine with that and we could tell you can't use that if you don't 
have epoch-in-micros.

But despite our recommendations, I hightly suspect there is users out there 
still not using epoch-in-micros (after all, there is client libraries out there 
allowing custom timestamp provider class and that ship with a milli-second 
provider (and even a second resolution for at least one of them). It's not the 
default but still). And while upgrading to epoch-in-micros from those lower 
resolution is theoretically simple, it's fairly costly in practice if you have 
to do it on the spot (you have to rewrite all the things).

I guess a related question is also, what complexity and lost opportunities 
are we talking about?


 formalize that timestamps are epoch-in-micros in 2.0
 

 Key: CASSANDRA-5293
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5293
 Project: Cassandra
  Issue Type: Task
  Components: Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 We've worked around don't assume timestamps are actually timestamps but the 
 utility is not worth the complexity and lost opportunities to optimize this 
 imposes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-02-27 Thread Sergio Bossa (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588303#comment-13588303
 ] 

Sergio Bossa commented on CASSANDRA-5062:
-

[~jbellis]

{quote}This is not correct for Paxos. (Not sufficiently familiar with ZAB to 
comment there){quote}

Right, I was talking about Zab, which does that exactly for improving liveness 
and performance.

{quote}What does this 2PC-that-avoids-lost-acks look like?{quote}

Well, given my lack of familiarity with Cassandra internals, I may be missing 
something here, so let's be clear about the lost-ack problem: my understanding 
of lost-ack is about what happens when the coordinator node sends a QUORUM 
request and fails before getting the ack back, causing uncertainty about the 
request status. So please correct me if I'm wrong here.
But stated this way, this problem can be overcame with Zab-like 2PC: once the 
coordinator gets the acks from the prepare phase, it can commit without having 
to wait for all acks, because only committed values with the highest commit 
id will be (QUORUM) read. Then:
1) If the coordinator fails during the prepare phase (lost ack), nothing will 
be committed, hence the previous committed value will be read, and if it will 
be hinted/repaired, it will just be a tentative value.
2) If the coordinator fails after sending commits, the coordinator with the 
highest commit id will take over and realign followers.
3) If a partition happens, the coordinator with the minority of followers will 
refuse to operate CAS (Paxos would behave exactly the same here).

Does it make sense to you?

Obviously I may be missing some corner case, and above all, I'm not sure about 
how comfortably this could be implemented in Cassandra (lack of knowledge 
again), so take my comments just as food for thoughts.

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588316#comment-13588316
]

Cristian Opris commented on CASSANDRA-5062:
---

Zab is not Paxos just vaguely resembles it. Zab leader replicates a totally
ordered log of idempotent operations to ALL followers. It requires a quorum of
followers to acknowledge the write before committing on the leader, and then
commits on the followers. When leader fails, the new leader is the one that is
most up-to-date with the writes (highest log sequence number) so that one will
necessarily have all the committed writes (If it does not have the commit for a
particular write I believe it can assume it's been committed, I'm a bit unclear
on this point).

The new leader needs to fully synchronize all the replicas and establish a
quorum before writes can resume. That may introduce a small period of
unavailability.

At least in ZK I believe clients connect to a single replica and may be behind
the leader with reads but they will always see all the writes (including their
own since they're forwarded to leader and replicated back) in consistent order

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

Strong consistency is not enough to prevent race conditions. The classic
example is user account creation: we want to ensure usernames are unique, so
we only want to signal account creation success if nobody else has created
the account yet. But naive read-then-write allows clients to race and both
think they have a green light to create.

[jira] [Commented] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588328#comment-13588328
]

Cristian Opris commented on CASSANDRA-5062:
---

On the other hand Paxos for each CAS would be quite different.

The basic approach would be to have each CAS be a full Paxos round (Phase 1:
prepare/promise, Phase 2: propose/accept). In this case each round is
independent and writes can happen concurrently (as opposed to Zab where all
writes are applied serially cluster-wide).

There doesn't even need to be a leader, that is an optimisation to ensure
liveness (avoid duelling proposers).

Now since full Paxos is quite expensive in terms of roundtrips, there are
optimisations to reduce that (see Fast Paxos in the wikipedia article) but I
have yet to study the details of that.

There is also the question of how the actual CAS op would be integrated with
Paxos (who does the CAS ? presumably the proposer needs to be able to do the
CAS verify locally, or maybe acceptors can NACK if the CAS is rejected locally
? Would that be a valid nack in Paxos terms ?) but that can be sorted out.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Commented] (CASSANDRA-5062) Support CAS


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588332#comment-13588332
 ] 

Cristian Opris commented on CASSANDRA-5062:
---

Re. which storage to use for metadata, why not use a meta-column family, like 
for secondary indexes, or like the locks would have required ? 

For Zab a persistent log will be necessary, and for Paxos a way to persist the 
paxos round state for each row.

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-02-27 Thread Jason Brown (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588339#comment-13588339
 ] 

Jason Brown commented on CASSANDRA-5062:


[~onetoinfin...@yahoo.com] Do you have a reference about ZAB? Thanks.

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588344#comment-13588344
]

Sylvain Lebresne commented on CASSANDRA-5062:
-

bq. once the coordinator gets the acks from the prepare phase, it can commit
without having to wait for all acks

What Jonathan means by lost ack is: what happens if when the coordinator sends
the commits to replicas, but only a minority of replicas get that commit (say 1
of 3 replica got it (and persist it), the two other dies between the prepare
and commit phase). And later on, the 2 replica get back up while the 3rd one
now dies, and we do a new CAS (that would have a majority and so should work).

In that case, probably the coordinator should hint something when he don't get
the commit-ack from the 2 replicas that died. It could either try to revert
from the 1 replica that did received the commit, but said replica can now be
dead (playing devil's advocate here), so it might be a hint really. Or we rely
on the commit being hinted to the 2 died replica when they come back up. But in
that any case, replicas would need to check and wait for those hints when they
come back up before joining the ring, and that's a problem (any other node
could have hint, we don't want to wait for everyone).

To be clear, I'm not saying Zab doesn't work or anything like that, just
explaining the lost-ack problem we have identified with a naive 2PC
implementation.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Created] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands

Pavel Trukhanov created CASSANDRA-5295:
--

 Summary: cassandra-cli java.lang.NullPointerException for almost 
any commands
 Key: CASSANDRA-5295
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov


{code}
cassandra-cli -v -h srv1 -p 9160 
Connected to: myspace on srv1/9160
Welcome to Cassandra CLI version 1.2.1

Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.

[default@unknown] use myspace;
java.lang.NullPointerException
[default@myspace] describe;
java.lang.NullPointerException
[default@myspace] list mycf1;
null
[default@myspace]  
{code}

and nothing in system.log or output.log

which information can i provide to speed up cause determination?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5245) AnitEntropy/MerkleTree Error

2013-02-27 Thread Antti Koivisto (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588345#comment-13588345
 ] 

Antti Koivisto commented on CASSANDRA-5245:
---

We have the same problem even with Cassandra 1.2.2. 

 AnitEntropy/MerkleTree Error
 

 Key: CASSANDRA-5245
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5245
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0, 1.2.1
Reporter: David Röhr
Assignee: Sylvain Lebresne
Priority: Minor

 We are seeing AntiEntropy errors when performing repair jobs in one of our 
 Cassandra clusters. It seems to have started with 1.2. (maybe an issue with 
 vnodes) The exceptions occur almost every time we try to do a repair on all 
 column families in the cluster. Doing the same task on 1.1 does not trigger 
 this.
 6 nodes cluster (vnodes, murmur3, rf:3)
 very low activity
 running a nodetool repair -pr loop on the cluster nodes
 nodetool hangs, and same big stacktrace in logs.
 root 11025 0.0 0.0 106100 1436 pts/0 S+ Feb11 0:00 _ /bin/sh 
 /usr/bin/nodetool -h HOST -p 7199 -pr repair KEYSPACE COLUMN_FAMILY
 ERROR [AntiEntropyStage:3] 2013-02-11 17:08:12,630 CassandraDaemon.java (line 
 133) Exception in thread Thread[AntiEntropyStage:3,5,main]
 java.lang.AssertionError
   at org.apache.cassandra.utils.MerkleTree.inc(MerkleTree.java:137)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:245)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:256)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at 
 org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:267)
   at

[jira] [Commented] (CASSANDRA-2699) continuous incremental anti-entropy

2013-02-27 Thread Benjamin Coverston (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588347#comment-13588347
]

Benjamin Coverston commented on CASSANDRA-2699:
---

You're right, which also means that in the face of idempotent writes and replay
the incremental scenario is also broken with the in-memory tree.

continuous incremental anti-entropy
---

Key: CASSANDRA-2699
URL: https://issues.apache.org/jira/browse/CASSANDRA-2699
Project: Cassandra
Issue Type: Improvement
Reporter: Peter Schuller
Assignee: Peter Schuller

Currently, repair works by periodically running bulk jobs that (1)
performs a validating compaction building up an in-memory merkle tree,
and (2) streaming ring segments as needed according to differences
indicated by the merkle tree.
There are some disadvantages to this approach:
* There is a trade-off between memory usage and the precision of the
merkle tree. Less precision means more data streamed relative to
what is strictly required.
* Repair is a periodic bulk process that runs for a significant
period and, although possibly rate limited as compaction (if 0.8 or
backported throttling patch applied), is a divergence in terms of
performance characteristics from normal operation of the cluster.
* The impact of imprecision can be huge on a workload dominated by I/O
and with cache locality being critical, since you will suddenly
transfers lots of data to the target node.
I propose a more incremental process whereby anti-entropy is
incremental and continuous over time. In order to avoid being
seek-bound one still wants to do work in some form of bursty fashion,
but the amount of data processed at a time could be sufficiently small
that the impact on the cluster feels a lot more continuous, and that
the page cache allows us to avoid re-reading differing data twice.
Consider a process whereby a node is constantly performing a per-CF
repair operation for each CF. The current state of the repair process
is defined by:
* A starting timestamp of the current iteration through the token
range the node is responsible for.
* A finger indicating the current position along the token ring to
which iteration has completed.
This information, other than being in-memory, could periodically (every
few minutes or something) be stored persistently on disk.
The finger advances by the node selecting the next small bit of the
ring and doing whatever merkling/hashing/checksumming is necessary on
that small part, and then asking neighbors to do the same, and
arranging for neighbors to send the node data for mismatching
ranges. The data would be sent either by way of mutations like with
read repair, or by streaming sstables. But it would be small amounts
of data that will act roughly the same as regular writes for the
perspective of compaction.
Some nice properties of this approach:
* It's always on; no periodic sudden effects on cluster performance.
* Restarting nodes never cancels or breaks anti-entropy.
* Huge compactions of entire CF:s never clog up the compaction queue
(not necessarily a non-issue even with concurrent compactions in
0.8).
* Because we're always operating on small chunks, there is never the
same kind of trade-off for memory use. A merkel tree or similar
could be calculated at a very detailed level potentially. Although
the precision from the perspective of reading from disk would likely
not matter much if we are in page cache anyway, very high precision
could be *very* useful when doing anti-entropy across data centers
on slow links.
There are devils in details, like how to select an appropriate ring
segment given that you don't have knowledge of the data density on
other nodes. But I feel that the overall idea/process seems very
promising.

[jira] [Commented] (CASSANDRA-2699) continuous incremental anti-entropy

[
https://issues.apache.org/jira/browse/CASSANDRA-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588366#comment-13588366
]

Sylvain Lebresne commented on CASSANDRA-2699:
-

bq. in the face of idempotent writes and replay the incremental scenario is
also broken with the in-memory tree

Yeah, and streaming and read-repair breaks things too I too (for the in-memory
tree idea), and I'm not sure how you even compute the initial in-memory tree at
startup in the first-place (there's a talk of saving the in-memory tree on disk
to reload it on restart, but I see many problem with that so it could be I
misunderstood the idea). But overall it sounded the conclusion of
CASSANDRA-4482 was that the in-memory trees themselves do not sound very
useful, which from my current comprehension of the idea (that could be very
partial/wrong) sounds about right.

continuous incremental anti-entropy
---

Key: CASSANDRA-2699
URL: https://issues.apache.org/jira/browse/CASSANDRA-2699
Project: Cassandra
Issue Type: Improvement
Reporter: Peter Schuller
Assignee: Peter Schuller

[jira] [Created] (CASSANDRA-5296) NPE on /init.d/cassandra start

Pavel Trukhanov created CASSANDRA-5296:
--

 Summary: NPE on /init.d/cassandra start
 Key: CASSANDRA-5296
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5296
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 
14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Reporter: Pavel Trukhanov


{code}
== /var/log/cassandra/output.log ==
INFO 18:05:18,466 Logging initialized
 INFO 18:05:18,477 JVM vendor/version: Java HotSpot(TM) 64-Bit Server 
VM/1.6.0_32
 INFO 18:05:18,478 Heap size: 6358564864/6358564864
 INFO 18:05:18,478 Classpath: 
/usr/share/java/mx4j-tools.jar:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/avro-1.4.0-fixes.jar:/usr/share/cassandra/lib/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang-2.6.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/guava-13.0.1.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jline-1.0.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.7.0.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/metrics-core-2.0.3.jar:/usr/share/cassandra/lib/netty-3.5.9.Final.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.7.2.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.7.2.jar:/usr/share/cassandra/lib/snakeyaml-1.6.jar:/usr/share/cassandra/lib/snappy-java-1.0.4.1.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/apache-cassandra-1.2.1.jar:/usr/share/cassandra/apache-cassandra-thrift-1.2.1.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/stress.jar:/usr/share/java/jna.jar:/etc/cassandra:/usr/share/java/commons-daemon.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar
 INFO 18:05:20,021 JNA mlockall successful
 INFO 18:05:20,042 Loading settings from file:/etc/cassandra/cassandra.yaml
 INFO 18:05:20,352 DiskAccessMode 'auto' determined to be mmap, indexAccessMode 
is mmap
 INFO 18:05:20,352 disk_failure_policy is stop
 INFO 18:05:20,368 Global memtable threshold is enabled at 2048MB
 INFO 18:05:21,401 Initializing key cache with capacity of 100 MBs.
 INFO 18:05:21,417 Scheduling key cache save to each 14400 seconds (going to 
save all keys).
 INFO 18:05:21,417 Initializing row cache with capacity of 0 MBs and provider 
org.apache.cassandra.cache.SerializingCacheProvider
 INFO 18:05:21,420 Scheduling row cache save to each 0 seconds (going to save 
all keys).
 INFO 18:05:21,640 Opening 
/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-ib-3 
(191 bytes)
 INFO 18:05:22,185 Opening 
/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ib-3
 (2674 bytes)
 INFO 18:05:22,214 Opening 
/var/lib/cassandra/data/system/schema_columns/system-schema_columns-ib-3 (437 
bytes)
 INFO 18:05:22,240 Opening 
/var/lib/cassandra/data/system/peers/system-peers-ib-3 (150 bytes)
 INFO 18:05:22,240 Opening 
/var/lib/cassandra/data/system/peers/system-peers-ib-2 (300 bytes)
 INFO 18:05:22,240 Opening 
/var/lib/cassandra/data/system/peers/system-peers-ib-1 (193 bytes)
 INFO 18:05:22,395 Opening 
/var/lib/cassandra/data/system/local/system-local-ib-2 (120 bytes)
 INFO 18:05:22,395 Opening 
/var/lib/cassandra/data/system/local/system-local-ib-7 (84 bytes)
 INFO 18:05:22,396 Opening 
/var/lib/cassandra/data/system/local/system-local-ib-8 (535 bytes)
 INFO 18:05:22,396 Opening 
/var/lib/cassandra/data/system/local/system-local-ib-4 (146 bytes)
 INFO 18:05:22,395 Opening 
/var/lib/cassandra/data/system/local/system-local-ib-3 (90 bytes)
 INFO 18:05:22,395 Opening 
/var/lib/cassandra/data/system/local/system-local-ib-6 (97 bytes)
 INFO 18:05:22,396 Opening 
/var/lib/cassandra/data/system/local/system-local-ib-1 (351 bytes)
 INFO 18:05:22,396 Opening 
/var/lib/cassandra/data/system/local/system-local-ib-5 (97 bytes)
java.lang.NullPointerException
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at 
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:73)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:93)
at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:32)
at 
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:96)
at 
org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(CFMetaData.java:1347)
at

[jira] [Commented] (CASSANDRA-5236) Migration during shutdown can cause AE


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588380#comment-13588380
 ] 

Aleksey Yeschenko commented on CASSANDRA-5236:
--

Agreed. +1

 Migration during shutdown can cause AE
 --

 Key: CASSANDRA-5236
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5236
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Trivial
 Fix For: 1.1.11

 Attachments: 5236.txt


 Mostly just a problem for the dtests on occasion:
 {noformat}
  INFO [FlushWriter:1] 2013-02-08 17:03:49,727 Memtable.java (line 453) 
 Writing Memtable-schema_columns@1757448463(793/793 serialized/live bytes, 15 
 ops)
  INFO [FlushWriter:1] 2013-02-08 17:03:49,752 Memtable.java (line 487) 
 Completed flushing 
 /tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-4-Data.db
  (339 bytes) for commitlog position ReplayPosition(segmentId=1360364624598, 
 position=66887)
  INFO [CompactionExecutor:2] 2013-02-08 17:03:49,754 CompactionTask.java 
 (line 112) Compacting 
 [SSTableReader(path='/tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-4-Data.db'),
  
 SSTableReader(path='/tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-3-Data.db'),
  
 SSTableReader(path='/tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-2-Data.db'),
  
 SSTableReader(path='/tmp/dtest-gEW6x2/test/node3/data/system/schema_columns/system-schema_columns-ib-1-Data.db')]
  INFO [CompactionExecutor:3] 2013-02-08 17:03:49,759 CompactionTask.java 
 (line 272) Compacted 4 sstables to 
 [/tmp/dtest-gEW6x2/test/node3/data/system/schema_columnfamilies/system-schema_columnfamilies-ib-5,].
   7,473 bytes to 5,595 (~74% of original) in 32ms = 0.166744MB/s.  6 total 
 rows, 4 unique.  Row merge counts were {1:3, 2:0, 3:1, 4:0, }
 ERROR [InternalResponseStage:1] 2013-02-08 17:03:49,787 CassandraDaemon.java 
 (line 135) Exception in thread Thread[InternalResponseStage:1,5,main]
 java.lang.AssertionError
 at 
 org.apache.cassandra.service.MigrationManager.passiveAnnounce(MigrationManager.java:320)
 at 
 org.apache.cassandra.config.Schema.updateVersionAndAnnounce(Schema.java:458)
 at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:347)
 at 
 org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:66)
 at 
 org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:47)
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
 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)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-02-27 Thread Sergio Bossa (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588390#comment-13588390
]

Sergio Bossa commented on CASSANDRA-5062:
-

Thanks for clarifying, [~slebresne].

{quote}what happens if when the coordinator sends the commits to replicas, but
only a minority of replicas get that commit (say 1 of 3 replica got it (and
persist it), the two other dies between the prepare and commit phase). And
later on, the 2 replica get back up while the 3rd one now dies, and we do a new
CAS (that would have a majority and so should work).{quote}

The Zab deviation from standard 2PC here is that the coordinator doesn't need
to wait for the ack from replicas on commit phase.
If a replica fails during prepare phase, it will just be out of quorum.
If a replica fails after prepare but before completing the commit, it will
recover later from the leader: so in your example, when 2 and 3 come up, they
will join the leader which may hint them the correct values.
If the third replica died in your example was actually the coordinator, a new
coordinator will be elected among the ones that have seen either the last
commit or the latest *proposed* commit, which will become committed.
So there's no lost-ack problem as there's actually no ack at all in the commit
phase: it will be eventually committed or recovered.

By the way, I'm not saying this is better than Paxos for sure: I just *think*
this is easier and more practical (which yes doesn't mean can be implemented
easily on top of Cassandra).

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

git commit: CQL3 shouldn't lowercase DC names for NTS

2013-02-27 Thread slebresne

Updated Branches:
  refs/heads/cassandra-1.2 a4166496f - db7759a2c


CQL3 shouldn't lowercase DC names for NTS

patch by slebresne; reviewed by jbellis for CASSANDRA-5292


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/db7759a2
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/db7759a2
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/db7759a2

Branch: refs/heads/cassandra-1.2
Commit: db7759a2cac76d86a9f5b1ca82f7e08cc358c28d
Parents: a416649
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Wed Feb 27 15:43:24 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Wed Feb 27 15:46:17 2013 +0100

--
 CHANGES.txt|1 +
 NEWS.txt   |   18 +++
 .../apache/cassandra/cql3/PropertyDefinitions.java |7 +-
 3 files changed, 20 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/db7759a2/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b19b092..85e283a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 1.2.3
  * Avoid allocating SSTableBoundedScanner during repair when the range does 
not intersect the sstable (CASSANDRA-5249)
+ * Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292)
 Merged from 1.1:
  * nodetool: ability to repair specific range (CASSANDRA-5280)
  * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/db7759a2/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 5b4f478..01db820 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -8,6 +8,24 @@ upgrade, just in case you need to roll back to the previous 
version.
 (Cassandra version X + 1 will always be able to read data files created
 by version X, but the inverse is not necessarily the case.)
 
+1.2.3
+=
+
+Upgrading
+-
+- CQL3 uses to be case-insensitive for property map key in ALTER and CREATE
+  statements. In other words:
+CREATE KEYSPACE test WITH replication = { 'CLASS' : 'SimpleStrategy',
+  'REPLICATION_FACTOR' : '1' }
+  was allowed. However, this was not consistent with the fact that string
+  literal are case sensitive in every other places and more importantly 
this
+  break NetworkTopologyStrategy for which DC names are case sensitive. 
Those
+  property map key are now case sensitive. So the statement above should be
+  changed to:
+CREATE KEYSPACE test WITH replication = { 'class' : 'SimpleStrategy',
+  'replication_factor' : '1' }
+
+
 1.2.2
 =
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/db7759a2/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java
--
diff --git a/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java 
b/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java
index 3db84fa..ba83e45 100644
--- a/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java
+++ b/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java
@@ -38,12 +38,7 @@ public class PropertyDefinitions
 
 public void addProperty(String name, MapString, String value) throws 
SyntaxException
 {
-// Lowercase the map keys to be nice to users
-MapString, String lowerCased = new HashMapString, 
String(value.size());
-for (Map.EntryString, String entry : value.entrySet())
-lowerCased.put(entry.getKey().toLowerCase(), entry.getValue());
-
-if (properties.put(name, lowerCased) != null)
+if (properties.put(name, value) != null)
 throw new SyntaxException(String.format(Multiple definition for 
property '%s', name));
 }

[jira] [Commented] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588400#comment-13588400
]

Jonathan Ellis commented on CASSANDRA-5062:
---

bq. probably the coordinator should hint something when he don't get the
commit-ack from the 2 replicas that died

This is racy, though; if the coordinator also dies, then we still lose.

FWIW, Spinnaker's solution is actually pretty dicey here too: the leader does
2PC, and if the leader does not get a majority of acks back to it's proposal,
it will return fail the op. But, it doesn't actually abort or revert the
proposal on the followers. (And if it tried, it would still be open to a race,
where it fails before aborting, leaving some proposals extant.)

Then, when a new leader is elected, it replays the proposals it has not yet
committed. So a proposal that originally failed, and was returned as such to
the client, could succeed after failover.

I think Sergio's proposal has a similar problem: if the leader reports success
to the client after local commit, but before it has been committed to the
followers, we could either (1) lose the commit on failover if followers are
pessimistic, or (2) commit data that we originally reported failed as in
Spinnaker if we are optimistic. On the other hand if the leader tries to wait
for commit ack from followers before reporting to the client it could block
indefinitely during a partition, so that is no solution either.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Comment Edited] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588400#comment-13588400
]

Jonathan Ellis edited comment on CASSANDRA-5062 at 2/27/13 2:51 PM:

bq. probably the coordinator should hint something when he don't get the
commit-ack from the 2 replicas that died

This is racy, though; if the coordinator also dies, then we still lose.

Then, when a new leader is elected, it replays the proposals it has not yet
committed. So a proposal that originally failed, and was returned as such to
the client, could end up committed after failover. Which is, at best,
unexpected, and in the CAS case I'm pretty sure is outright broken.

was (Author: jbellis):
bq. probably the coordinator should hint something when he don't get the
commit-ack from the 2 replicas that died

This is racy, though; if the coordinator also dies, then we still lose.

Then, when a new leader is elected, it replays the proposals it has not yet
committed. So a proposal that originally failed, and was returned as such to
the client, could succeed after failover.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Comment Edited] (CASSANDRA-5062) Support CAS


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588400#comment-13588400
 ] 

Jonathan Ellis edited comment on CASSANDRA-5062 at 2/27/13 2:52 PM:


bq. probably the coordinator should hint something when he don't get the 
commit-ack from the 2 replicas that died

This is racy, though; if the coordinator also dies, then we still lose.

FWIW, Spinnaker's solution is actually pretty dicey here too: the leader does 
2PC, and if the leader does not get a majority of acks back to it's proposal, 
it will return fail the op.  But, it doesn't actually abort or revert the 
proposal on the followers.  (And if it tried, it would still be open to a race, 
where it fails before aborting, leaving some proposals extant.)

Then, when a new leader is elected, the new leader replays the proposals it has 
not yet committed.  So a proposal that originally failed, and was returned as 
such to the client, could end up committed  after failover.  Which is, at best, 
unexpected, and in the CAS case I'm pretty sure is outright broken.

I think Sergio's proposal has a similar problem: if the leader reports success 
to the client after local commit, but before it has been committed to the 
followers, we could either (1) lose the commit on failover if followers are 
pessimistic, or (2) commit data that we originally reported failed as in 
Spinnaker if we are optimistic.  On the other hand if the leader tries to wait 
for commit ack from followers before reporting to the client it could block 
indefinitely during a partition, so that is no solution either.

  was (Author: jbellis):
bq. probably the coordinator should hint something when he don't get the 
commit-ack from the 2 replicas that died

This is racy, though; if the coordinator also dies, then we still lose.

FWIW, Spinnaker's solution is actually pretty dicey here too: the leader does 
2PC, and if the leader does not get a majority of acks back to it's proposal, 
it will return fail the op.  But, it doesn't actually abort or revert the 
proposal on the followers.  (And if it tried, it would still be open to a race, 
where it fails before aborting, leaving some proposals extant.)

Then, when a new leader is elected, it replays the proposals it has not yet 
committed.  So a proposal that originally failed, and was returned as such to 
the client, could end up committed  after failover.  Which is, at best, 
unexpected, and in the CAS case I'm pretty sure is outright broken.

I think Sergio's proposal has a similar problem: if the leader reports success 
to the client after local commit, but before it has been committed to the 
followers, we could either (1) lose the commit on failover if followers are 
pessimistic, or (2) commit data that we originally reported failed as in 
Spinnaker if we are optimistic.  On the other hand if the leader tries to wait 
for commit ack from followers before reporting to the client it could block 
indefinitely during a partition, so that is no solution either.
  
 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588407#comment-13588407
 ] 

Jonathan Ellis commented on CASSANDRA-5295:
---

cassandra-cli --debug

 cassandra-cli java.lang.NullPointerException for almost any commands
 

 Key: CASSANDRA-5295
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 
 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
  Labels: cassandra-cli

 {code}
 cassandra-cli -v -h srv1 -p 9160 
 Connected to: myspace on srv1/9160
 Welcome to Cassandra CLI version 1.2.1
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 [default@unknown] use myspace;
 java.lang.NullPointerException
 [default@myspace] describe;
 java.lang.NullPointerException
 [default@myspace] list mycf1;
 null
 [default@myspace]  
 {code}
 and nothing in system.log or output.log
 which information can i provide to speed up cause determination?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588411#comment-13588411
 ] 

Pavel Trukhanov commented on CASSANDRA-5295:


{code}[default@unknown] use myspace;
java.lang.NullPointerException
java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.cassandra.cli.CliClient.loadCql3Defs(CliClient.java:339)
at org.apache.cassandra.cli.CliClient.getKSMetaData(CliClient.java:324)
at 
org.apache.cassandra.cli.CliClient.executeUseKeySpace(CliClient.java:2025)
at 
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:263)
at 
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:210)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:337)
Caused by: java.lang.NullPointerException
at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
at 
org.apache.cassandra.cli.CliClient.loadCql3DefsUnchecked(CliClient.java:361)
at org.apache.cassandra.cli.CliClient.loadCql3Defs(CliClient.java:335)
... 5 more
{code}

 cassandra-cli java.lang.NullPointerException for almost any commands
 

 Key: CASSANDRA-5295
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 
 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
  Labels: cassandra-cli

 {code}
 cassandra-cli -v -h srv1 -p 9160 
 Connected to: myspace on srv1/9160
 Welcome to Cassandra CLI version 1.2.1
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 [default@unknown] use myspace;
 java.lang.NullPointerException
 [default@myspace] describe;
 java.lang.NullPointerException
 [default@myspace] list mycf1;
 null
 [default@myspace]  
 {code}
 and nothing in system.log or output.log
 which information can i provide to speed up cause determination?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-5297) sstableloader's interface could be improved

2013-02-27 Thread Dan Peebles (JIRA)

Dan Peebles created CASSANDRA-5297:
--

 Summary: sstableloader's interface could be improved
 Key: CASSANDRA-5297
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5297
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Dan Peebles
Priority: Minor


According to 
http://stackoverflow.com/questions/6832285/how-do-you-use-the-cassandra-tool-sstableloader
 and other references, it looks like running sstableloader in many cases 
necessitates duplicating (a subset of) the destination node's Cassandra install 
folder. This is primarily to have the right cassandra.yaml in the right place, 
as far as I can see.

It seems like it would be much less of a pain to use the bulk loader if it took 
a parameter for where to look for cassandra.yaml (or supported the individual 
settings it needed to gossip correctly directly on command line)

The whole business about making a duplicate loopback interface also seems a bit 
Byzantine.

Since the command-line tool appears just to be a fairly thin wrapper around 
code that is used elsewhere in Cassandra, disentangling it from the standard 
Cassandra configuration might be fairly difficult. But then again I'm pretty 
clueless so I'd be happy to be corrected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588443#comment-13588443
 ] 

Pavel Trukhanov commented on CASSANDRA-5295:


{code}[default@myspace] list mycf1;
null
java.lang.NullPointerException
at org.apache.cassandra.cli.CliClient.currentCfDefs(CliClient.java:441)
at org.apache.cassandra.cli.CliClient.executeList(CliClient.java:1389)
at 
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:272)
at 
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:210)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:337)
[default@myspace] describe;
java.lang.NullPointerException
java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.cassandra.cli.CliClient.loadCql3Defs(CliClient.java:339)
at org.apache.cassandra.cli.CliClient.getKSMetaData(CliClient.java:324)
at 
org.apache.cassandra.cli.CliClient.executeDescribe(CliClient.java:2229)
at 
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:257)
at 
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:210)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:337)
Caused by: java.lang.NullPointerException
at java.nio.ByteBuffer.wrap(ByteBuffer.java:373)
at 
org.apache.cassandra.cli.CliClient.loadCql3DefsUnchecked(CliClient.java:361)
at org.apache.cassandra.cli.CliClient.loadCql3Defs(CliClient.java:335)
... 5 more
[default@myspace] 
{code}

 cassandra-cli java.lang.NullPointerException for almost any commands
 

 Key: CASSANDRA-5295
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 
 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
  Labels: cassandra-cli

 {code}
 cassandra-cli -v -h srv1 -p 9160 
 Connected to: myspace on srv1/9160
 Welcome to Cassandra CLI version 1.2.1
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 [default@unknown] use myspace;
 java.lang.NullPointerException
 [default@myspace] describe;
 java.lang.NullPointerException
 [default@myspace] list mycf1;
 null
 [default@myspace]  
 {code}
 and nothing in system.log or output.log
 which information can i provide to speed up cause determination?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Trivial Update of CarleyN05 by CarleyN05

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The CarleyN05 page has been changed by CarleyN05:
http://wiki.apache.org/cassandra/CarleyN05

New page:
Yo bros !! I am VALENCIA KNOX. I am staying at Plano.BR
I am turning 43. I am self employed as a Hydraulic Engineer. My father name is 
Robert  and he is a Rat-catcher. My mom is a Party-leader.BR
BR
Feel free to surf to my webpage: [[http://www.majorguccioutlet.com|gucci 
bellts]]

[7/7] git commit: Merge branch 'cassandra-1.2' into trunk

Updated Branches:
  refs/heads/cassandra-1.1 05709f74e - aba9a1774
  refs/heads/cassandra-1.2 db7759a2c - 7e1e07676
  refs/heads/trunk c5f9ac87f - 327ae1247


Merge branch 'cassandra-1.2' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/327ae124
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/327ae124
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/327ae124

Branch: refs/heads/trunk
Commit: 327ae1247ae395c977095a5ba54acf6ec9b92145
Parents: c5f9ac8 7e1e076
Author: Brandon Williams bran...@datastax.com
Authored: Wed Feb 27 10:38:12 2013 -0600
Committer: Brandon Williams bran...@datastax.com
Committed: Wed Feb 27 10:38:12 2013 -0600

--
 CHANGES.txt|1 +
 NEWS.txt   |   18 +++
 .../apache/cassandra/cql3/PropertyDefinitions.java |7 +-
 .../apache/cassandra/service/MigrationManager.java |1 -
 4 files changed, 20 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/327ae124/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/327ae124/src/java/org/apache/cassandra/service/MigrationManager.java
--

[6/7] git commit: Merge branch 'cassandra-1.1' into cassandra-1.2

Merge branch 'cassandra-1.1' into cassandra-1.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7e1e0767
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7e1e0767
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7e1e0767

Branch: refs/heads/cassandra-1.2
Commit: 7e1e07676ebd66390aa9388cf456827d9b16e941
Parents: db7759a aba9a17
Author: Brandon Williams bran...@datastax.com
Authored: Wed Feb 27 10:37:59 2013 -0600
Committer: Brandon Williams bran...@datastax.com
Committed: Wed Feb 27 10:37:59 2013 -0600

--
 .../apache/cassandra/service/MigrationManager.java |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e1e0767/src/java/org/apache/cassandra/service/MigrationManager.java
--

[5/7] git commit: Merge branch 'cassandra-1.1' into cassandra-1.2

Merge branch 'cassandra-1.1' into cassandra-1.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7e1e0767
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7e1e0767
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7e1e0767

Branch: refs/heads/trunk
Commit: 7e1e07676ebd66390aa9388cf456827d9b16e941
Parents: db7759a aba9a17
Author: Brandon Williams bran...@datastax.com
Authored: Wed Feb 27 10:37:59 2013 -0600
Committer: Brandon Williams bran...@datastax.com
Committed: Wed Feb 27 10:37:59 2013 -0600

--
 .../apache/cassandra/service/MigrationManager.java |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/7e1e0767/src/java/org/apache/cassandra/service/MigrationManager.java
--

[4/7] git commit: Remove assertion that gossip is active in migration manager. Patch by brandonwilliams, reviewed by iamaleksey for CASSANDRA-5236

Remove assertion that gossip is active in migration manager.
Patch by brandonwilliams, reviewed by iamaleksey for CASSANDRA-5236


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/aba9a177
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/aba9a177
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/aba9a177

Branch: refs/heads/cassandra-1.2
Commit: aba9a17742ff6fd6fec2a355d7d7cce68fd06f04
Parents: 05709f7
Author: Brandon Williams bran...@datastax.com
Authored: Wed Feb 27 10:37:14 2013 -0600
Committer: Brandon Williams bran...@datastax.com
Committed: Wed Feb 27 10:37:14 2013 -0600

--
 .../apache/cassandra/service/MigrationManager.java |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/aba9a177/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index 9a82517..49e0c93 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -277,7 +277,6 @@ public class MigrationManager implements 
IEndpointStateChangeSubscriber
  */
 public static void passiveAnnounce(UUID version)
 {
-assert Gossiper.instance.isEnabled();
 Gossiper.instance.addLocalApplicationState(ApplicationState.SCHEMA, 
StorageService.instance.valueFactory.schema(version));
 logger.debug(Gossiping my schema version  + version);
 }

[3/7] git commit: Remove assertion that gossip is active in migration manager. Patch by brandonwilliams, reviewed by iamaleksey for CASSANDRA-5236

Remove assertion that gossip is active in migration manager.
Patch by brandonwilliams, reviewed by iamaleksey for CASSANDRA-5236


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/aba9a177
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/aba9a177
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/aba9a177

Branch: refs/heads/trunk
Commit: aba9a17742ff6fd6fec2a355d7d7cce68fd06f04
Parents: 05709f7
Author: Brandon Williams bran...@datastax.com
Authored: Wed Feb 27 10:37:14 2013 -0600
Committer: Brandon Williams bran...@datastax.com
Committed: Wed Feb 27 10:37:14 2013 -0600

--
 .../apache/cassandra/service/MigrationManager.java |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/aba9a177/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index 9a82517..49e0c93 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -277,7 +277,6 @@ public class MigrationManager implements 
IEndpointStateChangeSubscriber
  */
 public static void passiveAnnounce(UUID version)
 {
-assert Gossiper.instance.isEnabled();
 Gossiper.instance.addLocalApplicationState(ApplicationState.SCHEMA, 
StorageService.instance.valueFactory.schema(version));
 logger.debug(Gossiping my schema version  + version);
 }

[1/7] git commit: CQL3 shouldn't lowercase DC names for NTS

CQL3 shouldn't lowercase DC names for NTS

patch by slebresne; reviewed by jbellis for CASSANDRA-5292


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/db7759a2
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/db7759a2
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/db7759a2

Branch: refs/heads/trunk
Commit: db7759a2cac76d86a9f5b1ca82f7e08cc358c28d
Parents: a416649
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Wed Feb 27 15:43:24 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Wed Feb 27 15:46:17 2013 +0100

--
 CHANGES.txt|1 +
 NEWS.txt   |   18 +++
 .../apache/cassandra/cql3/PropertyDefinitions.java |7 +-
 3 files changed, 20 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/db7759a2/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b19b092..85e283a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 1.2.3
  * Avoid allocating SSTableBoundedScanner during repair when the range does 
not intersect the sstable (CASSANDRA-5249)
+ * Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292)
 Merged from 1.1:
  * nodetool: ability to repair specific range (CASSANDRA-5280)
  * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/db7759a2/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 5b4f478..01db820 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -8,6 +8,24 @@ upgrade, just in case you need to roll back to the previous 
version.
 (Cassandra version X + 1 will always be able to read data files created
 by version X, but the inverse is not necessarily the case.)
 
+1.2.3
+=
+
+Upgrading
+-
+- CQL3 uses to be case-insensitive for property map key in ALTER and CREATE
+  statements. In other words:
+CREATE KEYSPACE test WITH replication = { 'CLASS' : 'SimpleStrategy',
+  'REPLICATION_FACTOR' : '1' }
+  was allowed. However, this was not consistent with the fact that string
+  literal are case sensitive in every other places and more importantly 
this
+  break NetworkTopologyStrategy for which DC names are case sensitive. 
Those
+  property map key are now case sensitive. So the statement above should be
+  changed to:
+CREATE KEYSPACE test WITH replication = { 'class' : 'SimpleStrategy',
+  'replication_factor' : '1' }
+
+
 1.2.2
 =
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/db7759a2/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java
--
diff --git a/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java 
b/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java
index 3db84fa..ba83e45 100644
--- a/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java
+++ b/src/java/org/apache/cassandra/cql3/PropertyDefinitions.java
@@ -38,12 +38,7 @@ public class PropertyDefinitions
 
 public void addProperty(String name, MapString, String value) throws 
SyntaxException
 {
-// Lowercase the map keys to be nice to users
-MapString, String lowerCased = new HashMapString, 
String(value.size());
-for (Map.EntryString, String entry : value.entrySet())
-lowerCased.put(entry.getKey().toLowerCase(), entry.getValue());
-
-if (properties.put(name, lowerCased) != null)
+if (properties.put(name, value) != null)
 throw new SyntaxException(String.format(Multiple definition for 
property '%s', name));
 }

[2/7] git commit: Remove assertion that gossip is active in migration manager. Patch by brandonwilliams, reviewed by iamaleksey for CASSANDRA-5236

Remove assertion that gossip is active in migration manager.
Patch by brandonwilliams, reviewed by iamaleksey for CASSANDRA-5236


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/aba9a177
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/aba9a177
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/aba9a177

Branch: refs/heads/cassandra-1.1
Commit: aba9a17742ff6fd6fec2a355d7d7cce68fd06f04
Parents: 05709f7
Author: Brandon Williams bran...@datastax.com
Authored: Wed Feb 27 10:37:14 2013 -0600
Committer: Brandon Williams bran...@datastax.com
Committed: Wed Feb 27 10:37:14 2013 -0600

--
 .../apache/cassandra/service/MigrationManager.java |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/aba9a177/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index 9a82517..49e0c93 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -277,7 +277,6 @@ public class MigrationManager implements 
IEndpointStateChangeSubscriber
  */
 public static void passiveAnnounce(UUID version)
 {
-assert Gossiper.instance.isEnabled();
 Gossiper.instance.addLocalApplicationState(ApplicationState.SCHEMA, 
StorageService.instance.valueFactory.schema(version));
 logger.debug(Gossiping my schema version  + version);
 }

[jira] [Commented] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands

2013-02-27 Thread Brandon Williams (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588491#comment-13588491
 ] 

Brandon Williams commented on CASSANDRA-5295:
-

Are you possibly mixing cli and cassandra versions?

 cassandra-cli java.lang.NullPointerException for almost any commands
 

 Key: CASSANDRA-5295
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 
 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
  Labels: cassandra-cli

 {code}
 cassandra-cli -v -h srv1 -p 9160 
 Connected to: myspace on srv1/9160
 Welcome to Cassandra CLI version 1.2.1
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 [default@unknown] use myspace;
 java.lang.NullPointerException
 [default@myspace] describe;
 java.lang.NullPointerException
 [default@myspace] list mycf1;
 null
 [default@myspace]  
 {code}
 and nothing in system.log or output.log
 which information can i provide to speed up cause determination?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-5297) sstableloader's interface could be improved

2013-02-27 Thread Brandon Williams (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams resolved CASSANDRA-5297.
-

Resolution: Not A Problem

I think you're speaking about the 1.0 sstableloader.  These things were mostly 
solved in 1.1 (for instance there's no need to play the loopback game any 
longer.)

 sstableloader's interface could be improved
 ---

 Key: CASSANDRA-5297
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5297
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Dan Peebles
Priority: Minor

 According to 
 http://stackoverflow.com/questions/6832285/how-do-you-use-the-cassandra-tool-sstableloader
  and other references, it looks like running sstableloader in many cases 
 necessitates duplicating (a subset of) the destination node's Cassandra 
 install folder. This is primarily to have the right cassandra.yaml in the 
 right place, as far as I can see.
 It seems like it would be much less of a pain to use the bulk loader if it 
 took a parameter for where to look for cassandra.yaml (or supported the 
 individual settings it needed to gossip correctly directly on command line)
 The whole business about making a duplicate loopback interface also seems a 
 bit Byzantine.
 Since the command-line tool appears just to be a fairly thin wrapper around 
 code that is used elsewhere in Cassandra, disentangling it from the standard 
 Cassandra configuration might be fairly difficult. But then again I'm pretty 
 clueless so I'd be happy to be corrected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-02-27 Thread Sergio Bossa (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588504#comment-13588504
 ] 

Sergio Bossa commented on CASSANDRA-5062:
-

[~jbellis]:

{quote}if the leader reports success to the client after local commit, but 
before it has been committed to the followers, we could either (1) lose the 
commit on failover if followers are pessimistic, or (2) commit data that we 
originally reported failed{quote}

Nope, once the commit is reported as successful, even if still not acked, it 
will be always seen by clients because:
1) If the leader fails, the failed over one is guaranteed to see up to the 
latest (proposed or committed) value, because that's the way it is elected.
2) The only case when a commit can fail happens when the prepare phase doesn't 
get a quorum, but in this case the leader will have to retry until it gets it, 
times out or fails; last two options do not mean to the client the commit has 
failed, just that it has to retry (I think the same would be with Paxos, as the 
client is never part of the consensus).

This is really Zab/ZK by the way, I'm not adding much to it :)

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

buildbot success in ASF Buildbot on cassandra-trunk

2013-02-27 Thread buildbot

The Buildbot has detected a restored build on builder cassandra-trunk while 
building cassandra.
Full details are available at:
 http://ci.apache.org/builders/cassandra-trunk/builds/2379

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: portunus_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch trunk] 327ae1247ae395c977095a5ba54acf6ec9b92145
Blamelist: Brandon Williams bran...@datastax.com,Sylvain Lebresne 
sylv...@datastax.com

Build succeeded!

sincerely,
 -The Buildbot

[jira] [Commented] (CASSANDRA-5241) Fix forceBlockingFlush

2013-02-27 Thread Marcus Eriksson (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588511#comment-13588511
 ] 

Marcus Eriksson commented on CASSANDRA-5241:


i've run this and 5151 for a week or so with production traffic without seeing 
the issue, [~mkjellman], have you tried running more with these patches?

 Fix forceBlockingFlush
 --

 Key: CASSANDRA-5241
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5241
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Marcus Eriksson
 Fix For: 1.2.2

 Attachments: 
 0001-CASSANDRA-5241-wait-for-flushing-to-complete-before-.patch


 ForceBlockingFlush doesn't guarantee that after the call, every that the 
 thread has written prior to the call will be fully flushed. At least not in 
 the case of concurrent flushes, because if 2 threads flush roughly at the 
 same time, one will have it's forceBlockingFlush call return immediately 
 because the memtable will be clean (even though some of the thread writes may 
 have not be fully flushed yet).
 I think this is very fragile and make it easy to have hard to find races and 
 so we should fix it. Typically a forceFlush that see a clean memtable could 
 submit a dummy task in the postFlushExecutor and wait for that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588521#comment-13588521
 ] 

Cristian Opris commented on CASSANDRA-5062:
---

The Zab paper: research.yahoo.com/files/ladis08.pdf

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5062) Support CAS


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588521#comment-13588521
 ] 

Cristian Opris edited comment on CASSANDRA-5062 at 2/27/13 5:12 PM:


The Zab paper: http://research.yahoo.com/files/ladis08.pdf

  was (Author: onetoinfin...@yahoo.com):
The Zab paper: research.yahoo.com/files/ladis08.pdf
  
 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5241) Fix forceBlockingFlush

2013-02-27 Thread Michael Kjellman (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588538#comment-13588538
 ] 

Michael Kjellman commented on CASSANDRA-5241:
-

[~krummas] I 100% needed to revert #5151 when running with this patch. Was 
triggered on a rolling restart for me.

 Fix forceBlockingFlush
 --

 Key: CASSANDRA-5241
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5241
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Marcus Eriksson
 Fix For: 1.2.2

 Attachments: 
 0001-CASSANDRA-5241-wait-for-flushing-to-complete-before-.patch


 ForceBlockingFlush doesn't guarantee that after the call, every that the 
 thread has written prior to the call will be fully flushed. At least not in 
 the case of concurrent flushes, because if 2 threads flush roughly at the 
 same time, one will have it's forceBlockingFlush call return immediately 
 because the memtable will be clean (even though some of the thread writes may 
 have not be fully flushed yet).
 I think this is very fragile and make it easy to have hard to find races and 
 so we should fix it. Typically a forceFlush that see a clean memtable could 
 submit a dummy task in the postFlushExecutor and wait for that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588542#comment-13588542
 ] 

Cristian Opris commented on CASSANDRA-5062:
---

In the Zab paper in 4.1 it says ??We are able to simplify the two-phase commit 
protocol because we do not have aborts; followers either acknowledge the 
leader’s proposal or they abandon the leader. *The lack of aborts also mean 
that we can commit once a quorum of servers ack the proposal rather than 
waiting for all servers to respond.* This simplified two- phase commit by 
itself cannot handle leader failures, so we will add recovery mode to handle 
leader failures.??

So basically one a proposal is acked by a quorum there is no going back (no 
abort). The leader has to succeed in committing that or else it will lose its 
leadership.

If the client times out in the meantime it has to retry and find out what the 
result was. Presumably this can happen with regular ACID databases as well, 
where a client sends COMMIT TX and times out immediately after that.

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5062) Support CAS


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588542#comment-13588542
 ] 

Cristian Opris edited comment on CASSANDRA-5062 at 2/27/13 5:32 PM:


In the Zab paper in 4.1 it says ??We are able to simplify the two-phase commit 
protocol because we do not have aborts; followers either acknowledge the 
leader’s proposal or they abandon the leader. *The lack of aborts also mean 
that we can commit once a quorum of servers ack the proposal rather than 
waiting for all servers to respond.* This simplified two- phase commit by 
itself cannot handle leader failures, so we will add recovery mode to handle 
leader failures.??

So basically once a proposal is acked by a quorum there is no going back (no 
abort). The leader has to succeed in committing that or else it will lose its 
leadership.

If the client times out in the meantime it has to retry and find out what the 
result was. Presumably this can happen with regular ACID databases as well, 
where a client sends COMMIT TX and times out immediately after that.

  was (Author: onetoinfin...@yahoo.com):
In the Zab paper in 4.1 it says ??We are able to simplify the two-phase 
commit protocol because we do not have aborts; followers either acknowledge the 
leader’s proposal or they abandon the leader. *The lack of aborts also mean 
that we can commit once a quorum of servers ack the proposal rather than 
waiting for all servers to respond.* This simplified two- phase commit by 
itself cannot handle leader failures, so we will add recovery mode to handle 
leader failures.??

So basically one a proposal is acked by a quorum there is no going back (no 
abort). The leader has to succeed in committing that or else it will lose its 
leadership.

If the client times out in the meantime it has to retry and find out what the 
result was. Presumably this can happen with regular ACID databases as well, 
where a client sends COMMIT TX and times out immediately after that.
  
 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.

[
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588564#comment-13588564
]

Ryan McGuire commented on CASSANDRA-5120:
-

I have verified that Cassandra always reject a client certificate when
*require_client_auth = true*. It cannot verify a key that it does not know
about. If there is currently a way of installing my client certificate on the
server, I am not aware of it.

To verify this behaviour, I created my own example SSL server using stunnel so
that I could see how this would work with a server that does accept client
certificates. stunnel has the option to verify client certificates with it's
verify=3 option:

{code}
cert = server.pem
setuid = ryan
pid = /tmp/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
verify = 3
CAfile = certs/myca.crt
CApath = /home/ryan/stunnel_keys/acceptable
foreground = yes
debug = 7

[ryan]
accept =
connect = 127.0.0.1:9998
{code}

I can connect to this example server using OpenSSL's client:

{code}
openssl s_client -connect 127.0.0.1: -cert client.pem
{code}

With the certificate it connects, without it it doesn't.

The same command on port 9160 can be used to connect to Cassandra over SSL with
client certificate. With *require_client_auth=false*, the connection is always
allowed whether I use a client certificate or not. With
*require_client_auth=true* the connection is always terminated, regardless if I
specify a client certificate because the server does not know about my
certificate.

If Cassandra were to know about my certificate, I suspect this would work.

Add support for SSL sockets to use client certificate authentication.
-

Key: CASSANDRA-5120
URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Steven Franklin
Priority: Minor
Fix For: 1.2.1

Attachments: trunk-5120.txt

Add an option to EncryptionOptions to require client certication
authentication.

[jira] [Comment Edited] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588564#comment-13588564
 ] 

Ryan McGuire edited comment on CASSANDRA-5120 at 2/27/13 6:02 PM:
--

I have verified that Cassandra always rejects a client certificate when 
*require_client_auth = true*. It cannot verify a key that it does not know 
about. If there is currently a way of installing my client certificate on the 
server, I am not aware of it.

To verify this behaviour, I created my own example SSL server using stunnel so 
that I could see how this would work with a server that does accept client 
certificates. stunnel has the option to verify client certificates with it's 
verify=3 option:

{code}
cert = server.pem
setuid = ryan
pid = /tmp/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
verify = 3
CAfile = certs/myca.crt
CApath = /home/ryan/stunnel_keys/acceptable
foreground = yes
debug = 7

[ryan]
accept = 
connect = 127.0.0.1:9998
{code}

I can connect to this example server using OpenSSL's client:

{code}
openssl s_client -connect 127.0.0.1: -cert client.pem
{code}

With the certificate it connects, without it it doesn't.

The same command on port 9160 can be used to connect to Cassandra over SSL with 
client certificate. With *require_client_auth=false*, the connection is always 
allowed whether I use a client certificate or not. With 
*require_client_auth=true* the connection is always terminated, regardless if I 
specify a client certificate because the server does not know about my 
certificate.

If Cassandra were to know about my certificate, I suspect this would work.

  was (Author: enigmacurry):
I have verified that Cassandra always reject a client certificate when 
*require_client_auth = true*. It cannot verify a key that it does not know 
about. If there is currently a way of installing my client certificate on the 
server, I am not aware of it.

To verify this behaviour, I created my own example SSL server using stunnel so 
that I could see how this would work with a server that does accept client 
certificates. stunnel has the option to verify client certificates with it's 
verify=3 option:

{code}
cert = server.pem
setuid = ryan
pid = /tmp/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
verify = 3
CAfile = certs/myca.crt
CApath = /home/ryan/stunnel_keys/acceptable
foreground = yes
debug = 7

[ryan]
accept = 
connect = 127.0.0.1:9998
{code}

I can connect to this example server using OpenSSL's client:

{code}
openssl s_client -connect 127.0.0.1: -cert client.pem
{code}

With the certificate it connects, without it it doesn't.

The same command on port 9160 can be used to connect to Cassandra over SSL with 
client certificate. With *require_client_auth=false*, the connection is always 
allowed whether I use a client certificate or not. With 
*require_client_auth=true* the connection is always terminated, regardless if I 
specify a client certificate because the server does not know about my 
certificate.

If Cassandra were to know about my certificate, I suspect this would work.
  
 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Steven Franklin
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588564#comment-13588564
 ] 

Ryan McGuire edited comment on CASSANDRA-5120 at 2/27/13 6:06 PM:
--

I have verified that Cassandra always rejects a client connection when 
*require_client_auth = true*. It cannot verify a key that it does not know 
about. If there is currently a way of installing my client certificate on the 
server, I am not aware of it.

To verify this behaviour, I created my own example SSL server using stunnel so 
that I could see how this would work with a server that does accept client 
certificates. stunnel has the option to verify client certificates with it's 
verify=3 option:

{code}
cert = server.pem
setuid = ryan
pid = /tmp/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
verify = 3
CAfile = certs/myca.crt
CApath = /home/ryan/stunnel_keys/acceptable
foreground = yes
debug = 7

[ryan]
accept = 
connect = 127.0.0.1:9998
{code}

I can connect to this example server using OpenSSL's client:

{code}
openssl s_client -connect 127.0.0.1: -cert client.pem
{code}

With the certificate it connects, without it it doesn't.

The same command on port 9160 can be used to connect to Cassandra over SSL with 
client certificate. With *require_client_auth=false*, the connection is always 
allowed whether I use a client certificate or not. With 
*require_client_auth=true* the connection is always terminated, regardless if I 
specify a client certificate because the server does not know about my 
certificate.

If Cassandra were to know about my certificate, I suspect this would work.

  was (Author: enigmacurry):
I have verified that Cassandra always rejects a client certificate when 
*require_client_auth = true*. It cannot verify a key that it does not know 
about. If there is currently a way of installing my client certificate on the 
server, I am not aware of it.

To verify this behaviour, I created my own example SSL server using stunnel so 
that I could see how this would work with a server that does accept client 
certificates. stunnel has the option to verify client certificates with it's 
verify=3 option:

{code}
cert = server.pem
setuid = ryan
pid = /tmp/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
verify = 3
CAfile = certs/myca.crt
CApath = /home/ryan/stunnel_keys/acceptable
foreground = yes
debug = 7

[ryan]
accept = 
connect = 127.0.0.1:9998
{code}

I can connect to this example server using OpenSSL's client:

{code}
openssl s_client -connect 127.0.0.1: -cert client.pem
{code}

With the certificate it connects, without it it doesn't.

The same command on port 9160 can be used to connect to Cassandra over SSL with 
client certificate. With *require_client_auth=false*, the connection is always 
allowed whether I use a client certificate or not. With 
*require_client_auth=true* the connection is always terminated, regardless if I 
specify a client certificate because the server does not know about my 
certificate.

If Cassandra were to know about my certificate, I suspect this would work.
  
 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Steven Franklin
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588567#comment-13588567
]

Cristian Opris commented on CASSANDRA-5062:
---

Note that a proposal may eventually succeed on recovery even if a less than a
quorum has managed to ack it before the leader fails (and the client timed
out). The need for quorum writes is to be able to survive F failures out of
2F+1 replicas. Reads are not quorum, just replica local reads.

Let's say we have 5 replicas, F1 leader, F4 and F5 are ignored here as they
don't matter
{{
1a. F1 - proposal - F2
1b. F1 - ack - F2
2a. F1 - proposal - F3
2b. F1 - ack - F3
3a F1 - OK - client
3b F1 - COMMIT - F2,F3
}}

If F1 fails immediately after step 1b, F2 would become the leader since he has
the latest seq number. Now only F2 has the proposal but it can continue and
commit it to the other followers.
If it can't get a quorum (maybe it's partitioned in a minority) then it gives
up leadership. When it rejoins the majority, it runs another recovery procedure
that uses epoch numbers to determine if it needs to throw away that proposal.
This is fine since no client has actually been confirmed that the proposal has
been committed. This is detailed in the paper.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Commented] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588568#comment-13588568
 ] 

Aleksey Yeschenko commented on CASSANDRA-5120:
--

[~enigmacurry] Looks just like what we expected, thanks for verifying it. I'll 
attach a patch that sets the keystore (ONLY if require_client_auth = true, so 
that it won't disappoint users upgrading from 1.2.0/1).

 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Steven Franklin
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588567#comment-13588567
]

Cristian Opris edited comment on CASSANDRA-5062 at 2/27/13 6:09 PM:

Let's say we have 5 replicas, F1 leader, F4 and F5 are ignored here as they
don't matter
{code}
1a F1 - proposal - F2
1b F1 - ack - F2
2a F1 - proposal - F3
2b F1 - ack - F3
3a F1 - OK - client
3b F1 - COMMIT - F2,F3
{code}

was (Author: onetoinfin...@yahoo.com):
Note that a proposal may eventually succeed on recovery even if a less than
a quorum has managed to ack it before the leader fails (and the client timed
out). The need for quorum writes is to be able to survive F failures out of
2F+1 replicas. Reads are not quorum, just replica local reads.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Assigned] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko reassigned CASSANDRA-5120:


Assignee: Aleksey Yeschenko  (was: Steven Franklin)

 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588596#comment-13588596
]

Sylvain Lebresne commented on CASSANDRA-5062:
-

Let me first say that as far as I'm concerned, the priorities for this ticket
should be:
# correctness (as in, it would be nice not to spend the next 4 years fixing
corner cases).
# an implementation that doesn't make Cassandra's code some Frankenstein
monster.

You'll note that being fast is not on this list. That doesn't mean I don't care
about fast, all other things being equal, faster is better. But I don't think
we're targeting heavy use of conflicting CAS, not at first at least. The
typical use case we're targeting initially is the one described by Jonathan,
the unique user account creation problem. In that use case, 1) your application
probably don't do much user creation check (comparated to the overall cluster
load at least) and 2) it's fairly easy to partition the problem so that your
CAS will rarely conflict (so Paxos failing at liveness is not a huge concern).

All that to say that I'd rather start with something as simple as possible, and
consider optimisations later (as Jonathan said, if we expose this as a CAS, we
can switch the implementation later if need be).

Now, for our use case, I do believe Paxos without optimisation (that does mean
one complete paxos per-CAS) is simpler than Zab (to be honest, I haven't look
that much at Zab, but what I've seen does seem more complicated in practice).
I'm aware of papers like
http://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/paper2-1.pdf but their
main difficulties are due to 1) multi-paxos (not what I'm suggesting) and 2)
replicated log grow (it's difficult for them for reasons that don't apply to us
(we fully control the data to which the replicated log applies)). Could be that
I'm over-optimistic but...

Anyway, all that to say that I'm going to give a shot at prototyping a version
with a simple Paxos. I've tried to detail a concrete implementation a bit on
paper and that doesn't sound too bad, we'll see. But feel free to give a shot
to Zab and see how that goes :)

That does lead me to a more mundane problem: how do we expose a CAS in CQL3
(thrift is simpler as it happens)?

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[6/7] git commit: changelog

changelog


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/33ce1e35
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/33ce1e35
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/33ce1e35

Branch: refs/heads/cassandra-1.2
Commit: 33ce1e35f21e19cb3056862d0c0c6d463993d103
Parents: 6d3002f
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Feb 27 12:33:58 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Feb 27 12:33:58 2013 -0600

--
 CHANGES.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/33ce1e35/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 85e283a..4a7dd1a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,7 @@ Merged from 1.1:
  * nodetool: ability to repair specific range (CASSANDRA-5280)
  * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
 
+
 1.2.2
  * fix potential for multiple concurrent compactions of the same sstables
(CASSANDRA-5256)

[5/7] git commit: changelog

changelog


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/33ce1e35
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/33ce1e35
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/33ce1e35

Branch: refs/heads/trunk
Commit: 33ce1e35f21e19cb3056862d0c0c6d463993d103
Parents: 6d3002f
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Feb 27 12:33:58 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Feb 27 12:33:58 2013 -0600

--
 CHANGES.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/33ce1e35/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 85e283a..4a7dd1a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,7 @@ Merged from 1.1:
  * nodetool: ability to repair specific range (CASSANDRA-5280)
  * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
 
+
 1.2.2
  * fix potential for multiple concurrent compactions of the same sstables
(CASSANDRA-5256)

[4/7] git commit: changelog

changelog


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b13e77d3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b13e77d3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b13e77d3

Branch: refs/heads/trunk
Commit: b13e77d33c69b53c42aa76e28d3cac2d079914ed
Parents: a34ea8b
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Feb 27 12:33:46 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Feb 27 12:33:46 2013 -0600

--
 CHANGES.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b13e77d3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 370b4f8..0ea6738 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -11,6 +11,7 @@
  * more robust solution to incomplete compactions + counters (CASSANDRA-5151)
  * Change order of directory searching for c*.in.sh (CASSANDRA-3983)
 
+
 1.2.3
  * Avoid allocating SSTableBoundedScanner during repair when the range does 
not intersect the sstable (CASSANDRA-5249)

[7/7] git commit: Merge branch 'cassandra-1.2' into trunk

Updated Branches:
  refs/heads/cassandra-1.2 7e1e07676 - 33ce1e35f
  refs/heads/trunk 327ae1247 - 73e8cb62f


Merge branch 'cassandra-1.2' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/73e8cb62
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/73e8cb62
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/73e8cb62

Branch: refs/heads/trunk
Commit: 73e8cb62f1d5597cabad2c756d898d0fd5826c1a
Parents: b13e77d 33ce1e3
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Feb 27 12:34:08 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Feb 27 12:34:08 2013 -0600

--
 CHANGES.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/73e8cb62/CHANGES.txt
--

[3/7] git commit: Merge branch 'cassandra-1.2' into trunk

Merge branch 'cassandra-1.2' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a34ea8bf
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a34ea8bf
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a34ea8bf

Branch: refs/heads/trunk
Commit: a34ea8bfd290530c1fedc81b993ae59b2fe3e560
Parents: 327ae12 6d3002f
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Feb 27 12:33:28 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Feb 27 12:33:28 2013 -0600

--
 .../apache/cassandra/service/StorageService.java   |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a34ea8bf/src/java/org/apache/cassandra/service/StorageService.java
--

[1/7] git commit: use systemKeyspaceNames instead of hardcoding system + trace

use systemKeyspaceNames instead of hardcoding system + trace


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6d3002fe
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6d3002fe
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6d3002fe

Branch: refs/heads/cassandra-1.2
Commit: 6d3002fecb5c84a99b1110d49257021491e10e67
Parents: 7e1e076
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Feb 27 12:33:16 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Feb 27 12:33:22 2013 -0600

--
 .../apache/cassandra/service/StorageService.java   |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d3002fe/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 11ae98b..dfd948d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2364,7 +2364,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 
 public void forceTableRepairRange(final String tableName, final 
CollectionRangeToken ranges, boolean isSequential, boolean  isLocal, final 
String... columnFamilies) throws IOException
 {
-if (Table.SYSTEM_KS.equals(tableName) || 
Tracing.TRACE_KS.equals(tableName))
+if (Schema.systemKeyspaceNames.contains(tableName))
 return;
 createRepairTask(nextRepairCommand.incrementAndGet(), tableName, 
ranges, isSequential, isLocal, columnFamilies).run();
 }

[2/7] git commit: use systemKeyspaceNames instead of hardcoding system + trace

use systemKeyspaceNames instead of hardcoding system + trace


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6d3002fe
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6d3002fe
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6d3002fe

Branch: refs/heads/trunk
Commit: 6d3002fecb5c84a99b1110d49257021491e10e67
Parents: 7e1e076
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Feb 27 12:33:16 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Feb 27 12:33:22 2013 -0600

--
 .../apache/cassandra/service/StorageService.java   |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d3002fe/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 11ae98b..dfd948d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2364,7 +2364,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 
 public void forceTableRepairRange(final String tableName, final 
CollectionRangeToken ranges, boolean isSequential, boolean  isLocal, final 
String... columnFamilies) throws IOException
 {
-if (Table.SYSTEM_KS.equals(tableName) || 
Tracing.TRACE_KS.equals(tableName))
+if (Schema.systemKeyspaceNames.contains(tableName))
 return;
 createRepairTask(nextRepairCommand.incrementAndGet(), tableName, 
ranges, isSequential, isLocal, columnFamilies).run();
 }

[jira] [Commented] (CASSANDRA-5287) Composite comparators for super CFs broken in 1.2

2013-02-27 Thread Tyler Hobbs (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588608#comment-13588608
 ] 

Tyler Hobbs commented on CASSANDRA-5287:


Is the patch supposed to be against the 1.2 branch? It doesn't compile there.

 Composite comparators for super CFs broken in 1.2
 -

 Key: CASSANDRA-5287
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5287
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
 Fix For: 1.2.3

 Attachments: 5287-pycassa-repro.py, 5287.txt


 In Cassandra 1.2.0 through 1.2.2, attempting to insert data into a super 
 column family with a CompositeType comparator results in the following 
 stacktrace:
 {noformat}
 ERROR 14:56:49,920 Error occurred during processing of message.
 java.lang.IllegalArgumentException
   at java.nio.Buffer.limit(Buffer.java:249)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:51)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:60)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:126)
   at 
 org.apache.cassandra.config.CFMetaData.getColumnDefinitionFromColumnName(CFMetaData.java:920)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnData(ThriftValidation.java:404)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnOrSuperColumn(ThriftValidation.java:287)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateMutation(ThriftValidation.java:343)
   at 
 org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:704)
   at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:752)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3622)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3610)
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
   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)
 {noformat}
 Client-side, you'll just see {{TTransportException: TSocket read 0 bytes}}.
 Cassandra 1.1 doesn't have the same problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5287) Composite comparators for super CFs broken in 1.2


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-5287:


Attachment: (was: 5287.txt)

 Composite comparators for super CFs broken in 1.2
 -

 Key: CASSANDRA-5287
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5287
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
 Fix For: 1.2.3

 Attachments: 5287-pycassa-repro.py, 5287.txt


 In Cassandra 1.2.0 through 1.2.2, attempting to insert data into a super 
 column family with a CompositeType comparator results in the following 
 stacktrace:
 {noformat}
 ERROR 14:56:49,920 Error occurred during processing of message.
 java.lang.IllegalArgumentException
   at java.nio.Buffer.limit(Buffer.java:249)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:51)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:60)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:126)
   at 
 org.apache.cassandra.config.CFMetaData.getColumnDefinitionFromColumnName(CFMetaData.java:920)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnData(ThriftValidation.java:404)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnOrSuperColumn(ThriftValidation.java:287)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateMutation(ThriftValidation.java:343)
   at 
 org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:704)
   at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:752)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3622)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3610)
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
   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)
 {noformat}
 Client-side, you'll just see {{TTransportException: TSocket read 0 bytes}}.
 Cassandra 1.1 doesn't have the same problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5287) Composite comparators for super CFs broken in 1.2


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-5287:


Attachment: 5287.txt

 Composite comparators for super CFs broken in 1.2
 -

 Key: CASSANDRA-5287
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5287
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
 Fix For: 1.2.3

 Attachments: 5287-pycassa-repro.py, 5287.txt


 In Cassandra 1.2.0 through 1.2.2, attempting to insert data into a super 
 column family with a CompositeType comparator results in the following 
 stacktrace:
 {noformat}
 ERROR 14:56:49,920 Error occurred during processing of message.
 java.lang.IllegalArgumentException
   at java.nio.Buffer.limit(Buffer.java:249)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:51)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:60)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:126)
   at 
 org.apache.cassandra.config.CFMetaData.getColumnDefinitionFromColumnName(CFMetaData.java:920)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnData(ThriftValidation.java:404)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnOrSuperColumn(ThriftValidation.java:287)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateMutation(ThriftValidation.java:343)
   at 
 org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:704)
   at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:752)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3622)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3610)
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
   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)
 {noformat}
 Client-side, you'll just see {{TTransportException: TSocket read 0 bytes}}.
 Cassandra 1.1 doesn't have the same problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5287) Composite comparators for super CFs broken in 1.2


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588619#comment-13588619
 ] 

Sylvain Lebresne commented on CASSANDRA-5287:
-

Hum, that's what you get for not even compiling before attaching a patch I 
suppose. The newly attached version should work better. 

 Composite comparators for super CFs broken in 1.2
 -

 Key: CASSANDRA-5287
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5287
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
 Fix For: 1.2.3

 Attachments: 5287-pycassa-repro.py, 5287.txt


 In Cassandra 1.2.0 through 1.2.2, attempting to insert data into a super 
 column family with a CompositeType comparator results in the following 
 stacktrace:
 {noformat}
 ERROR 14:56:49,920 Error occurred during processing of message.
 java.lang.IllegalArgumentException
   at java.nio.Buffer.limit(Buffer.java:249)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:51)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:60)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:126)
   at 
 org.apache.cassandra.config.CFMetaData.getColumnDefinitionFromColumnName(CFMetaData.java:920)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnData(ThriftValidation.java:404)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnOrSuperColumn(ThriftValidation.java:287)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateMutation(ThriftValidation.java:343)
   at 
 org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:704)
   at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:752)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3622)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3610)
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
   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)
 {noformat}
 Client-side, you'll just see {{TTransportException: TSocket read 0 bytes}}.
 Cassandra 1.1 doesn't have the same problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5287) Composite comparators for super CFs broken in 1.2

2013-02-27 Thread Tyler Hobbs (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588665#comment-13588665
 ] 

Tyler Hobbs commented on CASSANDRA-5287:


The patch seems fine to me, but I'm not terribly familiar with this area of the 
code.  With it applied, all of the pycassa and phpcassa tests pass, and they 
cover this pretty well.

 Composite comparators for super CFs broken in 1.2
 -

 Key: CASSANDRA-5287
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5287
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
 Fix For: 1.2.3

 Attachments: 5287-pycassa-repro.py, 5287.txt


 In Cassandra 1.2.0 through 1.2.2, attempting to insert data into a super 
 column family with a CompositeType comparator results in the following 
 stacktrace:
 {noformat}
 ERROR 14:56:49,920 Error occurred during processing of message.
 java.lang.IllegalArgumentException
   at java.nio.Buffer.limit(Buffer.java:249)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:51)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:60)
   at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:126)
   at 
 org.apache.cassandra.config.CFMetaData.getColumnDefinitionFromColumnName(CFMetaData.java:920)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnData(ThriftValidation.java:404)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateColumnOrSuperColumn(ThriftValidation.java:287)
   at 
 org.apache.cassandra.thrift.ThriftValidation.validateMutation(ThriftValidation.java:343)
   at 
 org.apache.cassandra.thrift.CassandraServer.createMutationList(CassandraServer.java:704)
   at 
 org.apache.cassandra.thrift.CassandraServer.batch_mutate(CassandraServer.java:752)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3622)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$batch_mutate.getResult(Cassandra.java:3610)
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
   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)
 {noformat}
 Client-side, you'll just see {{TTransportException: TSocket read 0 bytes}}.
 Cassandra 1.1 doesn't have the same problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-02-27 Thread Jun Rao (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588668#comment-13588668
]

Jun Rao commented on CASSANDRA-5062:

To support things like CAS, the easiest way is for all writes to go to a leader
replica that orders all incoming writes. There are different approaches for the
leader to commit data. One approach is the quorum-based one used in Paxos, ZK
and Spinnaker. The advantage of this approach is that it can hide the latency
of a slow replica. The disadvantage is that for 2f+1 replicas, it only
tolerates f failures (instead of 2f failures). While this is ok for ZK since it
only stores state info, it's probably not ideal for systems that store real
data. For that reason, in Kafka, we designed a slightly different approach for
maintaining strongly consistent replicas. The details can be found in the
ApacheCon presentation that I gave yesterday
(http://www.slideshare.net/junrao/kafka-replication-apachecon2013). The Kafka
design doesn't do paxos, but depends on ZK for leader election. So, the
implementation is a bit simpler than that used in Spinnaker.

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Commented] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588706#comment-13588706
 ] 

Pavel Trukhanov commented on CASSANDRA-5295:


checked:
{code}$ dpkg -l cassandra 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Description
+++---
ii  cassandra1.2.1distributed 
storage system for structured data
{code}

{code}
$ cassandra-cli -v -h srv2
Connected to: okmeter on srv2/9160
Welcome to Cassandra CLI version 1.2.1
{code}


 cassandra-cli java.lang.NullPointerException for almost any commands
 

 Key: CASSANDRA-5295
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 
 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
  Labels: cassandra-cli

 {code}
 cassandra-cli -v -h srv1 -p 9160 
 Connected to: myspace on srv1/9160
 Welcome to Cassandra CLI version 1.2.1
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 [default@unknown] use myspace;
 java.lang.NullPointerException
 [default@myspace] describe;
 java.lang.NullPointerException
 [default@myspace] list mycf1;
 null
 [default@myspace]  
 {code}
 and nothing in system.log or output.log
 which information can i provide to speed up cause determination?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5295) cassandra-cli java.lang.NullPointerException for almost any commands


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588706#comment-13588706
 ] 

Pavel Trukhanov edited comment on CASSANDRA-5295 at 2/27/13 8:11 PM:
-

checked:
{code}$ dpkg -l cassandra 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Description
+++---
ii  cassandra1.2.1distributed 
storage system for structured data
{code}

{code}
$ cassandra-cli -v -h srv2
Connected to: ccc on srv2/9160
Welcome to Cassandra CLI version 1.2.1
{code}


  was (Author: pavel.trukhanov):
checked:
{code}$ dpkg -l cassandra 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Description
+++---
ii  cassandra1.2.1distributed 
storage system for structured data
{code}

{code}
$ cassandra-cli -v -h srv2
Connected to: okmeter on srv2/9160
Welcome to Cassandra CLI version 1.2.1
{code}

  
 cassandra-cli java.lang.NullPointerException for almost any commands
 

 Key: CASSANDRA-5295
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5295
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Linux srv1 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 
 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Pavel Trukhanov
  Labels: cassandra-cli

 {code}
 cassandra-cli -v -h srv1 -p 9160 
 Connected to: myspace on srv1/9160
 Welcome to Cassandra CLI version 1.2.1
 Type 'help;' or '?' for help.
 Type 'quit;' or 'exit;' to quit.
 [default@unknown] use myspace;
 java.lang.NullPointerException
 [default@myspace] describe;
 java.lang.NullPointerException
 [default@myspace] list mycf1;
 null
 [default@myspace]  
 {code}
 and nothing in system.log or output.log
 which information can i provide to speed up cause determination?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588731#comment-13588731
 ] 

Aleksey Yeschenko commented on CASSANDRA-5120:
--

[~enigmacurry] Can you try the same with 
https://github.com/iamaleksey/cassandra/compare/5120 ?

 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588784#comment-13588784
 ] 

Ryan McGuire commented on CASSANDRA-5120:
-

Yes it does!

I took the same key I used prior and imported it into a new trustsstore file, 
configured the *truststore* and *truststore_password* options in the yaml and 
was able to make a connection. I tested with another key that I did not import 
and the connections was terminated. I tried connecting without any key and the 
connection was terminated.

 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588784#comment-13588784
 ] 

Ryan McGuire edited comment on CASSANDRA-5120 at 2/27/13 9:27 PM:
--

Yes it works!

I took the same key I used prior and imported it into a new trustsstore file, 
configured the *truststore* and *truststore_password* options in the yaml and 
was able to make a connection. I tested with another key that I did not import 
and the connections was terminated. I tried connecting without any key and the 
connection was terminated.

  was (Author: enigmacurry):
Yes it does!

I took the same key I used prior and imported it into a new trustsstore file, 
configured the *truststore* and *truststore_password* options in the yaml and 
was able to make a connection. I tested with another key that I did not import 
and the connections was terminated. I tried connecting without any key and the 
connection was terminated.
  
 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Trivial Update of MilagrosC by MilagrosC

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The MilagrosC page has been changed by MilagrosC:
http://wiki.apache.org/cassandra/MilagrosC

New page:
Yo guys !! I am DORENE PAGE. I belong to Santa Barbara.BR
I am self employed as a Captain. My hobby is Stamps. My father name is Bruce   
and he is a Intelligence Officer. My momy is a Zoologist.BR
BR
Here is my homepage: [[http://dynamiclouisvuittonoutlet.webs.com|lv bags]]

[jira] [Commented] (CASSANDRA-5062) Support CAS


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588819#comment-13588819
 ] 

Jonathan Ellis commented on CASSANDRA-5062:
---

Thanks, Jun!

 Support CAS
 ---

 Key: CASSANDRA-5062
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
 Fix For: 2.0


 Strong consistency is not enough to prevent race conditions.  The classic 
 example is user account creation: we want to ensure usernames are unique, so 
 we only want to signal account creation success if nobody else has created 
 the account yet.  But naive read-then-write allows clients to race and both 
 think they have a green light to create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: Fix SSL client authentication (CASSANDRA-5120)

2013-02-27 Thread aleksey

Updated Branches:
  refs/heads/cassandra-1.2 33ce1e35f - ab23afa52


Fix SSL client authentication (CASSANDRA-5120)


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ab23afa5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ab23afa5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ab23afa5

Branch: refs/heads/cassandra-1.2
Commit: ab23afa521327ce5bf46a078e6bbd0591e00e778
Parents: 33ce1e3
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Feb 28 00:53:22 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Feb 28 00:53:22 2013 +0300

--
 conf/cassandra.yaml|5 -
 .../apache/cassandra/config/EncryptionOptions.java |2 +-
 .../cassandra/thrift/CustomTThreadPoolServer.java  |6 +-
 3 files changed, 10 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab23afa5/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 6d0528a..0a8102d 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -662,12 +662,15 @@ client_encryption_options:
 enabled: false
 keystore: conf/.keystore
 keystore_password: cassandra
+# require_client_auth: false
+# Set trustore and truststore_password if require_client_auth is true
+# truststore: conf/.truststore
+# truststore_password: cassandra
 # More advanced defaults below:
 # protocol: TLS
 # algorithm: SunX509
 # store_type: JKS
 # cipher_suites: 
[TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
-# require_client_auth: false
 
 # internode_compression controls whether traffic between nodes is
 # compressed.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab23afa5/src/java/org/apache/cassandra/config/EncryptionOptions.java
--
diff --git a/src/java/org/apache/cassandra/config/EncryptionOptions.java 
b/src/java/org/apache/cassandra/config/EncryptionOptions.java
index fe07f68..f873636 100644
--- a/src/java/org/apache/cassandra/config/EncryptionOptions.java
+++ b/src/java/org/apache/cassandra/config/EncryptionOptions.java
@@ -27,7 +27,7 @@ public abstract class EncryptionOptions
 public String protocol = TLS;
 public String algorithm = SunX509;
 public String store_type = JKS;
-public Boolean require_client_auth = false;
+public boolean require_client_auth = false;
 
 public static class ClientEncryptionOptions extends EncryptionOptions
 {

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab23afa5/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java 
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index 0a456b9..7014443 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -249,7 +249,11 @@ public class CustomTThreadPoolServer extends TServer
 logger.info(enabling encrypted thrift connections between 
client and server);
 TSSLTransportParameters params = new 
TSSLTransportParameters(clientEnc.protocol, clientEnc.cipher_suites);
 params.setKeyStore(clientEnc.keystore, 
clientEnc.keystore_password);
-params.requireClientAuth(clientEnc.require_client_auth);
+if (clientEnc.require_client_auth)
+{
+params.setTrustStore(clientEnc.truststore, 
clientEnc.truststore_password);
+params.requireClientAuth(true);
+}
 TServerSocket sslServer = 
TSSLTransportFactory.getServerSocket(addr.getPort(), 0, addr.getAddress(), 
params);
 serverTransport = new 
TCustomServerSocket(sslServer.getServerSocket(), args.keepAlive, 
args.sendBufferSize, args.recvBufferSize);
 }

[1/2] git commit: Fix SSL client authentication (CASSANDRA-5120)

2013-02-27 Thread aleksey

Fix SSL client authentication (CASSANDRA-5120)


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ab23afa5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ab23afa5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ab23afa5

Branch: refs/heads/trunk
Commit: ab23afa521327ce5bf46a078e6bbd0591e00e778
Parents: 33ce1e3
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Feb 28 00:53:22 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Feb 28 00:53:22 2013 +0300

--
 conf/cassandra.yaml|5 -
 .../apache/cassandra/config/EncryptionOptions.java |2 +-
 .../cassandra/thrift/CustomTThreadPoolServer.java  |6 +-
 3 files changed, 10 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab23afa5/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 6d0528a..0a8102d 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -662,12 +662,15 @@ client_encryption_options:
 enabled: false
 keystore: conf/.keystore
 keystore_password: cassandra
+# require_client_auth: false
+# Set trustore and truststore_password if require_client_auth is true
+# truststore: conf/.truststore
+# truststore_password: cassandra
 # More advanced defaults below:
 # protocol: TLS
 # algorithm: SunX509
 # store_type: JKS
 # cipher_suites: 
[TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
-# require_client_auth: false
 
 # internode_compression controls whether traffic between nodes is
 # compressed.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab23afa5/src/java/org/apache/cassandra/config/EncryptionOptions.java
--
diff --git a/src/java/org/apache/cassandra/config/EncryptionOptions.java 
b/src/java/org/apache/cassandra/config/EncryptionOptions.java
index fe07f68..f873636 100644
--- a/src/java/org/apache/cassandra/config/EncryptionOptions.java
+++ b/src/java/org/apache/cassandra/config/EncryptionOptions.java
@@ -27,7 +27,7 @@ public abstract class EncryptionOptions
 public String protocol = TLS;
 public String algorithm = SunX509;
 public String store_type = JKS;
-public Boolean require_client_auth = false;
+public boolean require_client_auth = false;
 
 public static class ClientEncryptionOptions extends EncryptionOptions
 {

http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab23afa5/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java 
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index 0a456b9..7014443 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -249,7 +249,11 @@ public class CustomTThreadPoolServer extends TServer
 logger.info(enabling encrypted thrift connections between 
client and server);
 TSSLTransportParameters params = new 
TSSLTransportParameters(clientEnc.protocol, clientEnc.cipher_suites);
 params.setKeyStore(clientEnc.keystore, 
clientEnc.keystore_password);
-params.requireClientAuth(clientEnc.require_client_auth);
+if (clientEnc.require_client_auth)
+{
+params.setTrustStore(clientEnc.truststore, 
clientEnc.truststore_password);
+params.requireClientAuth(true);
+}
 TServerSocket sslServer = 
TSSLTransportFactory.getServerSocket(addr.getPort(), 0, addr.getAddress(), 
params);
 serverTransport = new 
TCustomServerSocket(sslServer.getServerSocket(), args.keepAlive, 
args.sendBufferSize, args.recvBufferSize);
 }

[2/2] git commit: Merge branch 'cassandra-1.2' into trunk

2013-02-27 Thread aleksey

Updated Branches:
  refs/heads/trunk 73e8cb62f - 1aa9312f9


Merge branch 'cassandra-1.2' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1aa9312f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1aa9312f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1aa9312f

Branch: refs/heads/trunk
Commit: 1aa9312f928edb497632a3547eb7560092f16c09
Parents: 73e8cb6 ab23afa
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Feb 28 00:56:24 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Feb 28 00:56:24 2013 +0300

--
 conf/cassandra.yaml|5 -
 .../apache/cassandra/config/EncryptionOptions.java |2 +-
 .../cassandra/thrift/CustomTThreadPoolServer.java  |6 +-
 3 files changed, 10 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1aa9312f/conf/cassandra.yaml
--

[jira] [Commented] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588827#comment-13588827
 ] 

Aleksey Yeschenko commented on CASSANDRA-5120:
--

Committed in ab23afa521327ce5bf46a078e6bbd0591e00e778

 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5062) Support CAS

[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588834#comment-13588834
]

Jonathan Ellis commented on CASSANDRA-5062:
---

I think I can summarize things this way:

# Embedding or requiring ZK is a non-starter. So anything that starts with
that as a dependency (Spinnaker or Kafka-style replication) means implement
ZAB [or Paxos] first.
# A global master to designate cohort leaders as in HBase or Hibari is also a
non-starter.
# ZAB recovery after leader failure is a mess. (I recommend the 2008 paper
over the 2011 one; it's far more readable.)
# All of the options require some kind of proposal storage separate from
committed rows.

So I keep coming back to, first implement raw Paxos; then we can use that at a
building block to optimize later if CAS performance becomes more of a
priority. (Proposal storage may in fact be the initial bottleneck, not the
replication strategy.)

Support CAS
---

Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0

[jira] [Commented] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588879#comment-13588879
 ] 

Ryan McGuire commented on CASSANDRA-5120:
-

Given that cqlsh doesn't have the capability to use client certificates, I was 
curious if I could jury rig it through stunnel. Looks like it works.

My stunnel config:

{code}
client = yes
cert = client.pem
foreground = yes
debug = 7
pid = /tmp/stunnel-client.pid

[cqlsh]
accept = 9161
connect = 127.0.0.1:9160
{code}

This creates a clear text port 9161 that tunnels through to cassandra's SSL 
encrypted port 9160. You start stunnel with that config and then use cqlsh 
connecting to port 9161:

{code}
$ CQLSH_PORT=9161 cqlsh
Connected to ssl at 127.0.0.1:9161.
[cqlsh 2.3.0 | Cassandra 1.2.2-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 
19.35.0]
Use HELP for help.
cqlsh 
{code}

 Add support for SSL sockets to use client certificate authentication.
 -

 Key: CASSANDRA-5120
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.2.0
Reporter: Steven Franklin
Assignee: Aleksey Yeschenko
Priority: Minor
 Fix For: 1.2.1

 Attachments: trunk-5120.txt


 Add an option to EncryptionOptions to require client certication 
 authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Cassandra Wiki] Trivial Update of KristinCo by KristinCo

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The KristinCo page has been changed by KristinCo:
http://wiki.apache.org/cassandra/KristinCo

New page:
Hey !! I am HYO SHAFFER. I belong to Paterson. This summer iam going to be 
50.BR
I am a fan of Aquarium. My father name is Carles  and he is a Ethologist. My 
mother is a Agent.BR
BR
Look into my webpage - [[http://www.reachchanelhandbags.com|chanel outlet]]

[Cassandra Wiki] Trivial Update of SherriEld by SherriEld

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The SherriEld page has been changed by SherriEld:
http://wiki.apache.org/cassandra/SherriEld

New page:
Hey guys !! The name is ISADORA FLOWERS. I reside in Daytona Beach.BR
This may i will be 23. I might join The Smooth Boarding School in St Davids. I 
like Kayaking.BR
BR
my blog - [[http://www.conreplicahandbags.com|cheap designer handbags]]

[Cassandra Wiki] Trivial Update of ErnestLac by ErnestLac

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The ErnestLac page has been changed by ErnestLac:
http://wiki.apache.org/cassandra/ErnestLac

New page:
Hey fellas !! The name is KEILA OCHOA. I reside in New York.BR
I am turning 31. I might join The Cozy Institute located in San Bernardino. I 
like Geo Caching.BR
BR
Also visit my weblog: 
[[http://www.cleanscreenxcel.com/cheapmonsterbeatsbydre.html|cheap dre beats]]

[Cassandra Wiki] Trivial Update of AliceHelm by AliceHelm

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The AliceHelm page has been changed by AliceHelm:
http://wiki.apache.org/cassandra/AliceHelm

New page:
Howdy !! The name is CHRISTIANE ALBERT. I live in Provo.BR
I might join The Scarce Finishing School of Awful People in Winston. I also 
like to Leathercrafting. My papa name is Tony  and he is a Teacher. My mom is a 
Interpreter.BR
BR
Here is my weblog :: [[http://www.reachbeatsbydre.com|dre beats cheap]]

[Cassandra Wiki] Update of ThirdPartySupport by BenBromhead

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The ThirdPartySupport page has been changed by BenBromhead:
http://wiki.apache.org/cassandra/ThirdPartySupport?action=diffrev1=39rev2=40

Comment:
Adding new provider - Instaclustr

  
  [[http://www.dbteamlimited.co.uk|DB Team Limited]] We provide expert level 
consultancy services for performance tuning large Apache Cassandra Oracle and 
SQL Server databases. Contact us at adminatdbteamlimited.co.uk
  
+ 
+ {{http://www.decisivelabs.com.au/img/platforms/instaclustr-l...@2x.png}} 
[[https://www.instaclustr.com/?cid=casspp|Instaclustr]] provides managed Apache 
Cassandra hosting on Amazon Web Services. Instaclustr dramatically reduces 
administration overheads and support costs by providing automated deployment, 
backups, cluster balancing and performance tuning.
+ 
  (Other providers are welcome to add themselves to this publicly-editable 
page.)

[Cassandra Wiki] Trivial Update of Dominick7 by Dominick7