[jira] [Commented] (CASSANDRA-6106) QueryState.getTimestamp() FBUtilities.timestampMicros() reads current timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000
[ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13955602#comment-13955602 ] Blair Zajac commented on CASSANDRA-6106: Yes, I called gettimeofday() with JNA for a previous employer on a closed source project, otherwise I would copy/paste it here. QueryState.getTimestamp() FBUtilities.timestampMicros() reads current timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000 Key: CASSANDRA-6106 URL: https://issues.apache.org/jira/browse/CASSANDRA-6106 Project: Cassandra Issue Type: Improvement Components: Core Environment: DSE Cassandra 3.1, but also HEAD Reporter: Christopher Smith Assignee: Benedict Priority: Minor Labels: timestamps Fix For: 2.1 beta2 Attachments: microtimstamp.patch, microtimstamp_random.patch, microtimstamp_random_rev2.patch I noticed this blog post: http://aphyr.com/posts/294-call-me-maybe-cassandra mentioned issues with millisecond rounding in timestamps and was able to reproduce the issue. If I specify a timestamp in a mutating query, I get microsecond precision, but if I don't, I get timestamps rounded to the nearest millisecond, at least for my first query on a given connection, which substantially increases the possibilities of collision. I believe I found the offending code, though I am by no means sure this is comprehensive. I think we probably need a fairly comprehensive replacement of all uses of System.currentTimeMillis() with System.nanoTime(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6290) Switch to JDK7's StandardCharsets
[ https://issues.apache.org/jira/browse/CASSANDRA-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blair Zajac updated CASSANDRA-6290: --- Attachment: guava-charsets-to-jdk7-standardcharsets.patch.txt Second patch that switches from Google Guava's Charsets to JDK7's StandardCharsets. Switch to JDK7's StandardCharsets - Key: CASSANDRA-6290 URL: https://issues.apache.org/jira/browse/CASSANDRA-6290 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Blair Zajac Priority: Minor Attachments: guava-charsets-to-jdk7-standardcharsets.patch.txt, standard-charsets.patch.txt Instead of using Charset.forName() take advantage of JDK7's StandardCharsets that provides UTF-8 and US-ASCII character sets as static fields. http://docs.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CASSANDRA-6290) Switch to JDK7's StandardCharsets
Blair Zajac created CASSANDRA-6290: -- Summary: Switch to JDK7's StandardCharsets Key: CASSANDRA-6290 URL: https://issues.apache.org/jira/browse/CASSANDRA-6290 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Blair Zajac Priority: Minor Instead of using Charset.forName() take advantage of JDK7's StandardCharsets that provides UTF-8 and US-ASCII character sets as static fields. http://docs.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6290) Switch to JDK7's StandardCharsets
[ https://issues.apache.org/jira/browse/CASSANDRA-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blair Zajac updated CASSANDRA-6290: --- Attachment: standard-charsets.patch.txt This is against cassandra-2.0 branch. Switch to JDK7's StandardCharsets - Key: CASSANDRA-6290 URL: https://issues.apache.org/jira/browse/CASSANDRA-6290 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Blair Zajac Priority: Minor Attachments: standard-charsets.patch.txt Instead of using Charset.forName() take advantage of JDK7's StandardCharsets that provides UTF-8 and US-ASCII character sets as static fields. http://docs.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6106) QueryState.getTimestamp() FBUtilities.timestampMicros() reads current timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000
[ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13784825#comment-13784825 ] Blair Zajac commented on CASSANDRA-6106: Since Cassandra ships with JNA, one could use it to wrap gettimeofday() or maybe clock_gettime() for Unix systems and the equivalent for Windows. I did this for an internal Scala server \that needed microsecond precision. One question is is the Windows equivalent is too expensive. Looking at APR's code for getting microsecond time on Windows doesn't look cheap, look at apr_time_now() here:tw https://svn.apache.org/repos/asf/apr/apr/trunk/time/win32/time.c QueryState.getTimestamp() FBUtilities.timestampMicros() reads current timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000 Key: CASSANDRA-6106 URL: https://issues.apache.org/jira/browse/CASSANDRA-6106 Project: Cassandra Issue Type: Bug Components: Core Environment: DSE Cassandra 3.1, but also HEAD Reporter: Christopher Smith Priority: Minor Labels: collision, conflict, timestamp Attachments: microtimstamp.patch, microtimstamp_random.patch, microtimstamp_random_rev2.patch I noticed this blog post: http://aphyr.com/posts/294-call-me-maybe-cassandra mentioned issues with millisecond rounding in timestamps and was able to reproduce the issue. If I specify a timestamp in a mutating query, I get microsecond precision, but if I don't, I get timestamps rounded to the nearest millisecond, at least for my first query on a given connection, which substantially increases the possibilities of collision. I believe I found the offending code, though I am by no means sure this is comprehensive. I think we probably need a fairly comprehensive replacement of all uses of System.currentTimeMillis() with System.nanoTime(). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CASSANDRA-6034) Java Driver 2.0.0-beta1 dri
Blair Zajac created CASSANDRA-6034: -- Summary: Java Driver 2.0.0-beta1 dri Key: CASSANDRA-6034 URL: https://issues.apache.org/jira/browse/CASSANDRA-6034 Project: Cassandra Issue Type: Bug Reporter: Blair Zajac -- 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-6035) ArrayIndexOutOfBoundsException triggered by Java Driver 2.0.0-beta with CREATE KEYSPACE
[
https://issues.apache.org/jira/browse/CASSANDRA-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blair Zajac updated CASSANDRA-6035:
---
Description:
Pulling this ticket over from:
https://datastax-oss.atlassian.net/browse/JAVA-177
Using Java Driver 2.0.0-beta1, this fails:
{code}
Session#prepareStatement(CREATE KEYSPACE test WITH replication = {'class':
'SimpleStrategy', 'replication_factor': 3})
{code}
This works with Java Driver 1.0.3.
The client side stack:
{code}
Caused by: com.datastax.driver.core.exceptions.DriverInternalError: An
unexpected error occured server side on /127.0.0.3:
java.lang.ArrayIndexOutOfBoundsException: 30
at
com.datastax.driver.core.Responses$Error.asException(Responses.java:85)
at
com.datastax.driver.core.Session.toPreparedStatement(Session.java:281)
at com.datastax.driver.core.Session.prepare(Session.java:187)
{code}
The server side stack:
{code}
INFO [FlushWriter:16] 2013-09-14 00:41:02,882 Memtable.java (line 422)
Completed flushing /home/blair/.ccm/cassandra-2.0.0-168-gd2c67a1/node3
/data/system/local/system-local-jb-127-Data.db (80 bytes) for commitlog
position ReplayPosition(segmentId=1379132442754, position=712508)
INFO [CompactionExecutor:69] 2013-09-14 01:20:42,701 AutoSavingCache.java
(line 250) Saved KeyCache (325 items) in 255 ms
INFO [CompactionExecutor:70] 2013-09-14 05:20:42,665 AutoSavingCache.java
(line 250) Saved KeyCache (325 items) in 218 ms
INFO [CompactionExecutor:71] 2013-09-14 09:20:42,678 AutoSavingCache.java
(line 250) Saved KeyCache (325 items) in 217 ms
ERROR [Native-Transport-Requests:3009] 2013-09-14 10:53:38,724
ErrorMessage.java (line 222) Unexpected exception during request
java.lang.ArrayIndexOutOfBoundsException: 30
at
org.jboss.netty.buffer.BigEndianHeapChannelBuffer.setInt(BigEndianHeapChannelBuffer.java:98)
at
org.jboss.netty.buffer.AbstractChannelBuffer.writeInt(AbstractChannelBuffer.java:422)
at
org.apache.cassandra.cql3.ResultSet$Metadata$Codec.encode(ResultSet.java:368)
at
org.apache.cassandra.cql3.ResultSet$Metadata$Codec.encode(ResultSet.java:320)
at
org.apache.cassandra.transport.messages.ResultMessage$Prepared$1.encode(ResultMessage.java:261)
at
org.apache.cassandra.transport.messages.ResultMessage$Prepared$1.encode(ResultMessage.java:239)
at
org.apache.cassandra.transport.messages.ResultMessage$1.encode(ResultMessage.java:49)
at
org.apache.cassandra.transport.messages.ResultMessage$1.encode(ResultMessage.java:39)
at
org.apache.cassandra.transport.Message$ProtocolEncoder.encode(Message.java:279)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:66)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
at
org.jboss.netty.handler.execution.ExecutionHandler.handleDownstream(ExecutionHandler.java:186)
at org.jboss.netty.channel.Channels.write(Channels.java:704)
at org.jboss.netty.channel.Channels.write(Channels.java:671)
at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:311)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
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}
was:
Pulling this ticket over from:
https://datastax-oss.atlassian.net/browse/JAVA-177
Using
{code}
Session#prepareStatement(CREATE KEYSPACE test WITH replication = {'class':
'SimpleStrategy', 'replication_factor': 3})
{code}
Client side stack:
{code}
Caused by: com.datastax.driver.core.exceptions.DriverInternalError: An
unexpected error occured server side on /127.0.0.3:
java.lang.ArrayIndexOutOfBoundsException: 30
at
com.datastax.driver.core.Responses$Error.asException(Responses.java:85)
at
com.datastax.driver.core.Session.toPreparedStatement(Session.java:281)
at com.datastax.driver.core.Session.prepare(Session.java:187)
{code}
{code}
INFO [FlushWriter:16] 2013-09-14 00:41:02,882 Memtable.java (line 422)
Completed flushing /home/blair/.ccm/cassandra-2.0.0-168-gd2c67a1/node3
/data/system/local/system-local-jb-127-Data.db (80 bytes) for commitlog
position ReplayPosition(segmentId=1379132442754, position=712508)
INFO [CompactionExecutor:69] 2013-09-14 01:20:42,701 AutoSavingCache.java
(line 250) Saved KeyCache (325 items) in 255 ms
INFO [CompactionExecutor:70] 2013-09-14 05:20:42,665 AutoSavingCache.java
(line 250) Saved KeyCache
[jira] [Commented] (CASSANDRA-6034) Java Driver 2.0.0-beta1 dri
[ https://issues.apache.org/jira/browse/CASSANDRA-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768613#comment-13768613 ] Blair Zajac commented on CASSANDRA-6034: Sorry about this, will close. Opened for real in https://issues.apache.org/jira/browse/CASSANDRA-6035 . Java Driver 2.0.0-beta1 dri --- Key: CASSANDRA-6034 URL: https://issues.apache.org/jira/browse/CASSANDRA-6034 Project: Cassandra Issue Type: Bug Reporter: Blair Zajac -- 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-6035) ArrayIndexOutOfBoundsException triggered by Java Driver 2.0.0-beta with CREATE KEYSPACE
Blair Zajac created CASSANDRA-6035:
--
Summary: ArrayIndexOutOfBoundsException triggered by Java Driver
2.0.0-beta with CREATE KEYSPACE
Key: CASSANDRA-6035
URL: https://issues.apache.org/jira/browse/CASSANDRA-6035
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Ubuntu 13.04 with JDK 7u40 using ccm and the the
cassandra-2.0 branch at d2c67a1cb95264e8a839bdcfc0a727c892f1fc1d.
Reporter: Blair Zajac
Pulling this ticket over from:
https://datastax-oss.atlassian.net/browse/JAVA-177
Using
{code}
Session#prepareStatement(CREATE KEYSPACE test WITH replication = {'class':
'SimpleStrategy', 'replication_factor': 3})
{code}
Client side stack:
{code}
Caused by: com.datastax.driver.core.exceptions.DriverInternalError: An
unexpected error occured server side on /127.0.0.3:
java.lang.ArrayIndexOutOfBoundsException: 30
at
com.datastax.driver.core.Responses$Error.asException(Responses.java:85)
at
com.datastax.driver.core.Session.toPreparedStatement(Session.java:281)
at com.datastax.driver.core.Session.prepare(Session.java:187)
{code}
{code}
INFO [FlushWriter:16] 2013-09-14 00:41:02,882 Memtable.java (line 422)
Completed flushing /home/blair/.ccm/cassandra-2.0.0-168-gd2c67a1/node3
/data/system/local/system-local-jb-127-Data.db (80 bytes) for commitlog
position ReplayPosition(segmentId=1379132442754, position=712508)
INFO [CompactionExecutor:69] 2013-09-14 01:20:42,701 AutoSavingCache.java
(line 250) Saved KeyCache (325 items) in 255 ms
INFO [CompactionExecutor:70] 2013-09-14 05:20:42,665 AutoSavingCache.java
(line 250) Saved KeyCache (325 items) in 218 ms
INFO [CompactionExecutor:71] 2013-09-14 09:20:42,678 AutoSavingCache.java
(line 250) Saved KeyCache (325 items) in 217 ms
ERROR [Native-Transport-Requests:3009] 2013-09-14 10:53:38,724
ErrorMessage.java (line 222) Unexpected exception during request
java.lang.ArrayIndexOutOfBoundsException: 30
at
org.jboss.netty.buffer.BigEndianHeapChannelBuffer.setInt(BigEndianHeapChannelBuffer.java:98)
at
org.jboss.netty.buffer.AbstractChannelBuffer.writeInt(AbstractChannelBuffer.java:422)
at
org.apache.cassandra.cql3.ResultSet$Metadata$Codec.encode(ResultSet.java:368)
at
org.apache.cassandra.cql3.ResultSet$Metadata$Codec.encode(ResultSet.java:320)
at
org.apache.cassandra.transport.messages.ResultMessage$Prepared$1.encode(ResultMessage.java:261)
at
org.apache.cassandra.transport.messages.ResultMessage$Prepared$1.encode(ResultMessage.java:239)
at
org.apache.cassandra.transport.messages.ResultMessage$1.encode(ResultMessage.java:49)
at
org.apache.cassandra.transport.messages.ResultMessage$1.encode(ResultMessage.java:39)
at
org.apache.cassandra.transport.Message$ProtocolEncoder.encode(Message.java:279)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:66)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
at
org.jboss.netty.handler.execution.ExecutionHandler.handleDownstream(ExecutionHandler.java:186)
at org.jboss.netty.channel.Channels.write(Channels.java:704)
at org.jboss.netty.channel.Channels.write(Channels.java:671)
at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:311)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
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
[jira] [Resolved] (CASSANDRA-6034) Java Driver 2.0.0-beta1 dri
[ https://issues.apache.org/jira/browse/CASSANDRA-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blair Zajac resolved CASSANDRA-6034. Resolution: Invalid Early click on the web form. Java Driver 2.0.0-beta1 dri --- Key: CASSANDRA-6034 URL: https://issues.apache.org/jira/browse/CASSANDRA-6034 Project: Cassandra Issue Type: Bug Reporter: Blair Zajac -- 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] [Reopened] (CASSANDRA-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
[
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blair Zajac reopened CASSANDRA-5816:
Reproduced In: 2.0
Since Version: 2.0
Looking at DataStax's 2.0.0 Debian packages, the change didn't make its way in.
Digging deeper, it's only on the cassandra-1.2 branch. Can someone
merge/cherry-pick it to cassandra-2.0 and trunk.
Thanks,
Blair
[PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
---
Key: CASSANDRA-5816
URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
Fix For: 1.2.9, 2.0 rc1
I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the
reasons cited here when Fedora made the switch to have chrony be the default
NTP client:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Currently, the debian packaging recommends only ntp so if chrony is installed
it'll want to remove it and install ntp. I also added ptpd, the Precision
Time Protocol daemon, which is another time syncing server for completeness.
Please apply this to the 1.2 branch so the next 1.2.x release can deploy with
chrony.
Below is the patch since it's a one-liner.
Thanks,
Blair
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ 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}
-Recommends: ntp
+Recommends: chrony | ntp | ptpd
Conflicts: apache-cassandra1
Replaces: apache-cassandra1
Description: distributed storage system for structured data
--
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-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
[
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759778#comment-13759778
]
Blair Zajac commented on CASSANDRA-5816:
No problem. Thank you!
[PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
---
Key: CASSANDRA-5816
URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
Fix For: 1.2.9, 2.0.1
I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the
reasons cited here when Fedora made the switch to have chrony be the default
NTP client:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Currently, the debian packaging recommends only ntp so if chrony is installed
it'll want to remove it and install ntp. I also added ptpd, the Precision
Time Protocol daemon, which is another time syncing server for completeness.
Please apply this to the 1.2 branch so the next 1.2.x release can deploy with
chrony.
Below is the patch since it's a one-liner.
Thanks,
Blair
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ 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}
-Recommends: ntp
+Recommends: chrony | ntp | ptpd
Conflicts: apache-cassandra1
Replaces: apache-cassandra1
Description: distributed storage system for structured data
--
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-5715) CAS on 'primary key only' table
[
https://issues.apache.org/jira/browse/CASSANDRA-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13724409#comment-13724409
]
Blair Zajac commented on CASSANDRA-5715:
This ticket is marked as resolved. Open a new one to track DELETE?
CAS on 'primary key only' table
---
Key: CASSANDRA-5715
URL: https://issues.apache.org/jira/browse/CASSANDRA-5715
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 2.0 beta 2
Attachments: 0001-Conditions-on-INSERT.txt,
0002-Support-updating-the-PK-only.txt, 5715-v2.txt
Given a table with only a primary key, like
{noformat}
CREATE TABLE test (k int PRIMARY KEY)
{noformat}
there is currently no way to CAS a row in that table into existing because:
# INSERT doesn't currently support IF
# UPDATE has no way to update such table
So we should probably allow IF conditions on INSERT statements.
In addition (or alternatively), we could work on allowing UPDATE to update
such table. One motivation for that could be to make UPDATE always be more
general to INSERT. That is currently, there is a bunch of operation that
INSERT cannot do (counter increments, collection appends), but that primary
key table case is, afaik, the only case where you *need* to use INSERT.
However, because CQL forces segregation of PK value to the WHERE clause and
not to the SET one, the only syntax that I can see work would be:
{noformat}
UPDATE WHERE k=0;
{noformat}
which maybe is too ugly to allow?
--
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-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
[
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13724436#comment-13724436
]
Blair Zajac commented on CASSANDRA-5816:
Thank you guys, I greatly appreciate it!
[PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
---
Key: CASSANDRA-5816
URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
Fix For: 2.0 rc1, 1.2.9
I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the
reasons cited here when Fedora made the switch to have chrony be the default
NTP client:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Currently, the debian packaging recommends only ntp so if chrony is installed
it'll want to remove it and install ntp. I also added ptpd, the Precision
Time Protocol daemon, which is another time syncing server for completeness.
Please apply this to the 1.2 branch so the next 1.2.x release can deploy with
chrony.
Below is the patch since it's a one-liner.
Thanks,
Blair
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ 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}
-Recommends: ntp
+Recommends: chrony | ntp | ptpd
Conflicts: apache-cassandra1
Replaces: apache-cassandra1
Description: distributed storage system for structured data
--
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-5715) CAS on 'primary key only' table
[
https://issues.apache.org/jira/browse/CASSANDRA-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13724435#comment-13724435
]
Blair Zajac commented on CASSANDRA-5715:
Thanks. https://issues.apache.org/jira/browse/CASSANDRA-5832
CAS on 'primary key only' table
---
Key: CASSANDRA-5715
URL: https://issues.apache.org/jira/browse/CASSANDRA-5715
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 2.0 beta 2
Attachments: 0001-Conditions-on-INSERT.txt,
0002-Support-updating-the-PK-only.txt, 5715-v2.txt
Given a table with only a primary key, like
{noformat}
CREATE TABLE test (k int PRIMARY KEY)
{noformat}
there is currently no way to CAS a row in that table into existing because:
# INSERT doesn't currently support IF
# UPDATE has no way to update such table
So we should probably allow IF conditions on INSERT statements.
In addition (or alternatively), we could work on allowing UPDATE to update
such table. One motivation for that could be to make UPDATE always be more
general to INSERT. That is currently, there is a bunch of operation that
INSERT cannot do (counter increments, collection appends), but that primary
key table case is, afaik, the only case where you *need* to use INSERT.
However, because CQL forces segregation of PK value to the WHERE clause and
not to the SET one, the only syntax that I can see work would be:
{noformat}
UPDATE WHERE k=0;
{noformat}
which maybe is too ugly to allow?
--
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-5832) DELETE CAS on 'primary key only' table
Blair Zajac created CASSANDRA-5832: -- Summary: DELETE CAS on 'primary key only' table Key: CASSANDRA-5832 URL: https://issues.apache.org/jira/browse/CASSANDRA-5832 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 2 Reporter: Blair Zajac Priority: Minor Following up on the CAS on 'primary key only' table issue [1] which added support for atomically creating a primary key only table, this ticket is requesting support for a CAS DELETE of a row from such a table. Currently these two different statements fail: Trying DELETE FROM test1 WHERE k = 456 IF EXISTS using cassandra-dbapi2: cql.apivalues.ProgrammingError: Bad Request: line 0:-1 no viable alternative at input 'EOF' Trying DELETE FROM test1 WHERE k = 456 IF k = 456 cql.apivalues.ProgrammingError: Bad Request: PRIMARY KEY part k found in SET part [1] https://issues.apache.org/jira/browse/CASSANDRA-5715 -- 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-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
[
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722847#comment-13722847
]
Blair Zajac commented on CASSANDRA-5816:
A few points on closing this ticket:
1) I'm new to contributing to the Cassandra eco-system, Java-driver, etc, so I
would appreciate a one line change instead of just closing a ticket which is
good at pissing people off (I don't think there's anything more upsetting then
closing tickets that don't need to be closed), especially new contributors that
want to make a difference. Make it so that contributions get into the project
will have people continue to contribute, even if the change is simple. I'm a
MacPorts packager and not every change somebody requests is something I need,
but I make the change to the package to make it easier for other people [1].
2) This change makes it easier to deploy Cassandra than have to deal with a
one-off change to have apt ignore recommendations.
3) In 7 years of deploying Ubuntu systems I haven't needed to learn about
changing recommendations, so make the package work with the standards that
other packages do.
Thanks,
Blair
[1] https://trac.macports.org/ticket/39793
[PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
---
Key: CASSANDRA-5816
URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the
reasons cited here when Fedora made the switch to have chrony be the default
NTP client:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Currently, the debian packaging recommends only ntp so if chrony is installed
it'll want to remove it and install ntp. I also added ptpd, the Precision
Time Protocol daemon, which is another time syncing server for completeness.
Please apply this to the 1.2 branch so the next 1.2.x release can deploy with
chrony.
Below is the patch since it's a one-liner.
Thanks,
Blair
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ 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}
-Recommends: ntp
+Recommends: chrony | ntp | ptpd
Conflicts: apache-cassandra1
Replaces: apache-cassandra1
Description: distributed storage system for structured data
--
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-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
[
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722904#comment-13722904
]
Blair Zajac commented on CASSANDRA-5816:
The issue I have is that the cassandra package wants to uninstall chrony for
ntp. Here's a pristine Ubuntu 12.04.2 VM launched in OpenStack that adds
DataStax's repo, installs chrony and then tries to install cassandra.
{code}
root@server-2057c48c-24d1-40d1-b9b7-7b65890a5e56:~# curl
http://debian.datastax.com/debian/repo_key | apt-key add -
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 2922 100 29220 0 18918 0 --:--:-- --:--:-- --:--:-- 36987
OK
root@server-2057c48c-24d1-40d1-b9b7-7b65890a5e56:/etc/apt/sources.list.d# echo
deb http://debian.datastax.com/community stable main
/etc/apt/sources.list.d/datastax.list
root@server-2057c48c-24d1-40d1-b9b7-7b65890a5e56:/etc/apt/sources.list.d#
apt-get update
Get:1 http://debian.datastax.com stable Release.gpg [287 B]
Get:2 http://debian.datastax.com stable Release [2,870 B]
Get:3 http://security.ubuntu.com precise-security Release.gpg [198 B]
Get:4 http://debian.datastax.com stable/main amd64 Packages [8,844 B]
Get:5 http://security.ubuntu.com precise-security Release [49.6 kB]
Get:6 http://debian.datastax.com stable/main i386 Packages [8,835 B]
Hit http://nova.clouds.archive.ubuntu.com precise Release.gpg
Ign http://debian.datastax.com stable/main TranslationIndex
Get:7 http://nova.clouds.archive.ubuntu.com precise-updates Release.gpg [198 B]
Get:8 http://security.ubuntu.com precise-security/main Sources [83.7 kB]
Hit http://nova.clouds.archive.ubuntu.com precise Release
Get:9 http://nova.clouds.archive.ubuntu.com precise-updates Release [49.6 kB]
Get:10 http://security.ubuntu.com precise-security/universe Sources [27.6 kB]
Get:11 http://security.ubuntu.com precise-security/main amd64 Packages [301 kB]
Ign http://debian.datastax.com stable/main Translation-en_US
Ign http://debian.datastax.com stable/main Translation-en
Get:12 http://nova.clouds.archive.ubuntu.com precise/main Sources [934 kB]
Get:13 http://security.ubuntu.com precise-security/universe amd64 Packages
[80.2 kB]
Get:14 http://security.ubuntu.com precise-security/main i386 Packages [316 kB]
Get:15 http://security.ubuntu.com precise-security/universe i386 Packages [83.1
kB]
Get:16 http://security.ubuntu.com precise-security/main TranslationIndex [74 B]
Get:17 http://security.ubuntu.com precise-security/universe TranslationIndex
[73 B]
Get:18 http://security.ubuntu.com precise-security/main Translation-en [146 kB]
Get:19 http://security.ubuntu.com precise-security/universe Translation-en
[51.1 kB]
Get:20 http://nova.clouds.archive.ubuntu.com precise/universe Sources [5,019 kB]
Hit http://nova.clouds.archive.ubuntu.com precise/main amd64 Packages
Hit http://nova.clouds.archive.ubuntu.com precise/universe amd64 Packages
Hit http://nova.clouds.archive.ubuntu.com precise/main i386 Packages
Hit http://nova.clouds.archive.ubuntu.com precise/universe i386 Packages
Hit http://nova.clouds.archive.ubuntu.com precise/main TranslationIndex
Hit http://nova.clouds.archive.ubuntu.com precise/universe TranslationIndex
Get:21 http://nova.clouds.archive.ubuntu.com precise-updates/main Sources [411
kB]
Get:22 http://nova.clouds.archive.ubuntu.com precise-updates/universe Sources
[93.4 kB]
Get:23 http://nova.clouds.archive.ubuntu.com precise-updates/main amd64
Packages [668 kB]
Get:24 http://nova.clouds.archive.ubuntu.com precise-updates/universe amd64
Packages [211 kB]
Get:25 http://nova.clouds.archive.ubuntu.com precise-updates/main i386 Packages
[689 kB]
Get:26 http://nova.clouds.archive.ubuntu.com precise-updates/universe i386
Packages [214 kB]
Get:27 http://nova.clouds.archive.ubuntu.com precise-updates/main
TranslationIndex [3,564 B]
Get:28 http://nova.clouds.archive.ubuntu.com precise-updates/universe
TranslationIndex [2,850 B]
Hit http://nova.clouds.archive.ubuntu.com precise/main Translation-en
Hit http://nova.clouds.archive.ubuntu.com precise/universe Translation-en
Get:29 http://nova.clouds.archive.ubuntu.com precise-updates/main
Translation-en [303 kB]
Get:30 http://nova.clouds.archive.ubuntu.com precise-updates/universe
Translation-en [124 kB]
Fetched 9,882 kB in 12s (794 kB/s)
Reading package lists... Done
root@server-2057c48c-24d1-40d1-b9b7-7b65890a5e56:/etc/apt/sources.list.d#
apt-get install chrony
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
timelimit
The following
[jira] [Commented] (CASSANDRA-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
[
https://issues.apache.org/jira/browse/CASSANDRA-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723099#comment-13723099
]
Blair Zajac commented on CASSANDRA-5816:
We're using ansible [1] to do our installs into EC2 so we have a 'base'
playbook that does a minimal install of required packages, which includes
chrony, and then a 'cassandra' playbook deploys Cassandra on top of the base
install, so the package install order is fixed.
So there are multiple ways to skin the cat; I just prefer to update Cassandra's
packaging.
Are you removing your -1 then and giving the go-ahead to add ntp |
time-daemon?
[PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
---
Key: CASSANDRA-5816
URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Assignee: Blair Zajac
Priority: Minor
I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the
reasons cited here when Fedora made the switch to have chrony be the default
NTP client:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Currently, the debian packaging recommends only ntp so if chrony is installed
it'll want to remove it and install ntp. I also added ptpd, the Precision
Time Protocol daemon, which is another time syncing server for completeness.
Please apply this to the 1.2 branch so the next 1.2.x release can deploy with
chrony.
Below is the patch since it's a one-liner.
Thanks,
Blair
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ 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}
-Recommends: ntp
+Recommends: chrony | ntp | ptpd
Conflicts: apache-cassandra1
Replaces: apache-cassandra1
Description: distributed storage system for structured data
--
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-5816) [PATCH] Debian packaging: also recommend chrony and ptpd in addition to ntp
Blair Zajac created CASSANDRA-5816:
--
Summary: [PATCH] Debian packaging: also recommend chrony and ptpd
in addition to ntp
Key: CASSANDRA-5816
URL: https://issues.apache.org/jira/browse/CASSANDRA-5816
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Affects Versions: 1.2.7
Reporter: Blair Zajac
Priority: Minor
I'm switching my Ubuntu servers running Cassandra from ntp to chrony for the
reasons cited here when Fedora made the switch to have chrony be the default
NTP client:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Currently, the debian packaging recommends only ntp so if chrony is installed
it'll want to remove it and install ntp. I also added ptpd, the Precision Time
Protocol daemon, which is another time syncing server for completeness.
Please apply this to the 1.2 branch so the next 1.2.x release can deploy with
chrony.
Below is the patch since it's a one-liner.
Thanks,
Blair
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ 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}
-Recommends: ntp
+Recommends: chrony | ntp | ptpd
Conflicts: apache-cassandra1
Replaces: apache-cassandra1
Description: distributed storage system for structured data
--
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-5715) CAS on 'primary key only' table
[
https://issues.apache.org/jira/browse/CASSANDRA-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13721071#comment-13721071
]
Blair Zajac commented on CASSANDRA-5715:
Thanks for getting this in.
Is there syntax to support deleting the row with CAS? Is a CAS delete even
necessary?
Trying DELETE FROM test1 WHERE k = 456 IF EXISTS using cassandra-dbapi2:
cql.apivalues.ProgrammingError: Bad Request: line 0:-1 no viable alternative at
input 'EOF'
Trying DELETE FROM test1 WHERE k = 456 IF k = 456
cql.apivalues.ProgrammingError: Bad Request: PRIMARY KEY part k found in SET
part
CAS on 'primary key only' table
---
Key: CASSANDRA-5715
URL: https://issues.apache.org/jira/browse/CASSANDRA-5715
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 2.0 beta 2
Attachments: 0001-Conditions-on-INSERT.txt,
0002-Support-updating-the-PK-only.txt, 5715-v2.txt
Given a table with only a primary key, like
{noformat}
CREATE TABLE test (k int PRIMARY KEY)
{noformat}
there is currently no way to CAS a row in that table into existing because:
# INSERT doesn't currently support IF
# UPDATE has no way to update such table
So we should probably allow IF conditions on INSERT statements.
In addition (or alternatively), we could work on allowing UPDATE to update
such table. One motivation for that could be to make UPDATE always be more
general to INSERT. That is currently, there is a bunch of operation that
INSERT cannot do (counter increments, collection appends), but that primary
key table case is, afaik, the only case where you *need* to use INSERT.
However, because CQL forces segregation of PK value to the WHERE clause and
not to the SET one, the only syntax that I can see work would be:
{noformat}
UPDATE WHERE k=0;
{noformat}
which maybe is too ugly to allow?
--
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-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:comment-tabpanelfocusedCommentId=13698585#comment-13698585
]
Blair Zajac commented on CASSANDRA-5689:
I'm running 1.2.5 using DataStax's Debian cassandra package and using the same
shutdown script, I haven't seen this exception at all through many shutdowns on
my VMs, so this suggests it's new in 1.2.6 and trunk.
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: API
Affects Versions: 1.2.0
Environment: Ubuntu Precise with Oracle Java 7u25.
Reporter: Blair Zajac
Assignee: Alex Zarutin
Priority: Trivial
Attachments: CASSANDRA-5689.txt, init1, init2, init3
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] [Created] (CASSANDRA-5689) NPE shutting down Cassandra trunk (cassandra-1.2.5-989-g70dfb70)
Blair Zajac created CASSANDRA-5689:
--
Summary: 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
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
[jira] [Updated] (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
]
Blair Zajac updated CASSANDRA-5688:
---
Attachment: trunk-5688.txt
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
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] [Commented] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13691038#comment-13691038 ] Blair Zajac commented on CASSANDRA-5619: Sweet, thanks guys! CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 1 Reporter: Blair Zajac Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 Attachments: 5619.txt Looking at the new CAS CQL3 support examples [1], if one lost a race for an UPDATE, to save a round trip to get the current values to decide if you need to perform your work, could the columns that were used in the IF clause also be returned to the caller? Maybe the columns values as part of the SET part could also be returned. I don't know if this is generally useful though. In the case of creating a new user account with a given username which is the partition key, if one lost the race to another person creating an account with the same username, it doesn't matter to the loser what the column values are, just that they lost. I'm new to Cassandra, so maybe there's other use cases, such as doing incremental amount of work on a row. In pure Java projects I've done while loops around AtomicReference.html#compareAndSet() until the work was done on the referenced object to handle multiple threads each making forward progress in updating the references object. [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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-5688) Update debian packaging for 2.0
Blair Zajac created CASSANDRA-5688:
--
Summary: 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
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] [Created] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
Blair Zajac created CASSANDRA-5619: -- Summary: CAS UPDATE for a lost race: save round trip by returning column values Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 Reporter: Blair Zajac Looking at the new CAS CQL3 support examples [1], if one lost a race for an UPDATE, to save a round trip to get the current values to decide if you need to perform your work, could the columns that were used in the IF clause also be returned to the caller? Maybe the columns values as part of the SET part could also be returned. I don't know if this is generally useful though. In the case of creating a new user account with a given username which is the partition key, if one lost the race to another person creating an account with the same username, it doesn't matter to the loser what the column values are, just that they lost. I'm new to Cassandra, so maybe there's other use cases, such as doing incremental amount of work on a row. In pure Java projects I've done while loops around AtomicReference.html#compareAndSet() until the work was done on the referenced object to handle multiple threads each making forward progress in updating the references object. [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677332#comment-13677332 ] Blair Zajac commented on CASSANDRA-5619: I'm new to Cassandra and haven't looked at the Thrift or CQL2 API, I've been doing everything on CQL3 where possible, as suggested by your blogs ;) Given that the new CAS support returns a Boolean on the success or failure where the non-CAS UPDATE returned nothing, couldn't the additional columns be added on the return in addition to the Boolean? I was looking at the CQL3 Java Driver, and there, it seems pretty straight forward. CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 Reporter: Blair Zajac Looking at the new CAS CQL3 support examples [1], if one lost a race for an UPDATE, to save a round trip to get the current values to decide if you need to perform your work, could the columns that were used in the IF clause also be returned to the caller? Maybe the columns values as part of the SET part could also be returned. I don't know if this is generally useful though. In the case of creating a new user account with a given username which is the partition key, if one lost the race to another person creating an account with the same username, it doesn't matter to the loser what the column values are, just that they lost. I'm new to Cassandra, so maybe there's other use cases, such as doing incremental amount of work on a row. In pure Java projects I've done while loops around AtomicReference.html#compareAndSet() until the work was done on the referenced object to handle multiple threads each making forward progress in updating the references object. [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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
