[jira] [Commented] (CASSANDRA-5191) BufferOverflowException in CommitLogSegment
[ https://issues.apache.org/jira/browse/CASSANDRA-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565162#comment-13565162 ] André Borgqvist commented on CASSANDRA-5191: We have one BytesType column that holds a 132 byte id that is written frequently. > BufferOverflowException in CommitLogSegment > --- > > Key: CASSANDRA-5191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5191 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.9 > Environment: RHEL 2.6.32-220.el6.x86_64, jdk1.6.0_27 >Reporter: André Borgqvist > > Running mixed reads, writes and deletes on a single column family in a two > node cluster. After a few minutes the following appears in the system log: > ERROR [COMMIT-LOG-WRITER] 2013-01-25 12:49:55,955 > AbstractCassandraDaemon.java (line 135) Exception in thread > Thread[COMMIT-LOG-WRITER,5,main] > java.nio.BufferOverflowException > at java.nio.Buffer.nextPutIndex(Buffer.java:499) > at java.nio.DirectByteBuffer.putLong(DirectByteBuffer.java:756) > at > org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:265) > at > org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:382) > at > org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:50) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at java.lang.Thread.run(Thread.java:662) > Possibly related to https://issues.apache.org/jira/browse/CASSANDRA-3615 -- 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-4705) Speculative execution for Reads
[ https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565082#comment-13565082 ] Jonathan Ellis commented on CASSANDRA-4705: --- Can you rebase + commit? > Speculative execution for Reads > --- > > Key: CASSANDRA-4705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4705 > Project: Cassandra > Issue Type: Improvement >Reporter: Vijay >Assignee: Vijay > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-4705.patch, 0001-CASSANDRA-4705-v2.patch, > 0001-CASSANDRA-4705-v3.patch, > 0001-Refactor-to-introduce-AbstractReadExecutor.patch, > 0002-Add-Speculative-execution-for-Row-Reads.patch > > > When read_repair is not 1.0, we send the request to one node for some of the > requests. When a node goes down or when a node is too busy the client has to > wait for the timeout before it can retry. > It would be nice to watch for latency and execute an additional request to a > different node, if the response is not received within average/99% of the > response times recorded in the past. > CASSANDRA-2540 might be able to solve the variance when read_repair is set to > 1.0 > 1) May be we need to use metrics-core to record various Percentiles > 2) Modify ReadCallback.get to execute additional request speculatively. -- 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-4705) Speculative execution for Reads
[ https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565075#comment-13565075 ] Vijay commented on CASSANDRA-4705: -- LGTM +1 (will create a ticket for SimpleCondition with some benchmarks (Possibly) :) ) > Speculative execution for Reads > --- > > Key: CASSANDRA-4705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4705 > Project: Cassandra > Issue Type: Improvement >Reporter: Vijay >Assignee: Vijay > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-4705.patch, 0001-CASSANDRA-4705-v2.patch, > 0001-CASSANDRA-4705-v3.patch, > 0001-Refactor-to-introduce-AbstractReadExecutor.patch, > 0002-Add-Speculative-execution-for-Row-Reads.patch > > > When read_repair is not 1.0, we send the request to one node for some of the > requests. When a node goes down or when a node is too busy the client has to > wait for the timeout before it can retry. > It would be nice to watch for latency and execute an additional request to a > different node, if the response is not received within average/99% of the > response times recorded in the past. > CASSANDRA-2540 might be able to solve the variance when read_repair is set to > 1.0 > 1) May be we need to use metrics-core to record various Percentiles > 2) Modify ReadCallback.get to execute additional request speculatively. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4705) Speculative execution for Reads
[ https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565049#comment-13565049 ] Jonathan Ellis edited comment on CASSANDRA-4705 at 1/29/13 3:53 AM: (Also, changing SimpleCondition scares me a bit so let's pull that out to a separate ticket if it's necessary -- I took out those changes in my branch.) was (Author: jbellis): (Also, changing SimpleCondition scares me a bit so let's pull that out to a separate ticket if it's necessary.) > Speculative execution for Reads > --- > > Key: CASSANDRA-4705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4705 > Project: Cassandra > Issue Type: Improvement >Reporter: Vijay >Assignee: Vijay > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-4705.patch, 0001-CASSANDRA-4705-v2.patch, > 0001-CASSANDRA-4705-v3.patch, > 0001-Refactor-to-introduce-AbstractReadExecutor.patch, > 0002-Add-Speculative-execution-for-Row-Reads.patch > > > When read_repair is not 1.0, we send the request to one node for some of the > requests. When a node goes down or when a node is too busy the client has to > wait for the timeout before it can retry. > It would be nice to watch for latency and execute an additional request to a > different node, if the response is not received within average/99% of the > response times recorded in the past. > CASSANDRA-2540 might be able to solve the variance when read_repair is set to > 1.0 > 1) May be we need to use metrics-core to record various Percentiles > 2) Modify ReadCallback.get to execute additional request speculatively. -- 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-4705) Speculative execution for Reads
[ https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565049#comment-13565049 ] Jonathan Ellis commented on CASSANDRA-4705: --- (Also, changing SimpleCondition scares me a bit so let's pull that out to a separate ticket if it's necessary.) > Speculative execution for Reads > --- > > Key: CASSANDRA-4705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4705 > Project: Cassandra > Issue Type: Improvement >Reporter: Vijay >Assignee: Vijay > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-4705.patch, 0001-CASSANDRA-4705-v2.patch, > 0001-CASSANDRA-4705-v3.patch, > 0001-Refactor-to-introduce-AbstractReadExecutor.patch, > 0002-Add-Speculative-execution-for-Row-Reads.patch > > > When read_repair is not 1.0, we send the request to one node for some of the > requests. When a node goes down or when a node is too busy the client has to > wait for the timeout before it can retry. > It would be nice to watch for latency and execute an additional request to a > different node, if the response is not received within average/99% of the > response times recorded in the past. > CASSANDRA-2540 might be able to solve the variance when read_repair is set to > 1.0 > 1) May be we need to use metrics-core to record various Percentiles > 2) Modify ReadCallback.get to execute additional request speculatively. -- 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-4705) Speculative execution for Reads
[ https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565048#comment-13565048 ] Jonathan Ellis commented on CASSANDRA-4705: --- Thanks, that makes it a lot easier to follow the refactor. v6 pushed to https://github.com/jbellis/cassandra/branches/4705-v6 with a bunch of changes. Biggest is, simplified SpeculativeReadExecutor.speculate under the reasoning that if an earlier request hasn't been serviced yet on a given replica, sending a second request to the same one probably won't help. Also, realized sorting the speculation wasn't necessary after all. LMKWYT. > Speculative execution for Reads > --- > > Key: CASSANDRA-4705 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4705 > Project: Cassandra > Issue Type: Improvement >Reporter: Vijay >Assignee: Vijay > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-4705.patch, 0001-CASSANDRA-4705-v2.patch, > 0001-CASSANDRA-4705-v3.patch, > 0001-Refactor-to-introduce-AbstractReadExecutor.patch, > 0002-Add-Speculative-execution-for-Row-Reads.patch > > > When read_repair is not 1.0, we send the request to one node for some of the > requests. When a node goes down or when a node is too busy the client has to > wait for the timeout before it can retry. > It would be nice to watch for latency and execute an additional request to a > different node, if the response is not received within average/99% of the > response times recorded in the past. > CASSANDRA-2540 might be able to solve the variance when read_repair is set to > 1.0 > 1) May be we need to use metrics-core to record various Percentiles > 2) Modify ReadCallback.get to execute additional request speculatively. -- 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-3378) Allow configuration of storage protocol socket buffer
[ https://issues.apache.org/jira/browse/CASSANDRA-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564898#comment-13564898 ] Jason Brown commented on CASSANDRA-3378: Looks like snappy does it's own internal buffering (for compressing streams). SnappyOutputStream has an 'uncompressed' buffer of 32k, which flushes to it's output stream when full or flush() is called. SnappyInputStream creates a buffer based upon the size of the chunk size of the current block. Thus, we shouldn't need to worry about having Buffered*putStream for compressed streams. We could play with the buffer size there (4k vs. 8k), but I think the biggest win is just having _any_ buffer before the socket output stream (which doesn't buffer at all). I'm in favor of leaving the default 4096 buffer size for Buffered*putStream on uncompressed streams until there is sufficient evidence/testing to switch. As for the socket's buffer config, we can use Michal's new yaml settings for the in/out sockets. However, I think storage_send_buff_size_in_bytes should be commented out by default in the yaml. > Allow configuration of storage protocol socket buffer > - > > Key: CASSANDRA-3378 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3378 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Michał Michalski >Priority: Minor > Labels: lhf > Attachments: cassandra-3378-v1.patch, cassandra-3378-v2.patch > > > Similar to rpc_[send,recv]_buff_size_in_bytes, we should expose this for high > latency connections. -- 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-5191) BufferOverflowException in CommitLogSegment
[
https://issues.apache.org/jira/browse/CASSANDRA-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564781#comment-13564781
]
Jonathan Ellis commented on CASSANDRA-5191:
---
Are you doing a lot of {{blob}} writes?
> BufferOverflowException in CommitLogSegment
> ---
>
> Key: CASSANDRA-5191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5191
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.9
> Environment: RHEL 2.6.32-220.el6.x86_64, jdk1.6.0_27
>Reporter: André Borgqvist
>
> Running mixed reads, writes and deletes on a single column family in a two
> node cluster. After a few minutes the following appears in the system log:
> ERROR [COMMIT-LOG-WRITER] 2013-01-25 12:49:55,955
> AbstractCassandraDaemon.java (line 135) Exception in thread
> Thread[COMMIT-LOG-WRITER,5,main]
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:499)
> at java.nio.DirectByteBuffer.putLong(DirectByteBuffer.java:756)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:265)
> at
> org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:382)
> at
> org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:50)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at java.lang.Thread.run(Thread.java:662)
> Possibly related to https://issues.apache.org/jira/browse/CASSANDRA-3615
--
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-5194) LIKE Operator in CQL When Creating Column Families
Russell Bradberry created CASSANDRA-5194:
Summary: LIKE Operator in CQL When Creating Column Families
Key: CASSANDRA-5194
URL: https://issues.apache.org/jira/browse/CASSANDRA-5194
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2.1
Reporter: Russell Bradberry
Priority: Minor
Some RDBMSs have a very convenient feature that allows to create tables that
look like other tables.
THe end result should look similar to:
{code}
CREATE TABLE foo LIKE bar;
{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] [Created] (CASSANDRA-5193) Memtable flushwriter can pick a blacklisted directory
Aleksey Yeschenko created CASSANDRA-5193: Summary: Memtable flushwriter can pick a blacklisted directory Key: CASSANDRA-5193 URL: https://issues.apache.org/jira/browse/CASSANDRA-5193 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.1 Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Fix For: 1.2.2 The top-level data directory will be picked by DiskAwareRunnable (directory = Directories.getLocationCapableOfSize(writeSize)), and the top-level data directory itself might not be blacklisted (most likely won't be). For the same reason we can't just add a blacklist-check in the middle of Directories#getLocationCapableOfSize - most often it's the sstable directory that gets blacklisted. The issue seems to be caused by/related to CASSANDRA-4292, which was committed just two days prior 2116-2118 and undid some blacklist-aware directory-picking logic. Anyway, DiskAwareRunnable should be altered to respect directory blacklist. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5191) BufferOverflowException in CommitLogSegment
[ https://issues.apache.org/jira/browse/CASSANDRA-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564424#comment-13564424 ] André Borgqvist edited comment on CASSANDRA-5191 at 1/28/13 8:46 PM: - I'll try write a test program to reproduce the fault. The basic use case is that we have about 100-200 million rows in the database. We then simulate usage our application that will cause inserts of columns, deletes of columns and deletes of rows. The simulated usage is run toward both nodes in the cluster at about 2000 requests/second. After 5-15 minutes the fault appears and cassandra must be restarted. One noteable thing is that the fault only ever happened on one of the nodes (the second) in the cluster. Suspecting hardware fault we replaced that node only to have the fault appear on the new node. But never on node 1. was (Author: andbor): I'm working on a test program to reproduce. > BufferOverflowException in CommitLogSegment > --- > > Key: CASSANDRA-5191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5191 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.9 > Environment: RHEL 2.6.32-220.el6.x86_64, jdk1.6.0_27 >Reporter: André Borgqvist > > Running mixed reads, writes and deletes on a single column family in a two > node cluster. After a few minutes the following appears in the system log: > ERROR [COMMIT-LOG-WRITER] 2013-01-25 12:49:55,955 > AbstractCassandraDaemon.java (line 135) Exception in thread > Thread[COMMIT-LOG-WRITER,5,main] > java.nio.BufferOverflowException > at java.nio.Buffer.nextPutIndex(Buffer.java:499) > at java.nio.DirectByteBuffer.putLong(DirectByteBuffer.java:756) > at > org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:265) > at > org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:382) > at > org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:50) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at java.lang.Thread.run(Thread.java:662) > Possibly related to https://issues.apache.org/jira/browse/CASSANDRA-3615 -- 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-5192) cql2 batch mode ignores keyspace qualification
[
https://issues.apache.org/jira/browse/CASSANDRA-5192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-5192.
---
Resolution: Won't Fix
cql2 is around for compatibility only at this point.
> cql2 batch mode ignores keyspace qualification
> --
>
> Key: CASSANDRA-5192
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5192
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.9
>Reporter: Mark Dewey
>
> How to reproduce: {noformat}
> cqlsh
> CREATE KEYSPACE demo WITH
> strategy_class = 'SimpleStrategy'
> AND strategy_options:replication_factor = '1';
> USE demo;
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password) VALUES ('jsmith', '000');
> CREATE KEYSPACE demo2 WITH
> strategy_class = 'SimpleStrategy'
> AND strategy_options:replication_factor = '1';
> USE demo2;
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password) VALUES ('jsmith', '000');
> use demo;
> begin batch
> insert into demo.users (KEY, password) VALUES ('jsmith', '111')
> insert into demo2.users (KEY, password) VALUES ('jsmith', '222')
> apply batch;
> select * from demo.users;
> select * from demo2.users;
> {noformat}
> Error:
> The entry in demo.users will be what we tried to set demo2.users to be. The
> entry in demo2.users will be its original value.
--
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-5192) cql2 batch mode ignores keyspace qualification
Mark Dewey created CASSANDRA-5192:
-
Summary: cql2 batch mode ignores keyspace qualification
Key: CASSANDRA-5192
URL: https://issues.apache.org/jira/browse/CASSANDRA-5192
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.9
Reporter: Mark Dewey
How to reproduce: {noformat}
cqlsh
CREATE KEYSPACE demo WITH
strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = '1';
USE demo;
CREATE COLUMNFAMILY users (
KEY varchar PRIMARY KEY,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint);
INSERT INTO users (KEY, password) VALUES ('jsmith', '000');
CREATE KEYSPACE demo2 WITH
strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = '1';
USE demo2;
CREATE COLUMNFAMILY users (
KEY varchar PRIMARY KEY,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint);
INSERT INTO users (KEY, password) VALUES ('jsmith', '000');
use demo;
begin batch
insert into demo.users (KEY, password) VALUES ('jsmith', '111')
insert into demo2.users (KEY, password) VALUES ('jsmith', '222')
apply batch;
select * from demo.users;
select * from demo2.users;
{noformat}
Error:
The entry in demo.users will be what we tried to set demo2.users to be. The
entry in demo2.users will be its original value.
--
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: merge from 1.1
Updated Branches: refs/heads/cassandra-1.2 7752f018b -> 4feb87d37 merge from 1.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4feb87d3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4feb87d3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4feb87d3 Branch: refs/heads/cassandra-1.2 Commit: 4feb87d37544b9fde722786555475f2f790059ca Parents: 7752f01 73d828e Author: Pavel Yaskevich Authored: Mon Jan 28 10:45:47 2013 -0800 Committer: Pavel Yaskevich Committed: Mon Jan 28 10:45:47 2013 -0800 -- CHANGES.txt|1 + .../cassandra/hadoop/ColumnFamilyOutputFormat.java |4 +- .../cassandra/hadoop/ColumnFamilyRecordReader.java |4 +- .../org/apache/cassandra/hadoop/ConfigHelper.java | 34 ++- .../apache/cassandra/thrift/ITransportFactory.java |3 +- .../apache/cassandra/thrift/TBinaryProtocol.java |8 +++ .../cassandra/thrift/TFramedTransportFactory.java |7 ++- 7 files changed, 52 insertions(+), 9 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4feb87d3/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4feb87d3/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4feb87d3/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4feb87d3/src/java/org/apache/cassandra/hadoop/ConfigHelper.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4feb87d3/src/java/org/apache/cassandra/thrift/TBinaryProtocol.java --
[1/2] git commit: add ConfigHelper support for Thrift frame and max message sizes patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-5188
add ConfigHelper support for Thrift frame and max message sizes
patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-5188
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/73d828e4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/73d828e4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/73d828e4
Branch: refs/heads/cassandra-1.2
Commit: 73d828e4e8023b9f7ca8fafd12becec34eb59211
Parents: 3298c2f
Author: Pavel Yaskevich
Authored: Fri Jan 25 21:49:25 2013 -0800
Committer: Pavel Yaskevich
Committed: Mon Jan 28 10:31:13 2013 -0800
--
CHANGES.txt|1 +
.../cassandra/hadoop/ColumnFamilyOutputFormat.java |4 +-
.../cassandra/hadoop/ColumnFamilyRecordReader.java |4 +-
.../org/apache/cassandra/hadoop/ConfigHelper.java | 34 ++-
.../apache/cassandra/thrift/ITransportFactory.java |3 +-
.../apache/cassandra/thrift/TBinaryProtocol.java |8 +++
.../cassandra/thrift/TFramedTransportFactory.java |7 ++-
7 files changed, 52 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/73d828e4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1ad77b1..1c414bc 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -3,6 +3,7 @@
* fix ConcurrentModificationException in getBootstrapSource (CASSANDRA-5170)
* fix sstable maxtimestamp for row deletes and pre-1.1.1 sstables
(CASSANDRA-5153)
* fix start key/end token validation for wide row iteration (CASSANDRA-5168)
+ * add ConfigHelper support for Thrift frame and max message sizes
(CASSANDRA-5188)
1.1.9
http://git-wip-us.apache.org/repos/asf/cassandra/blob/73d828e4/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
b/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
index e01ada5..caea616 100644
--- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
+++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
@@ -154,8 +154,8 @@ public class ColumnFamilyOutputFormat extends
OutputFormathttp://git-wip-us.apache.org/repos/asf/cassandra/blob/73d828e4/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
index 83e436b..a40e6c5 100644
--- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
+++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
@@ -161,8 +161,8 @@ public class ColumnFamilyRecordReader extends
RecordReaderhttp://git-wip-us.apache.org/repos/asf/cassandra/blob/73d828e4/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
b/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
index 4b49387..ad29903 100644
--- a/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
+++ b/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
@@ -76,6 +76,8 @@ public class ConfigHelper
private static final String OUTPUT_COMPRESSION_CHUNK_LENGTH =
"cassandra.output.compression.length";
private static final String INPUT_TRANSPORT_FACTORY_CLASS =
"cassandra.input.transport.factory.class";
private static final String OUTPUT_TRANSPORT_FACTORY_CLASS =
"cassandra.output.transport.factory.class";
+private static final String THRIFT_FRAMED_TRANSPORT_SIZE_IN_MB =
"cassandra.thrift.framed.size_mb";
+private static final String THRIFT_MAX_MESSAGE_LENGTH_IN_MB =
"cassandra.thrift.message.max_size_mb";
private static final Logger logger =
LoggerFactory.getLogger(ConfigHelper.class);
@@ -466,6 +468,34 @@ public class ConfigHelper
conf.set(OUTPUT_COMPRESSION_CHUNK_LENGTH, length);
}
+public static void setThriftFramedTransportSizeInMb(Configuration conf,
int frameSizeInMB)
+{
+conf.setInt(THRIFT_FRAMED_TRANSPORT_SIZE_IN_MB, frameSizeInMB);
+}
+
+/**
+ * @param conf The configuration to use.
+ * @return Value (converts MBs to Bytes) set by {@link
setThriftFramedTransportSizeInMb(Configuration, int)} or default of 15MB
+ */
+public static int getThriftFramedTransportSize(Configuration conf)
+{
+return conf.getInt(THRIFT_FRAMED_TRANSPORT_SIZE_IN_MB, 15) * 1024 *
1024; // 15MB is default in Cassandra
+}
+
+public static void setThriftMax
git commit: add ConfigHelper support for Thrift frame and max message sizes patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-5188
Updated Branches:
refs/heads/cassandra-1.1 3298c2f19 -> 73d828e4e
add ConfigHelper support for Thrift frame and max message sizes
patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-5188
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/73d828e4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/73d828e4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/73d828e4
Branch: refs/heads/cassandra-1.1
Commit: 73d828e4e8023b9f7ca8fafd12becec34eb59211
Parents: 3298c2f
Author: Pavel Yaskevich
Authored: Fri Jan 25 21:49:25 2013 -0800
Committer: Pavel Yaskevich
Committed: Mon Jan 28 10:31:13 2013 -0800
--
CHANGES.txt|1 +
.../cassandra/hadoop/ColumnFamilyOutputFormat.java |4 +-
.../cassandra/hadoop/ColumnFamilyRecordReader.java |4 +-
.../org/apache/cassandra/hadoop/ConfigHelper.java | 34 ++-
.../apache/cassandra/thrift/ITransportFactory.java |3 +-
.../apache/cassandra/thrift/TBinaryProtocol.java |8 +++
.../cassandra/thrift/TFramedTransportFactory.java |7 ++-
7 files changed, 52 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/73d828e4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1ad77b1..1c414bc 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -3,6 +3,7 @@
* fix ConcurrentModificationException in getBootstrapSource (CASSANDRA-5170)
* fix sstable maxtimestamp for row deletes and pre-1.1.1 sstables
(CASSANDRA-5153)
* fix start key/end token validation for wide row iteration (CASSANDRA-5168)
+ * add ConfigHelper support for Thrift frame and max message sizes
(CASSANDRA-5188)
1.1.9
http://git-wip-us.apache.org/repos/asf/cassandra/blob/73d828e4/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
b/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
index e01ada5..caea616 100644
--- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
+++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyOutputFormat.java
@@ -154,8 +154,8 @@ public class ColumnFamilyOutputFormat extends
OutputFormathttp://git-wip-us.apache.org/repos/asf/cassandra/blob/73d828e4/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
index 83e436b..a40e6c5 100644
--- a/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
+++ b/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
@@ -161,8 +161,8 @@ public class ColumnFamilyRecordReader extends
RecordReaderhttp://git-wip-us.apache.org/repos/asf/cassandra/blob/73d828e4/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
b/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
index 4b49387..ad29903 100644
--- a/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
+++ b/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
@@ -76,6 +76,8 @@ public class ConfigHelper
private static final String OUTPUT_COMPRESSION_CHUNK_LENGTH =
"cassandra.output.compression.length";
private static final String INPUT_TRANSPORT_FACTORY_CLASS =
"cassandra.input.transport.factory.class";
private static final String OUTPUT_TRANSPORT_FACTORY_CLASS =
"cassandra.output.transport.factory.class";
+private static final String THRIFT_FRAMED_TRANSPORT_SIZE_IN_MB =
"cassandra.thrift.framed.size_mb";
+private static final String THRIFT_MAX_MESSAGE_LENGTH_IN_MB =
"cassandra.thrift.message.max_size_mb";
private static final Logger logger =
LoggerFactory.getLogger(ConfigHelper.class);
@@ -466,6 +468,34 @@ public class ConfigHelper
conf.set(OUTPUT_COMPRESSION_CHUNK_LENGTH, length);
}
+public static void setThriftFramedTransportSizeInMb(Configuration conf,
int frameSizeInMB)
+{
+conf.setInt(THRIFT_FRAMED_TRANSPORT_SIZE_IN_MB, frameSizeInMB);
+}
+
+/**
+ * @param conf The configuration to use.
+ * @return Value (converts MBs to Bytes) set by {@link
setThriftFramedTransportSizeInMb(Configuration, int)} or default of 15MB
+ */
+public static int getThriftFramedTransportSize(Configuration conf)
+{
+return conf.getInt(THRIFT_FRAMED_TRANSPORT_SIZE_IN_MB, 15) * 1024 *
1024; // 15MB
[jira] [Updated] (CASSANDRA-3378) Allow configuration of storage protocol socket buffer
[ https://issues.apache.org/jira/browse/CASSANDRA-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3378: -- Reviewer: jasobrown (was: brandon.williams) > Allow configuration of storage protocol socket buffer > - > > Key: CASSANDRA-3378 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3378 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Michał Michalski >Priority: Minor > Labels: lhf > Attachments: cassandra-3378-v1.patch, cassandra-3378-v2.patch > > > Similar to rpc_[send,recv]_buff_size_in_bytes, we should expose this for high > latency connections. -- 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-5188) o.a.c.hadoop.ConfigHelper should support setting Thrift frame and max message sizes.
[ https://issues.apache.org/jira/browse/CASSANDRA-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564489#comment-13564489 ] Brandon Williams commented on CASSANDRA-5188: - +1 > o.a.c.hadoop.ConfigHelper should support setting Thrift frame and max message > sizes. > > > Key: CASSANDRA-5188 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5188 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.1.9 >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.1.10 > > Attachments: CASSANDRA-5188.patch > > > Without such support people will be running into problems like > https://github.com/thinkaurelius/faunus/issues/99 without any work around > when custom frame and/or max message sizes are used. -- 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-5190) peers listed in peer system table but not listed in ring or gossipinfo
[
https://issues.apache.org/jira/browse/CASSANDRA-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-5190.
-
Resolution: Duplicate
> peers listed in peer system table but not listed in ring or gossipinfo
> --
>
> Key: CASSANDRA-5190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5190
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
> Environment: Ubuntu 12.04
>Reporter: Michael Kjellman
>Priority: Critical
>
> {code}
> cqlsh:system> select * from peers;
> peer| data_center | host_id | rack |
> release_version | rpc_address | schema_version | tokens
> -+-+--+--+-+-+--+---
> 10.8.25.113 | DC1 | 0c11b261-7514-4c98-b94c-baa79c6c4faf | RAC2 |
> 1.2.0-SNAPSHOT | 10.8.25.113 | b438118e-baab-3212-a69d-6b091104523f |
> {28356863910078205288614550619314017620}
> 10.8.30.104 | DC1 | ec7bf3be-41da-4cb5-8cec-63e5a8776bca | RAC1 |
>1.2.0 | 0.0.0.0 | be91dd6b-8419-3f91-b5a0-86b071c1bfbe |
>null
> 10.8.25.134 | DC1 | afdc7305-2a9e-471b-8a9c-5a27efd1423a | RAC2 |
> 1.2.0-SNAPSHOT | 10.8.25.134 | b438118e-baab-3212-a69d-6b091104523f |
> {113427455640312821154458202477256070480}
> 10.8.30.103 | DC1 | a6c4d3f6-dcbd-4801-aad3-ef0a26959e51 | RAC1 |
> 1.2.0-SNAPSHOT | 10.8.30.103 | b438118e-baab-3212-a69d-6b091104523f |
> {155962751505430129087380028406227096910}
> 10.8.25.114 | DC1 | a42f6766-279d-4d12-b549-d3d97c9ce650 | RAC2 |
> 1.2.0-SNAPSHOT | 10.8.25.114 | b438118e-baab-3212-a69d-6b091104523f |
> {85070591730234615865843651857942052860}
> 10.8.30.102 | DC1 | 21b3af77-46e8-4814-8340-598617b57dad | RAC1 |
> 1.2.0-SNAPSHOT | 10.8.30.102 | b438118e-baab-3212-a69d-6b091104523f |
> {99249023685273718510150927167599061670}
> 10.8.30.14 | DC1 | 24647d52-41eb-4df3-993e-51d4f841ca62 | RAC1 |
> 1.2.0-SNAPSHOT | 10.8.30.14 | b438118e-baab-3212-a69d-6b091104523f |
> {70892159775195513221536376548285044050}
> 10.8.30.15 | DC1 | d84a5632-d6d5-4b06-8e1b-ae39ab185ca1 | RAC1 |
>1.2.0 | 0.0.0.0 | 5cd8420d-ce3c-3625-8293-67558a24816b |
>null
> 10.8.25.132 | DC1 | 71904dbb-9682-45a9-b9a9-c15f3e28c068 | RAC2 |
> 1.2.0-SNAPSHOT | 10.8.25.132 | b438118e-baab-3212-a69d-6b091104523f |
> {14178431955039102644307275309657008816}
> 10.8.30.16 | DC1 | 73cf3d09-3c8a-41f0-a3fd-267e57216884 | RAC1 |
> 1.2.0-SNAPSHOT | 10.8.30.16 | b438118e-baab-3212-a69d-6b091104523f |
> {127605887595351923798765477786913079289}
> 10.8.25.123 | DC1 | 2d818a06-e62b-4027-9201-1801e885a446 | RAC2 |
> 1.2.0-SNAPSHOT | 10.8.25.123 | b438118e-baab-3212-a69d-6b091104523f |
> {141784319550391026443072753096570088100}
> 10.8.25.133 | DC1 | 940846e4-bb9c-4281-b583-7f76afa93589 | RAC2 |
> 1.2.0-SNAPSHOT | 10.8.25.133 | b438118e-baab-3212-a69d-6b091104523f |
> {56713727820156410577229101238628035240}
> 10.8.30.13 | DC1 | b63fe173-5d13-4905-a59f-a78790f4f980 | RAC1 |
> 1.2.0-SNAPSHOT | 10.8.30.13 | b438118e-baab-3212-a69d-6b091104523f |
> {6}
> cqlsh:system> quit
> root@scl-cas04:~# nodetool ring | grep 10.8.30.104
> root@scl-cas04:~# nodetool ring | grep 10.8.30
> 10.8.30.13 RAC1Up Normal 258.14 GB 8.33%
> 6
> 10.8.30.14 RAC1Up Normal 542.67 GB 8.33%
> 70892159775195513221536376548285044050
> 10.8.30.102 RAC1Up Normal 262.49 GB 8.33%
> 99249023685273718510150927167599061670
> 10.8.30.16 RAC1Up Normal 288.43 GB 8.33%
> 127605887595351923798765477786913079289
> 10.8.30.103 RAC1Up Normal 365.7 GB8.33%
> 155962751505430129087380028406227096910
> root@scl-cas04:~# nodetool gossipinfo | grep 10.8.30
> /10.8.30.14
> RPC_ADDRESS:10.8.30.14
> /10.8.30.13
> RPC_ADDRESS:10.8.30.13
> /10.8.30.102
> RPC_ADDRESS:10.8.30.102
> /10.8.30.16
> RPC_ADDRESS:10.8.30.16
> /10.8.30.103
> RPC_ADDRESS:10.8.30.103
> {code}
> more information as I debug but any thoughts about how this would be possible
> would be appreciated
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA,
[jira] [Updated] (CASSANDRA-3648) Repair should validate checksums before streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3648: -- Reviewer: jasobrown > Repair should validate checksums before streaming > - > > Key: CASSANDRA-3648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3648 > Project: Cassandra > Issue Type: New Feature >Reporter: Jonathan Ellis >Assignee: Vijay >Priority: Minor > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-3648.patch > > > We have block checksums and sha1 full-file hashes, but currently we do not > validate these before streaming in a repair. -- 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-5189) compact storage metadata is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5189:
--
Reviewer: jasobrown
> compact storage metadata is broken
> --
>
> Key: CASSANDRA-5189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5189
> Project: Cassandra
> Issue Type: Bug
> Components: API
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 1.2.2
>
> Attachments: 5189.txt
>
>
> {noformat}
> cqlsh:foo> CREATE TABLE bar (
>... id int primary key,
>... i int
>... ) WItH COMPACT STORAGE;
> cqlsh:foo> INSERT INTO bar (id, i) VALUES (1, 2);
> Bad Request: Missing PRIMARY KEY part column1
> Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.
> cqlsh:foo> INSERT INTO bar (id, column1) VALUES (1, 2);
> Bad Request: Missing mandatory column i
> Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "Committers" by JonathanEllis
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Committers" page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/Committers?action=diff&rev1=29&rev2=30 ||Gary Dusbabek||Dec 2009||Rackspace||PMC member|| ||Jaakko Laine||Dec 2009||?|| || ||Brandon Williams||Jun 2010||Datastax||PMC member|| - ||Jake Luciani||Jan 2011||BlueMountain||Also a [[http://thrift.apache.org/|Thrift]] PMC member|| + ||Jake Luciani||Jan 2011||!BlueMountain||Also a [[http://thrift.apache.org/|Thrift]] PMC member|| ||Sylvain Lebresne||Mar 2011||Datastax||PMC member, Release manager|| ||Pavel Yaskevich||Aug 2011||Twitter||PMC member|| ||Vijay Parthasarathy||Jan 2012||Apple|| ||
[jira] [Updated] (CASSANDRA-5125) Support indexes on composite column components
[
https://issues.apache.org/jira/browse/CASSANDRA-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5125:
Fix Version/s: (was: 1.2.2)
2.0
> Support indexes on composite column components
> --
>
> Key: CASSANDRA-5125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5125
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 2.0
>
>
> Given
> {code}
> CREATE TABLE foo (
> a int,
> b int,
> c int,
> PRIMARY KEY (a, b)
> );
> {code}
> We should support {{CREATE INDEX ON foo(b)}}.
--
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-5191) BufferOverflowException in CommitLogSegment
[ https://issues.apache.org/jira/browse/CASSANDRA-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564424#comment-13564424 ] André Borgqvist commented on CASSANDRA-5191: I'm working on a test program to reproduce. > BufferOverflowException in CommitLogSegment > --- > > Key: CASSANDRA-5191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5191 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.9 > Environment: RHEL 2.6.32-220.el6.x86_64, jdk1.6.0_27 >Reporter: André Borgqvist > > Running mixed reads, writes and deletes on a single column family in a two > node cluster. After a few minutes the following appears in the system log: > ERROR [COMMIT-LOG-WRITER] 2013-01-25 12:49:55,955 > AbstractCassandraDaemon.java (line 135) Exception in thread > Thread[COMMIT-LOG-WRITER,5,main] > java.nio.BufferOverflowException > at java.nio.Buffer.nextPutIndex(Buffer.java:499) > at java.nio.DirectByteBuffer.putLong(DirectByteBuffer.java:756) > at > org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:265) > at > org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:382) > at > org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:50) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at java.lang.Thread.run(Thread.java:662) > Possibly related to https://issues.apache.org/jira/browse/CASSANDRA-3615 -- 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-5191) BufferOverflowException in CommitLogSegment
[ https://issues.apache.org/jira/browse/CASSANDRA-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564375#comment-13564375 ] Jonathan Ellis commented on CASSANDRA-5191: --- Don't suppose you can give us a test case to reproduce? > BufferOverflowException in CommitLogSegment > --- > > Key: CASSANDRA-5191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5191 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.9 > Environment: RHEL 2.6.32-220.el6.x86_64, jdk1.6.0_27 >Reporter: André Borgqvist > > Running mixed reads, writes and deletes on a single column family in a two > node cluster. After a few minutes the following appears in the system log: > ERROR [COMMIT-LOG-WRITER] 2013-01-25 12:49:55,955 > AbstractCassandraDaemon.java (line 135) Exception in thread > Thread[COMMIT-LOG-WRITER,5,main] > java.nio.BufferOverflowException > at java.nio.Buffer.nextPutIndex(Buffer.java:499) > at java.nio.DirectByteBuffer.putLong(DirectByteBuffer.java:756) > at > org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:265) > at > org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:382) > at > org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:50) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at java.lang.Thread.run(Thread.java:662) > Possibly related to https://issues.apache.org/jira/browse/CASSANDRA-3615 -- 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: fix symlinks to data dir not working; patch by yukim reviewed by jbellis for CASSANDRA-5185
fix symlinks to data dir not working; patch by yukim reviewed by jbellis for
CASSANDRA-5185
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7752f018
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7752f018
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7752f018
Branch: refs/heads/cassandra-1.2
Commit: 7752f018b1cf4bbc03db77e251cd6272356087a9
Parents: f4a941e
Author: Yuki Morishita
Authored: Fri Jan 25 10:36:58 2013 -0600
Committer: Yuki Morishita
Committed: Fri Jan 25 15:41:49 2013 -0600
--
CHANGES.txt |3 +++
src/java/org/apache/cassandra/db/Directories.java |2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7752f018/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3696ca6..3a4ebe7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+1.2.2
+ * fix symlinks under data dir not working (CASSANDRA-5185)
+
1.2.1
* stream undelivered hints on decommission (CASSANDRA-5128)
* GossipingPropertyFileSnitch loads saved dc/rack info if needed
(CASSANDRA-5133)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7752f018/src/java/org/apache/cassandra/db/Directories.java
--
diff --git a/src/java/org/apache/cassandra/db/Directories.java
b/src/java/org/apache/cassandra/db/Directories.java
index bf1b695..f1db5ed 100644
--- a/src/java/org/apache/cassandra/db/Directories.java
+++ b/src/java/org/apache/cassandra/db/Directories.java
@@ -126,7 +126,7 @@ public class Directories
{
for (File dir : sstableDirectories)
{
-if
(FileUtils.getCanonicalPath(dir).startsWith(FileUtils.getCanonicalPath(dataDirectory)))
+if
(dir.getAbsolutePath().startsWith(dataDirectory.getAbsolutePath()))
return dir;
}
return null;
[2/3] git commit: fix symlinks to data dir not working; patch by yukim reviewed by jbellis for CASSANDRA-5185
fix symlinks to data dir not working; patch by yukim reviewed by jbellis for
CASSANDRA-5185
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7752f018
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7752f018
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7752f018
Branch: refs/heads/trunk
Commit: 7752f018b1cf4bbc03db77e251cd6272356087a9
Parents: f4a941e
Author: Yuki Morishita
Authored: Fri Jan 25 10:36:58 2013 -0600
Committer: Yuki Morishita
Committed: Fri Jan 25 15:41:49 2013 -0600
--
CHANGES.txt |3 +++
src/java/org/apache/cassandra/db/Directories.java |2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7752f018/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3696ca6..3a4ebe7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,6 @@
+1.2.2
+ * fix symlinks under data dir not working (CASSANDRA-5185)
+
1.2.1
* stream undelivered hints on decommission (CASSANDRA-5128)
* GossipingPropertyFileSnitch loads saved dc/rack info if needed
(CASSANDRA-5133)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7752f018/src/java/org/apache/cassandra/db/Directories.java
--
diff --git a/src/java/org/apache/cassandra/db/Directories.java
b/src/java/org/apache/cassandra/db/Directories.java
index bf1b695..f1db5ed 100644
--- a/src/java/org/apache/cassandra/db/Directories.java
+++ b/src/java/org/apache/cassandra/db/Directories.java
@@ -126,7 +126,7 @@ public class Directories
{
for (File dir : sstableDirectories)
{
-if
(FileUtils.getCanonicalPath(dir).startsWith(FileUtils.getCanonicalPath(dataDirectory)))
+if
(dir.getAbsolutePath().startsWith(dataDirectory.getAbsolutePath()))
return dir;
}
return null;
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/cassandra-1.2 f4a941e49 -> 7752f018b refs/heads/trunk b7ba0a917 -> 34f08529e Merge branch 'cassandra-1.2' into trunk Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/34f08529 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/34f08529 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/34f08529 Branch: refs/heads/trunk Commit: 34f08529ee17b6f5e5f6c740a7dc66a2e856254a Parents: b7ba0a9 7752f01 Author: Yuki Morishita Authored: Mon Jan 28 10:12:43 2013 -0600 Committer: Yuki Morishita Committed: Mon Jan 28 10:12:43 2013 -0600 -- CHANGES.txt |4 src/java/org/apache/cassandra/db/Directories.java |2 +- 2 files changed, 5 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/34f08529/CHANGES.txt -- diff --cc CHANGES.txt index 9876e37,3a4ebe7..5ae58fe --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,6 +1,14 @@@ +1.3 + * make index_interval configurable per columnfamily (CASSANDRA-3961) + * add default_tim_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) + + 1.2.2 + * fix symlinks under data dir not working (CASSANDRA-5185) + ++ 1.2.1 * stream undelivered hints on decommission (CASSANDRA-5128) * GossipingPropertyFileSnitch loads saved dc/rack info if needed (CASSANDRA-5133)
[Cassandra Wiki] Trivial Update of "Mamie7259" by Mamie7259
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Mamie7259" page has been changed by Mamie7259: http://wiki.apache.org/cassandra/Mamie7259 New page: Got nothing to say about myself really.<>I enjoy of finally being a part of apache.org.<>I really wish Im useful at all<><>Feel free to visit my homepage [[http://bristolairportparking.blogspot.com|Read More]]
svn commit: r1439405 - in /cassandra/site: publish/doc/cql3/CQL.html publish/download/index.html publish/index.html src/settings.py
Author: slebresne Date: Mon Jan 28 13:58:47 2013 New Revision: 1439405 URL: http://svn.apache.org/viewvc?rev=1439405&view=rev Log: Update website for 1.2.1 release Modified: cassandra/site/publish/doc/cql3/CQL.html cassandra/site/publish/download/index.html cassandra/site/publish/index.html cassandra/site/src/settings.py Modified: cassandra/site/publish/doc/cql3/CQL.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/doc/cql3/CQL.html?rev=1439405&r1=1439404&r2=1439405&view=diff == --- cassandra/site/publish/doc/cql3/CQL.html (original) +++ cassandra/site/publish/doc/cql3/CQL.html Mon Jan 28 13:58:47 2013 @@ -1,6 +1,6 @@ -http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>http://www.w3.org/1999/xhtml";>CQLCassandra Query Language (CQL) v3.0.0Cassandra Query Language (CQL) v3.0.0CQL SyntaxPreambleConventionsIdentifiers and keywordsConstantsComment sStatementsPrepared StatementData DefinitionCREATE KEYSPACEUSEALTER KEYSPACEDROP KEYSPACECREATE TABLEALTER TABLEDROP TABLETRUNCATECREATE INDEXDROP INDEXData ManipulationINSERTUPDATEDELETEhref="CQL.html#batchStmt">BATCHhref="CQL.html#queries">Querieshref="CQL.html#selectStmt">SELECThref="CQL.html#types">Data Typeshref="CQL.html#usingdates">Working with dateshref="CQL.html#counters">Countershref="CQL.html#collections">Working with collectionshref="CQL.html#appendixA">Appendix A: CQL Keywordshref="CQL.html#Versioning">Versioninghref="CQL.html#Changes">Changesid="CQLSyntax">CQL SyntaxPreambleThis document >describes the Cassandra Query Language (CQL) version 3. CQL v3 is not >backward compatible with CQL v2 and differs from it in numerous >ways.CQL v3 offers a model very close to SQL in the sense that d ata is put in tables containing rows of columns. For that reason, when used in this document, these terms (tables, rows and columns) have the same definition than they have in SQL. But please note that as such, they do not refer to the concept of rows and columns found in the internal implementation of Cassandra and in the thrift and CQL v2 API.ConventionsTo aid in specifying the CQL syntax, we will use the following conventions in this document:Language rules will be given in a http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form";>BNF -like notation:::= TERMINAL +http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>http://www.w3.org/1999/xhtml";>CQLCassandra Query Language (CQL) v3.0.1Cassandra Query Language (CQL) v3.0.1CQL SyntaxPreambleConventionsIdentifiers and keywordsConstantsComment sStatementsPrepared StatementData DefinitionCREATE KEYSPACEUSEALTER KEYSPACEDROP KEYSPACECREATE TABLEALTER TABLEDROP TABLETRUNCATECREATE INDEXDROP INDEXData ManipulationINSERTUPDATEDELETEhref="CQL.html#batchStmt">BATCHhref="CQL.html#queries">Querieshref="CQL.html#selectStmt">SELECThref="CQL.html#types">Data Typeshref="CQL.html#usingdates">Working with dateshref="CQL.html#usingtimeuuid">Working with @timeuuid@href="CQL.html#counters">Countershref="CQL.html#collections">Working with collectionshref="CQL.html#appendixA">Appendix A: CQL Keywordshref="CQL.html#changes">Changeshref="CQL.html#a3.0.1">3.0.1href="CQL.html#Versioning">Versioningid="CQLSyntax">CQL SyntaxPreambleThis document >describes the Cassandra Query Language (CQL) version 3. C QL v3 is not backward compatible with CQL v2 and differs from it in numerous ways. Note that this document describes the last version of the languages. However, the changes section provides the diff between the different versions of CQL v3.CQL v3 offers a model very close to SQL in the sense that data is put in tables containing rows of columns. For that reason, when used in this document, these terms (tables, rows and columns) have the same definition than they have in SQL. But please note that as such, they do not refer to the concept of rows and columns found in the internal implementation of Cassandra and in the thrift and CQL v2 API.ConventionsTo aid in specifying the CQL syntax, we will use the following conventions in this document:Language rules will be given in a http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form";>BNF -like notation: ::= TERMINAL Nonterminal symbols will have .As additional shortcut notations to BNF, we’ll use traditional regular expression’s symbols (?, + and *) to signify that a given symbol is optional and/or can be repeated. We’ll also allow parentheses to group symbols and the [ ] notation to represent any one of .The grammar is provided for documentation purposes and leave some minor details out. For instance, the last column definition in a CREATE TABLE statement is optional but supported if present even though the provided grammar in this document suggest it is not supported. Sample code will be provided in a code block:SELECT
Git Push Summary
Updated Tags: refs/tags/1.2.1-tentative [deleted] 8540974db
Git Push Summary
Updated Tags: refs/tags/cassandra-1.2.1 [created] 33c54984c
[jira] [Created] (CASSANDRA-5191) BufferOverflowException in CommitLogSegment
André Borgqvist created CASSANDRA-5191: -- Summary: BufferOverflowException in CommitLogSegment Key: CASSANDRA-5191 URL: https://issues.apache.org/jira/browse/CASSANDRA-5191 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.9 Environment: RHEL 2.6.32-220.el6.x86_64, jdk1.6.0_27 Reporter: André Borgqvist Running mixed reads, writes and deletes on a single column family in a two node cluster. After a few minutes the following appears in the system log: ERROR [COMMIT-LOG-WRITER] 2013-01-25 12:49:55,955 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[COMMIT-LOG-WRITER,5,main] java.nio.BufferOverflowException at java.nio.Buffer.nextPutIndex(Buffer.java:499) at java.nio.DirectByteBuffer.putLong(DirectByteBuffer.java:756) at org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:265) at org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:382) at org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:50) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.lang.Thread.run(Thread.java:662) Possibly related to https://issues.apache.org/jira/browse/CASSANDRA-3615 -- 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-5189) compact storage metadata is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5189:
Attachment: 5189.txt
> compact storage metadata is broken
> --
>
> Key: CASSANDRA-5189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5189
> Project: Cassandra
> Issue Type: Bug
> Components: API
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
> Fix For: 1.2.2
>
> Attachments: 5189.txt
>
>
> {noformat}
> cqlsh:foo> CREATE TABLE bar (
>... id int primary key,
>... i int
>... ) WItH COMPACT STORAGE;
> cqlsh:foo> INSERT INTO bar (id, i) VALUES (1, 2);
> Bad Request: Missing PRIMARY KEY part column1
> Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.
> cqlsh:foo> INSERT INTO bar (id, column1) VALUES (1, 2);
> Bad Request: Missing mandatory column i
> Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
