date:20130624


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

Sergio Bossa edited comment on CASSANDRA-5692 at 6/24/13 12:53 PM:
---

Given the first message which should setup the version is sent along the same 
connection, this patch doesn't actually work, causing two 1.2 nodes to block 
each other during bootstrap.

So I'm attaching a different patch (0005), which implements a simple handshake 
by assuming version 6 and trying to read the actual version on a different 
thread, so that it can be interrupted (disconnected) and can retry the 
handshake until one of the following happens:
1) The version is confirmed to be = 6, and the handshake succeeds.
2) The version is an old one, hence it is expected to be found among the 
tracked versions when the first gossip message is received.

Sorry for all the different patches, but the implementation details of all the 
version exchange machinery turned out to be quite subtle.

  was (Author: sbtourist):
Given the first message which should setup the version is sent along the 
same connection, this patch doesn't actually work, causing two 1.2 nodes to 
block each other during bootstrap.

So I'm attaching a different patch, which implements a simple handshake by 
assuming version 6 and trying to read the actual version on a different thread, 
so that it can be interrupted (disconnected) and can retry the handshake until 
one of the following happens:
1) The version is confirmed to be = 6, and the handshake succeeds.
2) The version is an old one, hence it is expected to be found among the 
tracked versions when the first gossip message is received.

Sorry for all the different patches, but the implementation details of all the 
version exchange machinery turned out to be quite subtle.
  
 Race condition in detecting version on a mixed 1.1/1.2 cluster
 --

 Key: CASSANDRA-5692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5692
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.9, 1.2.5
Reporter: Sergio Bossa
Priority: Minor
 Attachments: 5692-0001.patch, 5692-0004.patch, 5692-0005.patch


 On a mixed 1.1 / 1.2 cluster, starting 1.2 nodes fires sometimes a race 
 condition in version detection, where the 1.2 node wrongly detects version 6 
 for a 1.1 node.
 It works as follows:
 1) The just started 1.2 node quickly opens an OutboundTcpConnection toward a 
 1.1 node before receiving any messages from the latter.
 2) Given the version is correctly detected only when the first message is 
 received, the version is momentarily set at 6.
 3) This opens an OutboundTcpConnection from 1.2 to 1.1 at version 6, which 
 gets stuck in the connect() method.
 Later, the version is correctly fixed, but all outbound connections from 1.2 
 to 1.1 are stuck at this point.
 Evidence from 1.2 logs:
 TRACE 13:48:31,133 Assuming current protocol version for /127.0.0.2
 DEBUG 13:48:37,837 Setting version 5 for /127.0.0.2

--
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-5692) Race condition in detecting version on a mixed 1.1/1.2 cluster


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

Sergio Bossa commented on CASSANDRA-5692:
-

Given the first message which should setup the version is sent along the same 
connection, this patch doesn't actually work, causing two 1.2 nodes to block 
each other during bootstrap.

So I'm attaching a different patch, which implements a simple handshake by 
assuming version 6 and trying to read the actual version on a different thread, 
so that it can be interrupted (disconnected) and can retry the handshake until 
one of the following happens:
1) The version is confirmed to be = 6, and the handshake succeeds.
2) The version is an old one, hence it is expected to be found among the 
tracked versions when the first gossip message is received.

Sorry for all the different patches, but the implementation details of all the 
version exchange machinery turned out to be quite subtle.

 Race condition in detecting version on a mixed 1.1/1.2 cluster
 --

 Key: CASSANDRA-5692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5692
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.9, 1.2.5
Reporter: Sergio Bossa
Priority: Minor
 Attachments: 5692-0001.patch, 5692-0004.patch, 5692-0005.patch


 On a mixed 1.1 / 1.2 cluster, starting 1.2 nodes fires sometimes a race 
 condition in version detection, where the 1.2 node wrongly detects version 6 
 for a 1.1 node.
 It works as follows:
 1) The just started 1.2 node quickly opens an OutboundTcpConnection toward a 
 1.1 node before receiving any messages from the latter.
 2) Given the version is correctly detected only when the first message is 
 received, the version is momentarily set at 6.
 3) This opens an OutboundTcpConnection from 1.2 to 1.1 at version 6, which 
 gets stuck in the connect() method.
 Later, the version is correctly fixed, but all outbound connections from 1.2 
 to 1.1 are stuck at this point.
 Evidence from 1.2 logs:
 TRACE 13:48:31,133 Assuming current protocol version for /127.0.0.2
 DEBUG 13:48:37,837 Setting version 5 for /127.0.0.2

--
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-5692) Race condition in detecting version on a mixed 1.1/1.2 cluster


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

Sergio Bossa updated CASSANDRA-5692:


Attachment: 5692-0005.patch

 Race condition in detecting version on a mixed 1.1/1.2 cluster
 --

 Key: CASSANDRA-5692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5692
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.9, 1.2.5
Reporter: Sergio Bossa
Priority: Minor
 Attachments: 5692-0001.patch, 5692-0004.patch, 5692-0005.patch


 On a mixed 1.1 / 1.2 cluster, starting 1.2 nodes fires sometimes a race 
 condition in version detection, where the 1.2 node wrongly detects version 6 
 for a 1.1 node.
 It works as follows:
 1) The just started 1.2 node quickly opens an OutboundTcpConnection toward a 
 1.1 node before receiving any messages from the latter.
 2) Given the version is correctly detected only when the first message is 
 received, the version is momentarily set at 6.
 3) This opens an OutboundTcpConnection from 1.2 to 1.1 at version 6, which 
 gets stuck in the connect() method.
 Later, the version is correctly fixed, but all outbound connections from 1.2 
 to 1.1 are stuck at this point.
 Evidence from 1.2 logs:
 TRACE 13:48:31,133 Assuming current protocol version for /127.0.0.2
 DEBUG 13:48:37,837 Setting version 5 for /127.0.0.2

--
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-5014) Convert timeout from milli second to micro second.


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

Jonathan Ellis commented on CASSANDRA-5014:
---

Dunno, I was only thinking of the retries here but maybe we're not too far from 
a world where we want all the op timeouts to be millis.  I think I saw a ticket 
that implied Twitter experimented with setting timeouts 1ms.  Thoughts [~xedin] 
[~rbranson]?

 Convert timeout from milli second to micro second.
 --

 Key: CASSANDRA-5014
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5014
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0 beta 1
Reporter: Vijay
Assignee: Vijay
Priority: Trivial
 Fix For: 2.0 beta 1

 Attachments: 0001-CASSANDRA-5014.patch


 Convert all the timeouts to microseconds.
 Jonathan's comment from CASSANDRA-4705
 {quote}
 millis may be too coarse a grain here, especially for Custom settings. 
 Currently an in-memory read will typically be under 2ms and it's quite 
 possible we can get that down to 1 if we can purge some of the latency 
 between stages. Might as well use micros since Timer gives it to us for free
 {quote}

--
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-5691) Remove SimpleCondition


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

Jonathan Ellis commented on CASSANDRA-5691:
---

Yes, it's pretty obvious that signal==signalAll in SimpleCondition.  (Signaling 
just a single waiter is fairly useless and not something we care about.)

Unless CDL offers a performance benefit I don't see any point in churning this.

 Remove SimpleCondition
 --

 Key: CASSANDRA-5691
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5691
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Mikhail Mazursky
Priority: Minor
 Attachments: trunk-5691.patch


 Problematic scenario:
 1. two threads get blocked in SimpleCondition.await();
 2. some thread calls SimpleCondition.signal();
 3. one of blocked threads wakes up and runs;
 4. spurious wakeup happens in the second thread and it wakes up too and runs 
 even though nobody signaled it.
 Thus this is a broken implementation of Condition interface.
 Anyway, looking at how code uses it, SimpleCondition can just be replaced 
 with CountDownLatch.

--
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-5689) NPE shutting down Cassandra trunk (cassandra-1.2.5-989-g70dfb70)


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

Jonathan Ellis updated CASSANDRA-5689:
--

Priority: Trivial  (was: Major)

 NPE shutting down Cassandra trunk (cassandra-1.2.5-989-g70dfb70)
 

 Key: CASSANDRA-5689
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5689
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0 beta 1
 Environment: Ubuntu Precise with Oracle Java 7u25.
Reporter: Blair Zajac
Priority: Trivial

 I built Cassandra from git trunk at cassandra-1.2.5-989-g70dfb70 using the 
 debian/ package.  I have a shell script to shut down Cassandra:
 {code}
   $nodetool disablegossip
   sleep 5
   $nodetool disablebinary
   $nodetool disablethrift
   $nodetool drain
   /etc/init.d/cassandra stop
 {code}
 Shutting it down I get this exception on all three nodes:
 {code}
 Exception in thread main java.lang.NullPointerException
   at org.apache.cassandra.transport.Server.close(Server.java:156)
   at org.apache.cassandra.transport.Server.stop(Server.java:107)
   at 
 org.apache.cassandra.service.StorageService.stopNativeTransport(StorageService.java:347)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
   at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
   at 
 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
   at 
 com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
   at 
 com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
   at 
 javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
   at sun.rmi.transport.Transport$1.run(Transport.java:177)
   at sun.rmi.transport.Transport$1.run(Transport.java:174)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:724)
 {code}

--
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

[1/2] git commit: replace assert+cast w/ checkedCast

Updated Branches:
  refs/heads/trunk 36ef643e4 - 15df6691c


replace assert+cast w/ checkedCast


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

Branch: refs/heads/trunk
Commit: b48bd56e78788f0cd20735fdb7d9bfcbfb999cf7
Parents: 36ef643
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 24 06:41:22 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jun 24 06:41:22 2013 -0700

--
 src/java/org/apache/cassandra/db/RowIndexEntry.java | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b48bd56e/src/java/org/apache/cassandra/db/RowIndexEntry.java
--
diff --git a/src/java/org/apache/cassandra/db/RowIndexEntry.java 
b/src/java/org/apache/cassandra/db/RowIndexEntry.java
index 2819ae0..cfc7cf1 100644
--- a/src/java/org/apache/cassandra/db/RowIndexEntry.java
+++ b/src/java/org/apache/cassandra/db/RowIndexEntry.java
@@ -24,6 +24,8 @@ import java.util.ArrayList;
 import java.util.Collections;
 import java.util.List;
 
+import com.google.common.primitives.Ints;
+
 import org.apache.cassandra.cache.IMeasurableMemory;
 import org.apache.cassandra.io.sstable.Descriptor;
 import org.apache.cassandra.io.sstable.IndexHelper;
@@ -181,8 +183,7 @@ public class RowIndexEntry implements IMeasurableMemory
 for (IndexHelper.IndexInfo info : columnsIndex)
 size += info.serializedSize(typeSizes);
 
-assert size = Integer.MAX_VALUE;
-return (int)size;
+return Ints.checkedCast(size);
 }
 
 @Override

[jira] [Updated] (CASSANDRA-5667) Change timestamps used in CAS ballot proposals to be more resilient to clock skew


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

Jonathan Ellis updated CASSANDRA-5667:
--

 Priority: Minor  (was: Major)
Affects Version/s: 2.0 beta 1
Fix Version/s: 2.0 beta 1
 Assignee: Jonathan Ellis
   Issue Type: Improvement  (was: Bug)

 Change timestamps used in CAS ballot proposals to be more resilient to clock 
 skew
 -

 Key: CASSANDRA-5667
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5667
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0 beta 1
 Environment: n/a
Reporter: Nick Puz
Assignee: Jonathan Ellis
Priority: Minor
 Fix For: 2.0 beta 1


 The current time is used to generate the timeuuid used for CAS ballots 
 proposals with the logic that if a newer proposal exists then the current one 
 needs to complete that and re-propose. The problem is that if a machine has 
 clock skew and drifts into the future it will propose with a large timestamp 
 (which will get accepted) but then subsequent proposals with lower (but 
 correct) timestamps will not be able to proceed. This will prevent CAS write 
 operations and also reads at serializable consistency level. 
 The work around is to initially propose with current time (current behavior) 
 but if the proposal fails due to a larger existing one re-propose (after 
 completing the existing if necessary) with the max of (currentTime, 
 mostRecent+1, proposed+1).
 Since small drift is normal between different nodes in the same datacenter 
 this can happen even if NTP is working properly and a write hits one node and 
 a subsequent serialized read hits another. In the case of NTP config issues 
 (or OS bugs with time esp around DST) the unavailability window could be much 
 larger.  

--
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

[2/2] git commit: Tracing cleanup patch by Mikhail Mazursky; reviewed by jbellis for CASSANDRA-5625

Tracing cleanup
patch by Mikhail Mazursky; reviewed by jbellis for CASSANDRA-5625


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

Branch: refs/heads/trunk
Commit: 15df6691caf9e681727338d66d8f8b0d42843177
Parents: b48bd56
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 24 06:46:28 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jun 24 06:46:28 2013 -0700

--
 .../DebuggableThreadPoolExecutor.java   |  6 +-
 .../org/apache/cassandra/net/MessageOut.java|  2 +-
 .../apache/cassandra/net/MessagingService.java  |  2 +-
 .../cassandra/net/OutboundTcpConnection.java|  4 +-
 .../apache/cassandra/service/QueryState.java|  4 +-
 .../cassandra/service/StorageService.java   |  1 -
 .../cassandra/thrift/CassandraServer.java   | 84 ++--
 .../org/apache/cassandra/tracing/Tracing.java   | 41 +++---
 .../transport/messages/BatchMessage.java|  4 +-
 .../transport/messages/ExecuteMessage.java  |  4 +-
 .../transport/messages/PrepareMessage.java  |  4 +-
 .../transport/messages/QueryMessage.java|  4 +-
 12 files changed, 70 insertions(+), 90 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/15df6691/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
--
diff --git 
a/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java 
b/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
index 46a3216..665f0b0 100644
--- a/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
+++ b/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
@@ -266,7 +266,7 @@ public class DebuggableThreadPoolExecutor extends 
ThreadPoolExecutor implements
 public TraceSessionWrapper(CallableT callable)
 {
 super(callable);
-state = Tracing.instance().get();
+state = Tracing.instance.get();
 }
 
 public TraceSessionWrapper(Runnable command, TraceState state)
@@ -277,12 +277,12 @@ public class DebuggableThreadPoolExecutor extends 
ThreadPoolExecutor implements
 
 private void setupContext()
 {
-Tracing.instance().set(state);
+Tracing.instance.set(state);
 }
 
 private void reset()
 {
-Tracing.instance().set(null);
+Tracing.instance.set(null);
 }
 }
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15df6691/src/java/org/apache/cassandra/net/MessageOut.java
--
diff --git a/src/java/org/apache/cassandra/net/MessageOut.java 
b/src/java/org/apache/cassandra/net/MessageOut.java
index e10fcee..dd6cae8 100644
--- a/src/java/org/apache/cassandra/net/MessageOut.java
+++ b/src/java/org/apache/cassandra/net/MessageOut.java
@@ -57,7 +57,7 @@ public class MessageOutT
 this(verb,
  payload,
  serializer,
- isTracing() ? ImmutableMap.of(TRACE_HEADER, 
UUIDGen.decompose(Tracing.instance().getSessionId()))
+ isTracing() ? ImmutableMap.of(TRACE_HEADER, 
UUIDGen.decompose(Tracing.instance.getSessionId()))
  : Collections.String, byte[]emptyMap());
 }
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15df6691/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java 
b/src/java/org/apache/cassandra/net/MessagingService.java
index e01183c..43e2cb2 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -680,7 +680,7 @@ public final class MessagingService implements 
MessagingServiceMBean
 
 public void receive(MessageIn message, int id, long timestamp)
 {
-TraceState state = Tracing.instance().initializeFromMessage(message);
+TraceState state = Tracing.instance.initializeFromMessage(message);
 if (state != null)
 state.trace(Message received from {}, message.from);
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/15df6691/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/OutboundTcpConnection.java 
b/src/java/org/apache/cassandra/net/OutboundTcpConnection.java
index ba13644..4c6f498 100644
---

[jira] [Commented] (CASSANDRA-4415) Add cursor API/auto paging to the native CQL protocol

2013-06-24 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-4415:
-

Thanks for the review.

I've pushed a additional patch on the same (force-rebased) branch to fix those
issues. I realized that the QueryPagers.pagedQuery() method wasn't really
cutting it since it was losing the CF-level deletion information, so I've
replaced it with a simpler countPaged() method. The code was also slightly
under-counting the number of remaining results so that's fixed too.

All tests seem to be working fine here now.

Add cursor API/auto paging to the native CQL protocol
-

Key: CASSANDRA-4415
URL: https://issues.apache.org/jira/browse/CASSANDRA-4415
Project: Cassandra
Issue Type: New Feature
Affects Versions: 1.2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql, protocol
Fix For: 2.0 beta 1

The goal here would be to use a query paging mechanism to the CQL native
protocol. Typically the client/server with that would look something like
this:
{noformat}
C sends query to S.
S sends N first rows matching the query + flag saying the response is not
complete
C requests the next N rows
S sends N next rows + flag saying whether there is more
C requests the next N rows
...
S sends last rows + flag saying there is no more result
{noformat}
The clear goal is for user to not have to worry about limiting queries and
doing manual paging.

--
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-5561) Compaction strategy that minimizes re-compaction of old/frozen data

2013-06-24 Thread Edward Capriolo (JIRA)

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

Edward Capriolo commented on CASSANDRA-5561:

Or simply use the max/min column time stamp and something like a dateformat
like mmdd. This would mean two sstables for different days NEVER compact
together.

Compaction strategy that minimizes re-compaction of old/frozen data
---

Key: CASSANDRA-5561
URL: https://issues.apache.org/jira/browse/CASSANDRA-5561
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.3
Reporter: Tupshin Harper
Fix For: 2.0.1

Neither LCS nor STCS are good for data that becomes immutable over time. The
most obvious case is for time-series data where the application can guarantee
that out-of-order delivery (to Cassandra) of events can't take place more
than N minutes/seconds/hours/days have elapsed after the real (wall time).
There are various approaches that could involve paying attention to the row
keys (if they include a time component) and/or the column name (if they are
TimeUUID or Integer based and are inherently time-ordered), but it might be
sufficient to just look at the timestamp of the columns themselves.
A possible approach:
1) Define an optional max-out-of-order window on a per-CF basis.
2) Use normal (LCS or STCS) compaction strategy for any SSTables that include
any columns younger than max-out-of-order-delivery).
3) Use alternate compaction strategy (will call it TWCS time window
compaction strategy for now) for any SSTables that only contain columns older
than max-out-of-order-delivery.
4) TWCS will only compact sstables containing data older than
max-out-of-order-delivery.
5) TWCS will only perform compaction to reduce row fragmentation (if there is
any by the time it gets to TWCS or to reduce the number of small sstables.
6) To minimize re-compaction in TWCS, it should aggresively try to compact as
many small sstables as possible into one large sstable that would never have
to get recompacted.
In the case of large datasets (e.g. 5TB per node) with LCS, there would be on
the order of seven levels, and hence seven separate writes of the same data
over time. With this approach, it should be possible to get about 3
compactions per column (2 in original compaction and one more once hitting
TWCS) in most cases, cutting the write workload by a factor of two or more
for high volume time-series applications.
Note that the only workaround I can currently suggest to minimize compaction
for these workloads is to programatically shard your data across time-window
ranges (e.g. new CF per week), but that pushes unnecessary writing and
querying logic out to the user and is not as convenient nor flexible.
Also note that I am not convinced that the approach I've suggested above is
the best/most general way to solve the problem, but it does appear to be a
relatively easy one to implement.

[jira] [Updated] (CASSANDRA-5692) Race condition in detecting version on a mixed 1.1/1.2 cluster


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

Sergio Bossa updated CASSANDRA-5692:


Attachment: (was: 5692-0004.patch)

 Race condition in detecting version on a mixed 1.1/1.2 cluster
 --

 Key: CASSANDRA-5692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5692
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.9, 1.2.5
Reporter: Sergio Bossa
Priority: Minor
 Attachments: 5692-0005.patch


 On a mixed 1.1 / 1.2 cluster, starting 1.2 nodes fires sometimes a race 
 condition in version detection, where the 1.2 node wrongly detects version 6 
 for a 1.1 node.
 It works as follows:
 1) The just started 1.2 node quickly opens an OutboundTcpConnection toward a 
 1.1 node before receiving any messages from the latter.
 2) Given the version is correctly detected only when the first message is 
 received, the version is momentarily set at 6.
 3) This opens an OutboundTcpConnection from 1.2 to 1.1 at version 6, which 
 gets stuck in the connect() method.
 Later, the version is correctly fixed, but all outbound connections from 1.2 
 to 1.1 are stuck at this point.
 Evidence from 1.2 logs:
 TRACE 13:48:31,133 Assuming current protocol version for /127.0.0.2
 DEBUG 13:48:37,837 Setting version 5 for /127.0.0.2

--
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-5692) Race condition in detecting version on a mixed 1.1/1.2 cluster


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

Sergio Bossa updated CASSANDRA-5692:


Attachment: (was: 5692-0001.patch)

 Race condition in detecting version on a mixed 1.1/1.2 cluster
 --

 Key: CASSANDRA-5692
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5692
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.9, 1.2.5
Reporter: Sergio Bossa
Priority: Minor
 Attachments: 5692-0005.patch


 On a mixed 1.1 / 1.2 cluster, starting 1.2 nodes fires sometimes a race 
 condition in version detection, where the 1.2 node wrongly detects version 6 
 for a 1.1 node.
 It works as follows:
 1) The just started 1.2 node quickly opens an OutboundTcpConnection toward a 
 1.1 node before receiving any messages from the latter.
 2) Given the version is correctly detected only when the first message is 
 received, the version is momentarily set at 6.
 3) This opens an OutboundTcpConnection from 1.2 to 1.1 at version 6, which 
 gets stuck in the connect() method.
 Later, the version is correctly fixed, but all outbound connections from 1.2 
 to 1.1 are stuck at this point.
 Evidence from 1.2 logs:
 TRACE 13:48:31,133 Assuming current protocol version for /127.0.0.2
 DEBUG 13:48:37,837 Setting version 5 for /127.0.0.2

--
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-5554) Growing pending compactions

2013-06-24 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan updated CASSANDRA-5554:
---

Fix Version/s: 1.2.5

Growing pending compactions
---

Key: CASSANDRA-5554
URL: https://issues.apache.org/jira/browse/CASSANDRA-5554
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Reporter: Oleg Anastasyev
Assignee: Oleg Anastasyev
Fix For: 1.2.5

Attachments: patch.diff, pending_compactions_fixed.png

I noticed on one of our new cassandra production server, that pending
compactions number is steadily growing. The cluster is under low write load,
so compactions are not keeping up was not the case.
A quick investigation shown, that compactions are stopping far before all
pending tasks are completed. I also found, that if concurrent_compactors=1,
background compactions are not happening at all.
The bug is in BackgroundCompactionTask rescheduling logic. The executor pool
room control code in CompactionManager.submitBackground() does not
reschedule next background cycle, if executor.getActiveCount reach maximun
pool size, so it is lost forever.
So I patched it to always schedule single background cycle, regardless of the
free room in executor pool.

[jira] [Commented] (CASSANDRA-5351) Avoid repairing already-repaired data by default

2013-06-24 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan commented on CASSANDRA-5351:

I've been thinking about this issues this morning. Here are my current
thoughts on how it could be accomplished:

1. Keep track on a per range basis the data that has been repaired in a given
sstable. As new ranges are repaired, union them with existing repaired ranges
to update what has been repaired.
2. When sstables are compacted, take the intersection of repaired ranges in the
given sstables to be the repaired ranges for the resulting sstable(s).
3. Do not compact tables which have never been repaired with tables that have
had repairs done. This will prevent new sstables from blowing away the fact
that older tables are all repaired when intersecting ranges per step 2.
4. Make sure to mark sstables which are the result of streaming from repair as
having been repaired.
5. Have repair skip tables which have already been repaired on the specified
range.

I think with those 5 things this should be doable.

Avoid repairing already-repaired data by default

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

Repair has always built its merkle tree from all the data in a columnfamily,
which is guaranteed to work but is inefficient.
We can improve this by remembering which sstables have already been
successfully repaired, and only repairing sstables new since the last repair.
(This automatically makes CASSANDRA-3362 much less of a problem too.)
The tricky part is, compaction will (if not taught otherwise) mix repaired
data together with non-repaired. So we should segregate unrepaired sstables
from the repaired ones.

[jira] [Comment Edited] (CASSANDRA-5351) Avoid repairing already-repaired data by default

2013-06-24 Thread Jeremiah Jordan (JIRA)

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

Jeremiah Jordan edited comment on CASSANDRA-5351 at 6/24/13 4:08 PM:
-

I've been thinking about this issues this morning. Here are my current
thoughts on how it could be accomplished:

1. Keep track on a per range basis the data that has been repaired in a given
sstable. As new ranges are repaired, union them with existing repaired ranges
to update what has been repaired.
2. When sstables are compacted, take the intersection of repaired ranges in the
given sstables to be the repaired ranges for the resulting sstable(s).
3. Do not compact tables which have never been repaired with tables that have
had repairs done. This will prevent new sstables from blowing away the fact
that older tables are all repaired when intersecting ranges per step 2.
4. Make sure to mark sstables which are the result of streaming from repair as
having been repaired.
5. Have repair skip sstables which have already been repaired on the specified
range.

I think with those 5 things this should be doable.

was (Author: jjordan):
I've been thinking about this issues this morning. Here are my current
thoughts on how it could be accomplished:

I think with those 5 things this should be doable.

Avoid repairing already-repaired data by default

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

[jira] [Commented] (CASSANDRA-5234) Table created through CQL3 are not accessble to Pig 0.10


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

Brandon Williams commented on CASSANDRA-5234:
-

Hmm, I'm seeing errors when running the examples/pig/test tests that don't use 
cql3.

 Table created through CQL3 are not accessble to Pig 0.10
 

 Key: CASSANDRA-5234
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5234
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.1
 Environment: Red hat linux 5
Reporter: Shamim Ahmed
Assignee: Alex Liu
 Fix For: 1.2.6

 Attachments: 5234-1-1.2-patch.txt, 5234-1.2-patch.txt, 
 5234-2-1.2branch.txt, 5234.tx


 Hi,
   i have faced a bug when creating table through CQL3 and trying to load data 
 through pig 0.10 as follows:
 java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ'
   at 
 org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112)
   at 
 org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615).
 This effects from Simple table to table with compound key. 

--
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] Update of ClientOptions by DaveBrosius

2013-06-24 Thread Apache Wiki

Dear Wiki user,

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

The ClientOptions page has been changed by DaveBrosius:
https://wiki.apache.org/cassandra/ClientOptions?action=diffrev1=174rev2=175

Comment:
add libcql

* [[https://github.com/tux21b/gocql|gocql]]
   * Haskell
* [[http://hackage.haskell.org/package/cassandra-cql]]
+  * C++
+   * [[https://github.com/mstump/libcql]]
  
  
  = Thrift =

[Cassandra Wiki] Update of ClientOptions by DaveBrosius

2013-06-24 Thread Apache Wiki

Dear Wiki user,

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

The ClientOptions page has been changed by DaveBrosius:
https://wiki.apache.org/cassandra/ClientOptions?action=diffrev1=175rev2=176

   * PHP:
* [[http://code.google.com/a/apache-extras.org/p/cassandra-pdo/|Cassandra 
PDO driver]]
   * Perl:
-   * perlcassa: https://github.com/mkjellman/perlcassa
+   * [[https://github.com/mkjellman/perlcassa|perlcassa]]
   * Go
* [[https://github.com/tux21b/gocql|gocql]]
   * Haskell
-   * [[http://hackage.haskell.org/package/cassandra-cql]]
+   * [[http://hackage.haskell.org/package/cassandra-cql|cassandra-cql]]
   * C++
-   * [[https://github.com/mstump/libcql]]
+   * [[https://github.com/mstump/libcql|libcql]]
  
  
  = Thrift =

[jira] [Issue Comment Deleted] (CASSANDRA-5234) Table created through CQL3 are not accessble to Pig 0.10

2013-06-24 Thread Cyril Scetbon (JIRA)


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

Cyril Scetbon updated CASSANDRA-5234:
-

Comment: was deleted

(was: In my previous comment I asked for a consistency parameter and found 
there is already one in hadoop configuration, so never mind. We won't be able 
to use it as we have Replication-Factor=1 :( I sent an email on 
u...@apache.cassandra.org to ask for a workaround.)

 Table created through CQL3 are not accessble to Pig 0.10
 

 Key: CASSANDRA-5234
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5234
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.1
 Environment: Red hat linux 5
Reporter: Shamim Ahmed
Assignee: Alex Liu
 Fix For: 1.2.6

 Attachments: 5234-1-1.2-patch.txt, 5234-1.2-patch.txt, 
 5234-2-1.2branch.txt, 5234.tx


 Hi,
   i have faced a bug when creating table through CQL3 and trying to load data 
 through pig 0.10 as follows:
 java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ'
   at 
 org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112)
   at 
 org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615).
 This effects from Simple table to table with compound key. 

--
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: Update debian packaging for 2.0 Patch by Blair Zajac, reviewed by brandonwilliams for CASSANDRA-5688

2013-06-24 Thread brandonwilliams

Updated Branches:
  refs/heads/trunk 15df6691c - ab6232aea


Update debian packaging for 2.0
Patch by Blair Zajac, reviewed by brandonwilliams for CASSANDRA-5688


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

Branch: refs/heads/trunk
Commit: ab6232aea9fe3cdb29ca0f30d86aae80b99b6f82
Parents: 15df669
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Jun 24 11:46:19 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Jun 24 11:46:19 2013 -0500

--
 debian/control | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ab6232ae/debian/control
--
diff --git a/debian/control b/debian/control
index aa3db32..ac2c98b 100644
--- a/debian/control
+++ b/debian/control
@@ -3,15 +3,15 @@ Section: misc
 Priority: extra
 Maintainer: Eric Evans eev...@apache.org
 Uploaders: Sylvain Lebresne slebre...@apache.org
-Build-Depends: debhelper (= 5), openjdk-6-jdk (= 6b11) | java6-sdk, ant (= 
1.7), ant-optional (= 1.7), subversion, python-support
+Build-Depends: debhelper (= 5), openjdk-7-jdk | java7-sdk, ant (= 1.7), 
ant-optional (= 1.7), python-support
 Homepage: http://cassandra.apache.org
-Vcs-Svn: https://svn.apache.org/repos/asf/cassandra/trunk
-Vcs-Browser: http://svn.apache.org/viewvc/cassandra/trunk
+Vcs-Git: http://git-wip-us.apache.org/repos/asf/cassandra.git
+Vcs-Browser: https://git-wip-us.apache.org/repos/asf?p=cassandra.git
 Standards-Version: 3.8.3
 
 Package: cassandra
 Architecture: all
-Depends: openjdk-6-jre-headless (= 6b11) | java6-runtime, jsvc (= 1.0), 
libcommons-daemon-java (= 1.0), adduser, libjna-java, python (= 2.5), 
python-support (= 0.90.0), ${misc:Depends}
+Depends: openjdk-7-jre-headless | java7-runtime, jsvc (= 1.0), 
libcommons-daemon-java (= 1.0), adduser, libjna-java, python (= 2.5), 
python-support (= 0.90.0), ${misc:Depends}
 Recommends: ntp
 Conflicts: apache-cassandra1
 Replaces: apache-cassandra1

[jira] [Commented] (CASSANDRA-4415) Add cursor API/auto paging to the native CQL protocol

2013-06-24 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko commented on CASSANDRA-4415:
--

+1

nit: unused boolean doCopy in AQP.filterEmpty() - from an earlier version, I 
assume
femtonit: QP.countPaged() arguments don't line up

 Add cursor API/auto paging to the native CQL protocol
 -

 Key: CASSANDRA-4415
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4415
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 1.2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
  Labels: cql, protocol
 Fix For: 2.0 beta 1


 The goal here would be to use a query paging mechanism to the CQL native 
 protocol. Typically the client/server with that would look something like 
 this:
 {noformat}
 C sends query to S.
 S sends N first rows matching the query + flag saying the response is not 
 complete
 C requests the next N rows
 S sends N next rows + flag saying whether there is more
 C requests the next N rows
 ...
 S sends last rows + flag saying there is no more result
 {noformat}
 The clear goal is for user to not have to worry about limiting queries and 
 doing manual paging.

--
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] [Assigned] (CASSANDRA-5688) Update debian packaging for 2.0


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

Brandon Williams reassigned CASSANDRA-5688:
---

Assignee: Blair Zajac

 Update debian packaging for 2.0
 ---

 Key: CASSANDRA-5688
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5688
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Affects Versions: 2.0 beta 1
 Environment: Ubuntu precise
Reporter: Blair Zajac
Assignee: Blair Zajac
  Labels: build
 Fix For: 2.0 beta 1

 Attachments: trunk-5688.txt


 Building trunk on an Ubuntu Precise VM fails with the following output:
 {code}
 $ git describe 
 cassandra-1.2.5-983-g96a1bb0
 $ dpkg-buildpackage
 ...
 ...
 gen-cql3-grammar:
  [echo] Building Grammar 
 /home/blair/Code/Cassandra/cassandra-0.2.0.0.1.2.5.982/src/java/org/apache/cassandra/cql3/Cql.g
   ...
 build-project:
  [echo] apache-cassandra: 
 /home/blair/Code/Cassandra/cassandra-0.2.0.0.1.2.5.982/build.xml
 [javac] Compiling 41 source files to 
 /home/blair/Code/Cassandra/cassandra-0.2.0.0.1.2.5.982/build/classes/thrift
 [javac] javac: invalid target release: 1.7
 [javac] Usage: javac options source files
 [javac] use -help for a list of possible options
 BUILD FAILED
 {code}
 I'm working on changes to the files in debian/ to support this.

--
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-5680) keyspace (and CF?) argument to nodetool cfstats


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

Brandon Williams resolved CASSANDRA-5680.
-

Resolution: Duplicate

 keyspace (and CF?) argument to nodetool cfstats
 ---

 Key: CASSANDRA-5680
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5680
 Project: Cassandra
  Issue Type: Improvement
Reporter: Robert Coli
Assignee: Edward Capriolo
Priority: Trivial

 Operators frequently use cfstats to get a quick health check/row size 
 check/etc. for their cluster. Unfortunately, the output of cfstats includes 
 system keyspace columnfamilies and there is no easy way to exclude them from 
 the output.
 [~appodictic] and I were discussing this on #cassandra and he said that if I 
 filed a JIRA to request that cfstats take a keyspace (and CF?) argument, he 
 would try to hack out a quick patch.
 Here's that JIRA! :D

--
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-5694) Allow sstable2json to dump SecondaryIndex SSTables


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

Michał Michalski updated CASSANDRA-5694:


Attachment: sstable2json-for-2i.txt

 Allow sstable2json to dump SecondaryIndex SSTables
 --

 Key: CASSANDRA-5694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5694
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Minor
 Attachments: sstable2json-for-2i.txt


 When investigating some 2I problems I had, I was pretty disappointed that 
 sstable2json does not allow me to dump SecondaryIndex, saying that The 
 provided column family is not part of this cassandra database: keyspace = 
 testks, column family = testcf.testcf_col_idx.
 I'm attaching patch that fixes given problem by changing a bit the way that 
 sst2j validates the input file. My only concern is that this solution uses 
 StorageService for validation, so it's a bit heavier than it should, as it 
 has to set everything up.

--
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-5694) Allow sstable2json to dump SecondaryIndex SSTables

Michał Michalski created CASSANDRA-5694:
---

 Summary: Allow sstable2json to dump SecondaryIndex SSTables
 Key: CASSANDRA-5694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5694
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Minor
 Attachments: sstable2json-for-2i.txt

When investigating some 2I problems I had, I was pretty disappointed that 
sstable2json does not allow me to dump SecondaryIndex, saying that The 
provided column family is not part of this cassandra database: keyspace = 
testks, column family = testcf.testcf_col_idx.

I'm attaching patch that fixes given problem by changing a bit the way that 
sst2j validates the input file. My only concern is that this solution uses 
StorageService for validation, so it's a bit heavier than it should, as it 
has to set everything up.

--
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-5695) Convert pig smoke tests into real PigUnit tests

Brandon Williams created CASSANDRA-5695:
---

 Summary: Convert pig smoke tests into real PigUnit tests
 Key: CASSANDRA-5695
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5695
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Brandon Williams
Assignee: Ryan McGuire
 Fix For: 1.2.7


Currently, we have some ghetto pig tests in examples/pig/test, but there's 
currently no way to continuously integrate these since a human needs to check 
that the output isn't wrong, not just that the tests ran successfully.  We've 
had garbled output problems in the past, so it would be nice to formalize our 
tests to catch this.  PigUnit appears to be a good choice for this.

--
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-5694) Allow sstable2json to dump SecondaryIndex SSTables


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

Michał Michalski updated CASSANDRA-5694:


Attachment: (was: sstable2json-for-2i.txt)

 Allow sstable2json to dump SecondaryIndex SSTables
 --

 Key: CASSANDRA-5694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5694
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Minor
 Attachments: sstable2json-for-2i-v1.txt


 When investigating some 2I problems I had, I was pretty disappointed that 
 sstable2json does not allow me to dump SecondaryIndex, saying that The 
 provided column family is not part of this cassandra database: keyspace = 
 testks, column family = testcf.testcf_col_idx.
 I'm attaching patch that fixes given problem by changing a bit the way that 
 sst2j validates the input file. My only concern is that this solution uses 
 StorageService for validation, so it's a bit heavier than it should, as it 
 has to set everything up.

--
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-5694) Allow sstable2json to dump SecondaryIndex SSTables


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

Michał Michalski updated CASSANDRA-5694:


Attachment: sstable2json-for-2i-v1.txt

 Allow sstable2json to dump SecondaryIndex SSTables
 --

 Key: CASSANDRA-5694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5694
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Minor
 Attachments: sstable2json-for-2i-v1.txt


 When investigating some 2I problems I had, I was pretty disappointed that 
 sstable2json does not allow me to dump SecondaryIndex, saying that The 
 provided column family is not part of this cassandra database: keyspace = 
 testks, column family = testcf.testcf_col_idx.
 I'm attaching patch that fixes given problem by changing a bit the way that 
 sst2j validates the input file. My only concern is that this solution uses 
 StorageService for validation, so it's a bit heavier than it should, as it 
 has to set everything up.

--
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-5694) Allow sstable2json to dump SecondaryIndex SSTables


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

Jonathan Ellis commented on CASSANDRA-5694:
---

Don't we have the information in the filename to figure out what the parent 
CF would be?  Not a fan of starting up StorageService here.

 Allow sstable2json to dump SecondaryIndex SSTables
 --

 Key: CASSANDRA-5694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5694
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Minor
 Attachments: sstable2json-for-2i-v1.txt


 When investigating some 2I problems I had, I was pretty disappointed that 
 sstable2json does not allow me to dump SecondaryIndex, saying that The 
 provided column family is not part of this cassandra database: keyspace = 
 testks, column family = testcf.testcf_col_idx.
 I'm attaching patch that fixes given problem by changing a bit the way that 
 sst2j validates the input file. My only concern is that this solution uses 
 StorageService for validation, so it's a bit heavier than it should, as it 
 has to set everything up.

--
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-5695) Convert pig smoke tests into real PigUnit tests


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

Brandon Williams updated CASSANDRA-5695:


Priority: Minor  (was: Major)

 Convert pig smoke tests into real PigUnit tests
 ---

 Key: CASSANDRA-5695
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5695
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Brandon Williams
Assignee: Ryan McGuire
Priority: Minor
 Fix For: 1.2.7


 Currently, we have some ghetto pig tests in examples/pig/test, but there's 
 currently no way to continuously integrate these since a human needs to check 
 that the output isn't wrong, not just that the tests ran successfully.  We've 
 had garbled output problems in the past, so it would be nice to formalize our 
 tests to catch this.  PigUnit appears to be a good choice for this.

--
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-5695) Convert pig smoke tests into real PigUnit tests


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

Brandon Williams commented on CASSANDRA-5695:
-

[https://svn.apache.org/repos/asf/pig/trunk/test/org/apache/pig/test/TestHBaseStorage.java]
 shows how Pig does it for HBase.

 Convert pig smoke tests into real PigUnit tests
 ---

 Key: CASSANDRA-5695
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5695
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Brandon Williams
Assignee: Ryan McGuire
 Fix For: 1.2.7


 Currently, we have some ghetto pig tests in examples/pig/test, but there's 
 currently no way to continuously integrate these since a human needs to check 
 that the output isn't wrong, not just that the tests ran successfully.  We've 
 had garbled output problems in the past, so it would be nice to formalize our 
 tests to catch this.  PigUnit appears to be a good choice for this.

--
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-5695) Convert pig smoke tests into real PigUnit tests


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

Brandon Williams updated CASSANDRA-5695:


Issue Type: Test  (was: Bug)

 Convert pig smoke tests into real PigUnit tests
 ---

 Key: CASSANDRA-5695
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5695
 Project: Cassandra
  Issue Type: Test
  Components: Hadoop
Reporter: Brandon Williams
Assignee: Ryan McGuire
Priority: Minor
 Fix For: 1.2.7


 Currently, we have some ghetto pig tests in examples/pig/test, but there's 
 currently no way to continuously integrate these since a human needs to check 
 that the output isn't wrong, not just that the tests ran successfully.  We've 
 had garbled output problems in the past, so it would be nice to formalize our 
 tests to catch this.  PigUnit appears to be a good choice for this.

--
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-5694) Allow sstable2json to dump SecondaryIndex SSTables


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

Michał Michalski commented on CASSANDRA-5694:
-

We have and I use it to get proper CF (the given one if it's normal CF or 
parent CF if the given one is index CF) to validate input file name. I use 
StorageService only to instantiate keyspace (errr... Table ;-) ) object in the 
begining, which I later use to getColumnFamilyStore basing on CF name I find in 
filename.

 Allow sstable2json to dump SecondaryIndex SSTables
 --

 Key: CASSANDRA-5694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5694
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Minor
 Attachments: sstable2json-for-2i-v1.txt


 When investigating some 2I problems I had, I was pretty disappointed that 
 sstable2json does not allow me to dump SecondaryIndex, saying that The 
 provided column family is not part of this cassandra database: keyspace = 
 testks, column family = testcf.testcf_col_idx.
 I'm attaching patch that fixes given problem by changing a bit the way that 
 sst2j validates the input file. My only concern is that this solution uses 
 StorageService for validation, so it's a bit heavier than it should, as it 
 has to set everything up.

--
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-5694) Allow sstable2json to dump SecondaryIndex SSTables


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

Michał Michalski commented on CASSANDRA-5694:
-

Argh. Now I see that I can probably just pick keyspace name from filename and 
use Table.open(). Will check it and get back here! ;-)

 Allow sstable2json to dump SecondaryIndex SSTables
 --

 Key: CASSANDRA-5694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5694
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Minor
 Attachments: sstable2json-for-2i-v1.txt


 When investigating some 2I problems I had, I was pretty disappointed that 
 sstable2json does not allow me to dump SecondaryIndex, saying that The 
 provided column family is not part of this cassandra database: keyspace = 
 testks, column family = testcf.testcf_col_idx.
 I'm attaching patch that fixes given problem by changing a bit the way that 
 sst2j validates the input file. My only concern is that this solution uses 
 StorageService for validation, so it's a bit heavier than it should, as it 
 has to set everything up.

--
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-5694) Allow sstable2json to dump SecondaryIndex SSTables


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

Michał Michalski updated CASSANDRA-5694:


Attachment: sstable2json-for-2i-v2.txt

Attaching v2: no StorageService, use Schema.instance.getKsMetaData to check if 
keyspace name is valid and then instantiate Table using Table.open on ksname 
from Descriptor.

 Allow sstable2json to dump SecondaryIndex SSTables
 --

 Key: CASSANDRA-5694
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5694
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Minor
 Attachments: sstable2json-for-2i-v1.txt, sstable2json-for-2i-v2.txt


 When investigating some 2I problems I had, I was pretty disappointed that 
 sstable2json does not allow me to dump SecondaryIndex, saying that The 
 provided column family is not part of this cassandra database: keyspace = 
 testks, column family = testcf.testcf_col_idx.
 I'm attaching patch that fixes given problem by changing a bit the way that 
 sst2j validates the input file. My only concern is that this solution uses 
 StorageService for validation, so it's a bit heavier than it should, as it 
 has to set everything up.

--
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-5234) Table created through CQL3 are not accessble to Pig 0.10

2013-06-24 Thread Alex Liu (JIRA)


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

Alex Liu commented on CASSANDRA-5234:
-

I will fix it today.

 Table created through CQL3 are not accessble to Pig 0.10
 

 Key: CASSANDRA-5234
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5234
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.1
 Environment: Red hat linux 5
Reporter: Shamim Ahmed
Assignee: Alex Liu
 Fix For: 1.2.6

 Attachments: 5234-1-1.2-patch.txt, 5234-1.2-patch.txt, 
 5234-2-1.2branch.txt, 5234.tx


 Hi,
   i have faced a bug when creating table through CQL3 and trying to load data 
 through pig 0.10 as follows:
 java.lang.RuntimeException: Column family 'abc' not found in keyspace 'XYZ'
   at 
 org.apache.cassandra.hadoop.pig.CassandraStorage.initSchema(CassandraStorage.java:1112)
   at 
 org.apache.cassandra.hadoop.pig.CassandraStorage.setLocation(CassandraStorage.java:615).
 This effects from Simple table to table with compound key. 

--
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-5696) Upgrading to cassandra-1.2 with a dead LEFT state from 1.1 causes problems

Brandon Williams created CASSANDRA-5696:
---

 Summary: Upgrading to cassandra-1.2 with a dead LEFT state from 
1.1 causes problems
 Key: CASSANDRA-5696
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5696
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.0
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 1.2.7


In 1.1, we wrote LEFT states as LEFT,token,expiretime in gossip.  However in 
1.2, VersionValue serializes this to LEFT,expiretime,tokens and causes the 
upgrade 1.2 to try and parse it this way as well, causing it to try to parse 
the token as an expiretime.

Another wrinkle to this is assassinate still writes it the old way: 
LEFT,tokens,expiretime.

--
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

[1/3] git commit: allow sstable2json on 2i CFs patch by Michał Michalski; reviewed by jbellis for CASSANDRA-5694

Updated Branches:
  refs/heads/cassandra-1.2 57eb87b57 - 07c627aae
  refs/heads/trunk ab6232aea - a684ee095


allow sstable2json on 2i CFs
patch by MichaÅ Michalski; reviewed by jbellis for CASSANDRA-5694


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

Branch: refs/heads/cassandra-1.2
Commit: 07c627aaed6d381aee79e2e7e388fd115e3cd410
Parents: 57eb87b
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 24 18:00:27 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jun 24 18:00:27 2013 -0700

--
 CHANGES.txt |  1 +
 .../apache/cassandra/tools/SSTableExport.java   | 27 ++--
 2 files changed, 26 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/07c627aa/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 78c630f..be0c1d0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 1.2.7
  * Fix ReadResponseSerializer.serializedSize() for digest reads 
(CASSANDRA-5476)
+ * allow sstable2json on 2i CFs (CASSANDRA-5694)
 
 
 1.2.6

http://git-wip-us.apache.org/repos/asf/cassandra/blob/07c627aa/src/java/org/apache/cassandra/tools/SSTableExport.java
--
diff --git a/src/java/org/apache/cassandra/tools/SSTableExport.java 
b/src/java/org/apache/cassandra/tools/SSTableExport.java
index 1d898ef..c407ca1 100644
--- a/src/java/org/apache/cassandra/tools/SSTableExport.java
+++ b/src/java/org/apache/cassandra/tools/SSTableExport.java
@@ -503,9 +503,32 @@ public class SSTableExport
 
 DatabaseDescriptor.loadSchemas();
 Descriptor descriptor = Descriptor.fromFilename(ssTableFileName);
-if (Schema.instance.getCFMetaData(descriptor) == null)
+
+// Start by validating keyspace name
+if (Schema.instance.getKSMetaData(descriptor.ksname) == null)
+{
+System.err.println(String.format(Filename %s references to 
nonexistent keyspace: %s!,
+ ssTableFileName, 
descriptor.ksname));
+System.exit(1);
+}
+Table table = Table.open(descriptor.ksname);
+
+// Make it work for indexes too - find parent cf if necessary
+String baseName = descriptor.cfname;
+if (descriptor.cfname.contains(.))
+{
+String[] parts = descriptor.cfname.split(\\., 2);
+baseName = parts[0];
+}
+
+// IllegalArgumentException will be thrown here if ks/cf pair does not 
exist
+try
+{
+table.getColumnFamilyStore(baseName);
+}
+catch (IllegalArgumentException e)
 {
-System.err.println(String.format(The provided column family is 
not part of this cassandra database: keyspace = %s, column family = %s,
+System.err.println(String.format(The provided column family is 
not part of this cassandra keyspace: keyspace = %s, column family = %s,
  descriptor.ksname, 
descriptor.cfname));
 System.exit(1);
 }

[jira] [Created] (CASSANDRA-5697) Semi-colons not Allowed in CQL3 Batch Statements

2013-06-24 Thread Russell Alexander Spitzer (JIRA)

Russell Alexander Spitzer created CASSANDRA-5697:


 Summary: Semi-colons not Allowed in CQL3 Batch Statements
 Key: CASSANDRA-5697
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5697
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.2.5
 Environment: Mac OSX, cqlsh 3.0.2
Reporter: Russell Alexander Spitzer


The documentation for BATCH statements declares that semicolons are required 
between update operations. Currently including them results in an error 
'expecting K_APPLY'. To match the design specifications, semi-colons should 
allowed or optional. 



--
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

[2/3] git commit: allow sstable2json on 2i CFs patch by Michał Michalski; reviewed by jbellis for CASSANDRA-5694

allow sstable2json on 2i CFs
patch by MichaÅ Michalski; reviewed by jbellis for CASSANDRA-5694


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

Branch: refs/heads/trunk
Commit: 07c627aaed6d381aee79e2e7e388fd115e3cd410
Parents: 57eb87b
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 24 18:00:27 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jun 24 18:00:27 2013 -0700

--
 CHANGES.txt |  1 +
 .../apache/cassandra/tools/SSTableExport.java   | 27 ++--
 2 files changed, 26 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/07c627aa/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 78c630f..be0c1d0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 1.2.7
  * Fix ReadResponseSerializer.serializedSize() for digest reads 
(CASSANDRA-5476)
+ * allow sstable2json on 2i CFs (CASSANDRA-5694)
 
 
 1.2.6

http://git-wip-us.apache.org/repos/asf/cassandra/blob/07c627aa/src/java/org/apache/cassandra/tools/SSTableExport.java
--
diff --git a/src/java/org/apache/cassandra/tools/SSTableExport.java 
b/src/java/org/apache/cassandra/tools/SSTableExport.java
index 1d898ef..c407ca1 100644
--- a/src/java/org/apache/cassandra/tools/SSTableExport.java
+++ b/src/java/org/apache/cassandra/tools/SSTableExport.java
@@ -503,9 +503,32 @@ public class SSTableExport
 
 DatabaseDescriptor.loadSchemas();
 Descriptor descriptor = Descriptor.fromFilename(ssTableFileName);
-if (Schema.instance.getCFMetaData(descriptor) == null)
+
+// Start by validating keyspace name
+if (Schema.instance.getKSMetaData(descriptor.ksname) == null)
+{
+System.err.println(String.format(Filename %s references to 
nonexistent keyspace: %s!,
+ ssTableFileName, 
descriptor.ksname));
+System.exit(1);
+}
+Table table = Table.open(descriptor.ksname);
+
+// Make it work for indexes too - find parent cf if necessary
+String baseName = descriptor.cfname;
+if (descriptor.cfname.contains(.))
+{
+String[] parts = descriptor.cfname.split(\\., 2);
+baseName = parts[0];
+}
+
+// IllegalArgumentException will be thrown here if ks/cf pair does not 
exist
+try
+{
+table.getColumnFamilyStore(baseName);
+}
+catch (IllegalArgumentException e)
 {
-System.err.println(String.format(The provided column family is 
not part of this cassandra database: keyspace = %s, column family = %s,
+System.err.println(String.format(The provided column family is 
not part of this cassandra keyspace: keyspace = %s, column family = %s,
  descriptor.ksname, 
descriptor.cfname));
 System.exit(1);
 }

[3/3] 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/a684ee09
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a684ee09
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a684ee09

Branch: refs/heads/trunk
Commit: a684ee095d3f706d5126ec19292227fc909353c9
Parents: ab6232a 07c627a
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 24 18:00:34 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jun 24 18:00:34 2013 -0700

--
 CHANGES.txt |  1 +
 .../apache/cassandra/tools/SSTableExport.java   | 27 ++--
 2 files changed, 26 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a684ee09/CHANGES.txt
--
diff --cc CHANGES.txt
index ebcdd4e,be0c1d0..2c43d57
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,72 -1,6 +1,73 @@@
 +2.0
 + * Removed on-heap row cache (CASSANDRA-5348)
 + * use nanotime consistently for node-local timeouts (CASSANDRA-5581)
 + * Avoid unnecessary second pass on name-based queries (CASSANDRA-5577)
 + * Experimental triggers (CASSANDRA-1311)
 + * JEMalloc support for off-heap allocation (CASSANDRA-3997)
 + * Single-pass compaction (CASSANDRA-4180)
 + * Removed token range bisection (CASSANDRA-5518)
 + * Removed compatibility with pre-1.2.5 sstables and network messages
 +   (CASSANDRA-5511)
 + * removed PBSPredictor (CASSANDRA-5455)
 + * CAS support (CASSANDRA-5062, 5441, 5442, 5443, 5619)
 + * Leveled compaction performs size-tiered compactions in L0 
 +   (CASSANDRA-5371, 5439)
 + * Add yaml network topology snitch for mixed ec2/other envs (CASSANDRA-5339)
 + * Log when a node is down longer than the hint window (CASSANDRA-4554)
 + * Optimize tombstone creation for ExpiringColumns (CASSANDRA-4917)
 + * Improve LeveledScanner work estimation (CASSANDRA-5250, 5407)
 + * Replace compaction lock with runWithCompactionsDisabled (CASSANDRA-3430)
 + * Change Message IDs to ints (CASSANDRA-5307)
 + * Move sstable level information into the Stats component, removing the
 +   need for a separate Manifest file (CASSANDRA-4872)
 + * avoid serializing to byte[] on commitlog append (CASSANDRA-5199)
 + * make index_interval configurable per columnfamily (CASSANDRA-3961, 
CASSANDRA-5650)
 + * add default_time_to_live (CASSANDRA-3974)
 + * add memtable_flush_period_in_ms (CASSANDRA-4237)
 + * replace supercolumns internally by composites (CASSANDRA-3237, 5123)
 + * upgrade thrift to 0.9.0 (CASSANDRA-3719)
 + * drop unnecessary keyspace parameter from user-defined compaction API 
 +   (CASSANDRA-5139)
 + * more robust solution to incomplete compactions + counters (CASSANDRA-5151)
 + * Change order of directory searching for c*.in.sh (CASSANDRA-3983)
 + * Add tool to reset SSTable compaction level for LCS (CASSANDRA-5271)
 + * Allow custom configuration loader (CASSANDRA-5045)
 + * Remove memory emergency pressure valve logic (CASSANDRA-3534)
 + * Reduce request latency with eager retry (CASSANDRA-4705)
 + * cqlsh: Remove ASSUME command (CASSANDRA-5331)
 + * Rebuild BF when loading sstables if bloom_filter_fp_chance
 +   has changed since compaction (CASSANDRA-5015)
 + * remove row-level bloom filters (CASSANDRA-4885)
 + * Change Kernel Page Cache skipping into row preheating (disabled by default)
 +   (CASSANDRA-4937)
 + * Improve repair by deciding on a gcBefore before sending
 +   out TreeRequests (CASSANDRA-4932)
 + * Add an official way to disable compactions (CASSANDRA-5074)
 + * Reenable ALTER TABLE DROP with new semantics (CASSANDRA-3919)
 + * Add binary protocol versioning (CASSANDRA-5436)
 + * Swap THshaServer for TThreadedSelectorServer (CASSANDRA-5530)
 + * Add alias support to SELECT statement (CASSANDRA-5075)
 + * Don't create empty RowMutations in CommitLogReplayer (CASSANDRA-5541)
 + * Use range tombstones when dropping cfs/columns from schema (CASSANDRA-5579)
 + * cqlsh: drop CQL2/CQL3-beta support (CASSANDRA-5585)
 + * Track max/min column names in sstables to be able to optimize slice
 +   queries (CASSANDRA-5514, CASSANDRA-5595, CASSANDRA-5600)
 + * Binary protocol: allow batching already prepared statements 
(CASSANDRA-4693)
 + * Allow preparing timestamp, ttl and limit in CQL3 queries (CASSANDRA-4450)
 + * Support native link w/o JNA in Java7 (CASSANDRA-3734)
 + * Use SASL authentication in binary protocol v2 (CASSANDRA-5545)
 + * Replace Thrift HsHa with LMAX Disruptor based implementation 
(CASSANDRA-5582)
 + * cqlsh: Add row count to SELECT output (CASSANDRA-5636)
 + * Include a timestamp with all read commands to determine column expiration
 +   (CASSANDRA-5149)
 + * Streaming 2.0 (CASSANDRA-5286)
 + * Conditional create/drop ks/table/index

[jira] [Updated] (CASSANDRA-5697) Semi-colons not Allowed in CQL3 Batch Statements

2013-06-24 Thread Russell Alexander Spitzer (JIRA)


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

Russell Alexander Spitzer updated CASSANDRA-5697:
-

Description: 
The documentation for BATCH statements declares that semicolons are required 
between update operations. Currently including them results in an error 
'expecting K_APPLY'. To match the design specifications, semi-colons should be 
allowed or optional. 



  was:
The documentation for BATCH statements declares that semicolons are required 
between update operations. Currently including them results in an error 
'expecting K_APPLY'. To match the design specifications, semi-colons should 
allowed or optional. 




 Semi-colons not Allowed in CQL3 Batch Statements
 

 Key: CASSANDRA-5697
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5697
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.2.5
 Environment: Mac OSX, cqlsh 3.0.2
Reporter: Russell Alexander Spitzer
  Labels: cql

 The documentation for BATCH statements declares that semicolons are required 
 between update operations. Currently including them results in an error 
 'expecting K_APPLY'. To match the design specifications, semi-colons should 
 be allowed or optional. 

--
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

[3/3] git commit: merge from 1.2

merge from 1.2


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

Branch: refs/heads/trunk
Commit: 40bc4456fa0228e8a78c6f6edab0b02c38c14389
Parents: a684ee0 81619fe
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 24 18:09:12 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jun 24 18:09:12 2013 -0700

--

--

[2/3] git commit: import

import


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

Branch: refs/heads/trunk
Commit: 81619fe9c6bd8f0ab82837598f72ba49f0afc104
Parents: 07c627a
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 24 18:08:43 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jun 24 18:08:43 2013 -0700

--
 .../apache/cassandra/tools/SSTableExport.java   | 45 
 1 file changed, 9 insertions(+), 36 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/81619fe9/src/java/org/apache/cassandra/tools/SSTableExport.java
--
diff --git a/src/java/org/apache/cassandra/tools/SSTableExport.java 
b/src/java/org/apache/cassandra/tools/SSTableExport.java
index c407ca1..fc64da6 100644
--- a/src/java/org/apache/cassandra/tools/SSTableExport.java
+++ b/src/java/org/apache/cassandra/tools/SSTableExport.java
@@ -17,56 +17,29 @@
  */
 package org.apache.cassandra.tools;
 
-import static org.apache.cassandra.utils.ByteBufferUtil.bytesToHex;
-import static org.apache.cassandra.utils.ByteBufferUtil.hexToBytes;
-
 import java.io.File;
 import java.io.IOException;
 import java.io.PrintStream;
 import java.nio.ByteBuffer;
-import java.util.ArrayList;
-import java.util.Arrays;
-import java.util.Collection;
-import java.util.HashSet;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Set;
-
-import com.google.common.util.concurrent.RateLimiter;
-import org.apache.commons.cli.CommandLine;
-import org.apache.commons.cli.CommandLineParser;
-import org.apache.commons.cli.Option;
-import org.apache.commons.cli.Options;
-import org.apache.commons.cli.ParseException;
-import org.apache.commons.cli.PosixParser;
+import java.util.*;
+
+import org.apache.commons.cli.*;
 
 import org.apache.cassandra.config.CFMetaData;
-import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.config.Schema;
-import org.apache.cassandra.db.AbstractColumnContainer;
-import org.apache.cassandra.db.ColumnFamily;
-import org.apache.cassandra.db.CounterColumn;
-import org.apache.cassandra.db.DecoratedKey;
-import org.apache.cassandra.db.DeletedColumn;
-import org.apache.cassandra.db.DeletionInfo;
-import org.apache.cassandra.db.DeletionTime;
-import org.apache.cassandra.db.ExpiringColumn;
-import org.apache.cassandra.db.IColumn;
-import org.apache.cassandra.db.OnDiskAtom;
-import org.apache.cassandra.db.RangeTombstone;
-import org.apache.cassandra.db.SuperColumn;
+import org.apache.cassandra.db.*;
 import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.dht.IPartitioner;
-import org.apache.cassandra.io.sstable.Descriptor;
-import org.apache.cassandra.io.sstable.KeyIterator;
-import org.apache.cassandra.io.sstable.SSTableIdentityIterator;
-import org.apache.cassandra.io.sstable.SSTableReader;
-import org.apache.cassandra.io.sstable.SSTableScanner;
+import org.apache.cassandra.exceptions.ConfigurationException;
+import org.apache.cassandra.io.sstable.*;
 import org.apache.cassandra.utils.ByteBufferUtil;
 import org.codehaus.jackson.JsonGenerator;
 import org.codehaus.jackson.map.ObjectMapper;
 
+import static org.apache.cassandra.utils.ByteBufferUtil.bytesToHex;
+import static org.apache.cassandra.utils.ByteBufferUtil.hexToBytes;
+
 /**
  * Export SSTables to JSON format.
  */

[1/3] git commit: import

Updated Branches:
  refs/heads/cassandra-1.2 07c627aae - 81619fe9c
  refs/heads/trunk a684ee095 - 40bc4456f


import


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

Branch: refs/heads/cassandra-1.2
Commit: 81619fe9c6bd8f0ab82837598f72ba49f0afc104
Parents: 07c627a
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jun 24 18:08:43 2013 -0700
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jun 24 18:08:43 2013 -0700

--
 .../apache/cassandra/tools/SSTableExport.java   | 45 
 1 file changed, 9 insertions(+), 36 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/81619fe9/src/java/org/apache/cassandra/tools/SSTableExport.java
--
diff --git a/src/java/org/apache/cassandra/tools/SSTableExport.java 
b/src/java/org/apache/cassandra/tools/SSTableExport.java
index c407ca1..fc64da6 100644
--- a/src/java/org/apache/cassandra/tools/SSTableExport.java
+++ b/src/java/org/apache/cassandra/tools/SSTableExport.java
@@ -17,56 +17,29 @@
  */
 package org.apache.cassandra.tools;
 
-import static org.apache.cassandra.utils.ByteBufferUtil.bytesToHex;
-import static org.apache.cassandra.utils.ByteBufferUtil.hexToBytes;
-
 import java.io.File;
 import java.io.IOException;
 import java.io.PrintStream;
 import java.nio.ByteBuffer;
-import java.util.ArrayList;
-import java.util.Arrays;
-import java.util.Collection;
-import java.util.HashSet;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Set;
-
-import com.google.common.util.concurrent.RateLimiter;
-import org.apache.commons.cli.CommandLine;
-import org.apache.commons.cli.CommandLineParser;
-import org.apache.commons.cli.Option;
-import org.apache.commons.cli.Options;
-import org.apache.commons.cli.ParseException;
-import org.apache.commons.cli.PosixParser;
+import java.util.*;
+
+import org.apache.commons.cli.*;
 
 import org.apache.cassandra.config.CFMetaData;
-import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.config.Schema;
-import org.apache.cassandra.db.AbstractColumnContainer;
-import org.apache.cassandra.db.ColumnFamily;
-import org.apache.cassandra.db.CounterColumn;
-import org.apache.cassandra.db.DecoratedKey;
-import org.apache.cassandra.db.DeletedColumn;
-import org.apache.cassandra.db.DeletionInfo;
-import org.apache.cassandra.db.DeletionTime;
-import org.apache.cassandra.db.ExpiringColumn;
-import org.apache.cassandra.db.IColumn;
-import org.apache.cassandra.db.OnDiskAtom;
-import org.apache.cassandra.db.RangeTombstone;
-import org.apache.cassandra.db.SuperColumn;
+import org.apache.cassandra.db.*;
 import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.dht.IPartitioner;
-import org.apache.cassandra.io.sstable.Descriptor;
-import org.apache.cassandra.io.sstable.KeyIterator;
-import org.apache.cassandra.io.sstable.SSTableIdentityIterator;
-import org.apache.cassandra.io.sstable.SSTableReader;
-import org.apache.cassandra.io.sstable.SSTableScanner;
+import org.apache.cassandra.exceptions.ConfigurationException;
+import org.apache.cassandra.io.sstable.*;
 import org.apache.cassandra.utils.ByteBufferUtil;
 import org.codehaus.jackson.JsonGenerator;
 import org.codehaus.jackson.map.ObjectMapper;
 
+import static org.apache.cassandra.utils.ByteBufferUtil.bytesToHex;
+import static org.apache.cassandra.utils.ByteBufferUtil.hexToBytes;
+
 /**
  * Export SSTables to JSON format.
  */

[jira] [Created] (CASSANDRA-5698) Confirm with cqlsh of Cassandra-1.2.5, the behavior of the export/import

2013-06-24 Thread Hiroshi Kise (JIRA)

Hiroshi Kise created CASSANDRA-5698:
---

 Summary: Confirm with cqlsh of Cassandra-1.2.5, the behavior of 
the export/import
 Key: CASSANDRA-5698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5698
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.5
 Environment: Using the Copy of cqlsh, the data included the “{“ and 
“[“ (= CollectionType) case,
I think in the export / import process, data integrity is compromised.

Reporter: Hiroshi Kise


Concrete operation is as follows.
-*-*-*-*-*-*-*-*
(1)map type's export/import
export
[root@castor bin]# ./cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
Use HELP for help.
cqlsh create keyspace maptestks with replication  = { 'class' : 
'SimpleStrategy', 'replication_factor' : '1' };
cqlsh use maptestks;
cqlsh:maptestks create table maptestcf (rowkey varchar PRIMARY KEY, targetmap 
mapvarchar,varchar);
cqlsh:maptestks insert into maptestcf (rowkey, targetmap) values 
('rowkey',{'mapkey':'mapvalue'});
cqlsh:maptestks select * from maptestcf;

 rowkey | targetmap
+
 rowkey | {mapkey: mapvalue}
cqlsh:maptestks  copy maptestcf to 'maptestcf-20130619.txt';
1 rows exported in 0.008 seconds.
cqlsh:maptestks exit;

[root@castor bin]# cat maptestcf-20130619.txt
rowkey,{mapkey: mapvalue}
　　　(a)
import
[root@castor bin]# ./cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
Use HELP for help.
cqlsh create keyspace mapimptestks with replication  = { 'class' : 
'SimpleStrategy', 'replication_factor' : '1' };
cqlsh use mapimptestks;
cqlsh:mapimptestks create table mapimptestcf (rowkey varchar PRIMARY KEY, 
targetmap mapvarchar,varchar);

cqlsh:mapimptestks copy mapimptestcf from ' maptestcf-20130619.txt ';
Bad Request: line 1:83 no viable alternative at input '}'
Aborting import at record #0 (line 1). Previously-inserted values still present.
0 rows imported in 0.025 seconds.
-*-*-*-*-*-*-*-*
(2)list type's export/import
export
[root@castor bin]#./cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
Use HELP for help.
cqlsh create keyspace listtestks with replication  = { 'class' : 
'SimpleStrategy', 'replication_factor' : '1' };
cqlsh use listtestks;
cqlsh:listtestks create table listtestcf (rowkey varchar PRIMARY KEY, value 
listvarchar);
cqlsh:listtestks insert into listtestcf (rowkey,value) values 
('rowkey',['value1','value2']);
cqlsh:listtestks select * from listtestcf;

 rowkey | value
+--
 rowkey | [value1, value2]

cqlsh:listtestks copy listtestcf to 'listtestcf-20130619.txt';
1 rows exported in 0.014 seconds.
cqlsh:listtestks exit;

[root@castor bin]# cat listtestcf-20130619.txt
rowkey,[value1, value2]
　　　(b)
export
[root@castor bin]# ./cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
Use HELP for help.
cqlsh create keyspace listimptestks with replication  = { 'class' : 
'SimpleStrategy', 'replication_factor' : '1' };
cqlsh use listimptestks;
cqlsh:listimptestks create table listimptestcf (rowkey varchar PRIMARY KEY, 
value listvarchar);
cqlsh:listimptestks copy listimptestcf from ' listtestcf-20130619.txt ';
Bad Request: line 1:79 no viable alternative at input ']'
Aborting import at record #0 (line 1). Previously-inserted values still present.
0 rows imported in 0.030 seconds.
-*-*-*-*-*-*-*-*
Reference: (correct, or error, in another dimension)

Manually, I have rewritten the export file.
[root@castor bin]# cat nlisttestcf-20130619.txt
rowkey,['value1',' value2']


cqlsh:listimptestks copy listimptestcf from 'nlisttestcf-20130619.txt';
1 rows imported in 0.035 seconds.

cqlsh:listimptestks select * from implisttestcf;
 rowkey | value
+--
 rowkey | [value1, value2]
cqlsh:implisttestks exit;

[root@castor bin]# cat nmaptestcf-20130619.txt
rowkey,”{'mapkey': 'mapvalue'}”

[root@castor bin]# ./cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
Use HELP for help.
cqlsh use  mapimptestks;
cqlsh:mapimptestks copy mapimptestcf from 'nmaptestcf-20130619.txt';
1 rows imported in 0.023 seconds.
cqlsh:mapimptestks select * from mapimptestcf;

 rowkey | targetmap
+
 rowkey | {mapkey: mapvalue}

(It appears to be as normal processing.)

[jira] [Commented] (CASSANDRA-5691) Remove SimpleCondition

2013-06-24 Thread Mikhail Mazursky (JIRA)

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

Mikhail Mazursky commented on CASSANDRA-5691:
-

I see following reasons to make this change:
1. It removes code that have a bug;
2. It removes code that is not tested;
3. Why invent a wheel? CountDownLatch(1) is a common way to do this kind of
signaling and is widely used and known. So it's easier to understand code.

If the patch is not applied then at least singnal() invocations should be
replaced with signalAll() and signal() should throw
UnsupportedOperationException.

p.s. I don't think CDL offers any better or worse performance.

Remove SimpleCondition
--

Key: CASSANDRA-5691
URL: https://issues.apache.org/jira/browse/CASSANDRA-5691
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Mikhail Mazursky
Priority: Minor
Attachments: trunk-5691.patch

Problematic scenario:
1. two threads get blocked in SimpleCondition.await();
2. some thread calls SimpleCondition.signal();
3. one of blocked threads wakes up and runs;
4. spurious wakeup happens in the second thread and it wakes up too and runs
even though nobody signaled it.
Thus this is a broken implementation of Condition interface.
Anyway, looking at how code uses it, SimpleCondition can just be replaced
with CountDownLatch.

[jira] [Updated] (CASSANDRA-5247) cassandra-cli should exit with error-exit status on all errors which cause it to exit.

2013-06-24 Thread Steve Peters (JIRA)


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

Steve Peters updated CASSANDRA-5247:


Attachment: CASSANDRA-5247.txt

 cassandra-cli should exit with error-exit status on all errors which cause it 
 to exit.
 --

 Key: CASSANDRA-5247
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5247
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.2.1
Reporter: Robert P. Thille
Priority: Minor
  Labels: lhf
 Attachments: CASSANDRA-5247.txt


 running cassandra-cli with a --file argument which does not exist returns 
 success:
 ubuntu@host:~$ cassandra-cli --file does-not-exist ; echo $?
 does-not-exist (No such file or directory)
 0

--
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-5698) Confirm with cqlsh of Cassandra-1.2.5, the behavior of the export/import


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

Jonathan Ellis updated CASSANDRA-5698:
--

  Component/s: Tools
 Priority: Minor  (was: Major)
Affects Version/s: (was: 1.2.5)
   1.1.2
   1.1.3
 Assignee: Aleksey Yeschenko

 Confirm with cqlsh of Cassandra-1.2.5, the behavior of the export/import
 

 Key: CASSANDRA-5698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5698
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.1.2, 1.1.3
 Environment: Using the Copy of cqlsh, the data included the “{“ and 
 “[“ (= CollectionType) case,
 I think in the export / import process, data integrity is compromised.
Reporter: Hiroshi Kise
Assignee: Aleksey Yeschenko
Priority: Minor

 Concrete operation is as follows.
 -*-*-*-*-*-*-*-*
 (1)map type's export/import
 export
 [root@castor bin]# ./cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
 Use HELP for help.
 cqlsh create keyspace maptestks with replication  = { 'class' : 
 'SimpleStrategy', 'replication_factor' : '1' };
 cqlsh use maptestks;
 cqlsh:maptestks create table maptestcf (rowkey varchar PRIMARY KEY, 
 targetmap mapvarchar,varchar);
 cqlsh:maptestks insert into maptestcf (rowkey, targetmap) values 
 ('rowkey',{'mapkey':'mapvalue'});
 cqlsh:maptestks select * from maptestcf;
  rowkey | targetmap
 +
  rowkey | {mapkey: mapvalue}
 cqlsh:maptestks  copy maptestcf to 'maptestcf-20130619.txt';
 1 rows exported in 0.008 seconds.
 cqlsh:maptestks exit;
 [root@castor bin]# cat maptestcf-20130619.txt
 rowkey,{mapkey: mapvalue}
 　　　(a)
 import
 [root@castor bin]# ./cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
 Use HELP for help.
 cqlsh create keyspace mapimptestks with replication  = { 'class' : 
 'SimpleStrategy', 'replication_factor' : '1' };
 cqlsh use mapimptestks;
 cqlsh:mapimptestks create table mapimptestcf (rowkey varchar PRIMARY KEY, 
 targetmap mapvarchar,varchar);
 cqlsh:mapimptestks copy mapimptestcf from ' maptestcf-20130619.txt ';
 Bad Request: line 1:83 no viable alternative at input '}'
 Aborting import at record #0 (line 1). Previously-inserted values still 
 present.
 0 rows imported in 0.025 seconds.
 -*-*-*-*-*-*-*-*
 (2)list type's export/import
 export
 [root@castor bin]#./cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
 Use HELP for help.
 cqlsh create keyspace listtestks with replication  = { 'class' : 
 'SimpleStrategy', 'replication_factor' : '1' };
 cqlsh use listtestks;
 cqlsh:listtestks create table listtestcf (rowkey varchar PRIMARY KEY, value 
 listvarchar);
 cqlsh:listtestks insert into listtestcf (rowkey,value) values 
 ('rowkey',['value1','value2']);
 cqlsh:listtestks select * from listtestcf;
  rowkey | value
 +--
  rowkey | [value1, value2]
 cqlsh:listtestks copy listtestcf to 'listtestcf-20130619.txt';
 1 rows exported in 0.014 seconds.
 cqlsh:listtestks exit;
 [root@castor bin]# cat listtestcf-20130619.txt
 rowkey,[value1, value2]
 　　　(b)
 export
 [root@castor bin]# ./cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 3.0.2 | Cassandra 1.2.5 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
 Use HELP for help.
 cqlsh create keyspace listimptestks with replication  = { 'class' : 
 'SimpleStrategy', 'replication_factor' : '1' };
 cqlsh use listimptestks;
 cqlsh:listimptestks create table listimptestcf (rowkey varchar PRIMARY KEY, 
 value listvarchar);
 cqlsh:listimptestks copy listimptestcf from ' listtestcf-20130619.txt ';
 Bad Request: line 1:79 no viable alternative at input ']'
 Aborting import at record #0 (line 1). Previously-inserted values still 
 present.
 0 rows imported in 0.030 seconds.
 -*-*-*-*-*-*-*-*
 Reference: (correct, or error, in another dimension)
 Manually, I have rewritten the export file.
 [root@castor bin]# cat nlisttestcf-20130619.txt
 rowkey,['value1',' value2']
 
 cqlsh:listimptestks copy listimptestcf from 'nlisttestcf-20130619.txt';
 1 rows imported in 0.035 seconds.
 cqlsh:listimptestks select * from implisttestcf;
  rowkey | value
 +--
  rowkey | [value1, value2]
 cqlsh:implisttestks exit;

[jira] [Updated] (CASSANDRA-5697) Semi-colons not Allowed in CQL3 Batch Statements


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

Jonathan Ellis updated CASSANDRA-5697:
--

 Priority: Minor  (was: Major)
Affects Version/s: (was: 1.2.5)
   1.2.0
 Assignee: Aleksey Yeschenko

The grammar suggests that it was intended for semicolon to be optional.  I 
guess some kind of antlr nondeterminism makes it not work as designed?

 Semi-colons not Allowed in CQL3 Batch Statements
 

 Key: CASSANDRA-5697
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5697
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.2.0
 Environment: Mac OSX, cqlsh 3.0.2
Reporter: Russell Alexander Spitzer
Assignee: Aleksey Yeschenko
Priority: Minor
  Labels: cql

 The documentation for BATCH statements declares that semicolons are required 
 between update operations. Currently including them results in an error 
 'expecting K_APPLY'. To match the design specifications, semi-colons should 
 be allowed or optional. 

--
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-5691) Remove SimpleCondition