[jira] [Commented] (CASSANDRA-5338) scripts fail when paths contain space
[ https://issues.apache.org/jira/browse/CASSANDRA-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619566#comment-13619566 ] Amichai Rothman commented on CASSANDRA-5338: The duplication thing is a related thought that could prevent the issue from creeping back again in the future, and making the fix easier, but the actual bug is the whitespace handling, which is unrelated to bug #5301 (which is resolved as wontfix in any case). scripts fail when paths contain space - Key: CASSANDRA-5338 URL: https://issues.apache.org/jira/browse/CASSANDRA-5338 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.2 Environment: Kubuntu 12.10 (GNU bash 4.2.37), and Windows XP (msysgit GNU bash 3.1.0) Reporter: Amichai Rothman Priority: Minor Attachments: fix_spaces_in_paths.patch The shell scripts fail when the cassandra or java dirs contain spaces. -- 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-4180) Single-pass compaction for LCR
[
https://issues.apache.org/jira/browse/CASSANDRA-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619595#comment-13619595
]
Jason Brown commented on CASSANDRA-4180:
On the whole, LGTM.
I think Jonathan and I had the same basic notion of how to implement this, and
we ran into many of the same problems (schema loading borked hard and fast).
Admittedly, the one-off sstable reads were what kept kicking me in the shins
(repeatedly), and what kept taking me down wrong paths. I agree about the fishy
smell with knowledge of the SSTable format spread around, but minimally that's
for a another ticket.
We can probably remove the {code}output != null{code} check in
ColumnIndex.Builder.add() as LCR is no longer passing in null (on the first
pass).
Jonathan mentioned he didn't try to scrub, but I just tried it out locally, and
it failed with an OOM error. I'd look into it more, but brain power running out
this late at night. I'm attaching a file with the scrub errors. Will look into
it tomorrow.
Single-pass compaction for LCR
--
Key: CASSANDRA-4180
URL: https://issues.apache.org/jira/browse/CASSANDRA-4180
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Sylvain Lebresne
Assignee: Jonathan Ellis
Labels: compaction
Fix For: 2.0
Attachments: scrub-error.txt
LazilyCompactedRow reads all data twice to compact a row which is obviously
inefficient. The main reason we do that is to compute the row header.
However, CASSANDRA-2319 have removed the main part of that row header. What
remains is the size in bytes and the number of columns, but it should be
relatively simple to remove those, which would then remove the need for the
two-phase compaction.
--
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-4180) Single-pass compaction for LCR
[ https://issues.apache.org/jira/browse/CASSANDRA-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-4180: --- Attachment: scrub-error.txt Single-pass compaction for LCR -- Key: CASSANDRA-4180 URL: https://issues.apache.org/jira/browse/CASSANDRA-4180 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Jonathan Ellis Labels: compaction Fix For: 2.0 Attachments: scrub-error.txt LazilyCompactedRow reads all data twice to compact a row which is obviously inefficient. The main reason we do that is to compute the row header. However, CASSANDRA-2319 have removed the main part of that row header. What remains is the size in bytes and the number of columns, but it should be relatively simple to remove those, which would then remove the need for the two-phase compaction. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-5393) Add an Ack/Retry for merkle tree sending
[
https://issues.apache.org/jira/browse/CASSANDRA-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Brown reassigned CASSANDRA-5393:
--
Assignee: Jason Brown
Add an Ack/Retry for merkle tree sending
Key: CASSANDRA-5393
URL: https://issues.apache.org/jira/browse/CASSANDRA-5393
Project: Cassandra
Issue Type: Bug
Reporter: Jeremiah Jordan
Assignee: Jason Brown
Can we add an Ack/Retry around passing merle tree's around in repair? If the
following fails, the repair hangs for ever on the coordinating node.
https://github.com/apache/cassandra/blob/cassandra-1.1.10/src/java/org/apache/cassandra/service/AntiEntropyService.java#L242
{noformat}
Message message = TreeResponseVerbHandler.makeVerb(local,
validator);
if
(!validator.request.endpoint.equals(FBUtilities.getBroadcastAddress()))
logger.info(String.format([repair #%s] Sending completed
merkle tree to %s for %s, validator.request.sessionid,
validator.request.endpoint, validator.request.cf));
ms.sendOneWay(message, validator.request.endpoint);
{noformat}
If the message asking for merkle tree's gets lost, coordinating node hangs
for ever as well.
--
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-5393) Add an Ack/Retry for merkle tree sending
[
https://issues.apache.org/jira/browse/CASSANDRA-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619597#comment-13619597
]
Jason Brown commented on CASSANDRA-5393:
We've got an idea we're testing out here, and will hopefully post a patch in a
day or so.
Add an Ack/Retry for merkle tree sending
Key: CASSANDRA-5393
URL: https://issues.apache.org/jira/browse/CASSANDRA-5393
Project: Cassandra
Issue Type: Bug
Reporter: Jeremiah Jordan
Assignee: Jason Brown
Can we add an Ack/Retry around passing merle tree's around in repair? If the
following fails, the repair hangs for ever on the coordinating node.
https://github.com/apache/cassandra/blob/cassandra-1.1.10/src/java/org/apache/cassandra/service/AntiEntropyService.java#L242
{noformat}
Message message = TreeResponseVerbHandler.makeVerb(local,
validator);
if
(!validator.request.endpoint.equals(FBUtilities.getBroadcastAddress()))
logger.info(String.format([repair #%s] Sending completed
merkle tree to %s for %s, validator.request.sessionid,
validator.request.endpoint, validator.request.cf));
ms.sendOneWay(message, validator.request.endpoint);
{noformat}
If the message asking for merkle tree's gets lost, coordinating node hangs
for ever as well.
--
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 SanoraLer by SanoraLer
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The SanoraLer page has been changed by SanoraLer: http://wiki.apache.org/cassandra/SanoraLer New page: This author's name is Trinidad. She's always loved living in New Shirt.BR To ice-cubes skate is something she surely enjoys doing. Debt collecting is how she advocates for her family but she's normally wanted her own business. Check out the sought after news on her website: http://faststdtesting.com/343-W-Houston-St-Ste-308-San-Antonio-TX-Texas-78205.php
[jira] [Updated] (CASSANDRA-5407) Repair exception when getPositionsForRanges returns empty iterator
[ https://issues.apache.org/jira/browse/CASSANDRA-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-5407: --- Attachment: 0001-CASSANDRA-5407-v2.patch adds a unit test that would have found the bug Repair exception when getPositionsForRanges returns empty iterator -- Key: CASSANDRA-5407 URL: https://issues.apache.org/jira/browse/CASSANDRA-5407 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 Reporter: Marcus Eriksson Assignee: Marcus Eriksson Attachments: 0001-CASSANDRA-5407-v2.patch, 0001-Fix-repair-bug-where-getPositionsForRanges-returns-e.patch CASSANDRA-5250 broke repair, this re-adds the code from CASSANDRA-5249 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Fix writetime/ttl functions on columns with null values
Updated Branches:
refs/heads/cassandra-1.2 50aa1f707 - 65b9093d4
Fix writetime/ttl functions on columns with null values
patch by slebresne; reviewed by iamaleksey for CASSANDRA-5341
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/65b9093d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/65b9093d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/65b9093d
Branch: refs/heads/cassandra-1.2
Commit: 65b9093d4905da489e472dfd565417c6865d44c8
Parents: 50aa1f7
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Apr 2 11:38:30 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Apr 2 11:38:30 2013 +0200
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/Selection.java | 16 +++---
2 files changed, 13 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/65b9093d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ca062d6..c7d64b4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -15,6 +15,7 @@
* Correctly typecheck in CQL3 even with ReversedType (CASSANDRA-5386)
* Fix streaming compressed files when using encryption (CASSANDRA-5391)
* cassandra-all 1.2.0 pom missing netty dependency (CASSANDRA-5392)
+ * Fix writetime/ttl functions on null values (CASSANDRA-5341)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/65b9093d/src/java/org/apache/cassandra/cql3/statements/Selection.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/Selection.java
b/src/java/org/apache/cassandra/cql3/statements/Selection.java
index c42b587..983c35b 100644
--- a/src/java/org/apache/cassandra/cql3/statements/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/statements/Selection.java
@@ -248,20 +248,25 @@ public abstract class Selection
public void add(IColumn c)
{
-current.add(c == null || c.isMarkedForDelete() ? null : value(c));
+current.add(isDead(c) ? null : value(c));
if (timestamps != null)
{
-timestamps[current.size() - 1] = c.timestamp();
+timestamps[current.size() - 1] = isDead(c) ? -1 :
c.timestamp();
}
if (ttls != null)
{
int ttl = -1;
-if (c instanceof ExpiringColumn)
+if (!isDead(c) c instanceof ExpiringColumn)
ttl = ((ExpiringColumn)c).getLocalDeletionTime() - (int)
(System.currentTimeMillis() / 1000);
ttls[current.size() - 1] = ttl;
}
}
+private boolean isDead(IColumn c)
+{
+return c == null || c.isMarkedForDelete();
+}
+
public void newRow() throws InvalidRequestException
{
if (current != null)
@@ -366,7 +371,10 @@ public abstract class Selection
public ByteBuffer compute(ResultSetBuilder rs)
{
if (isWritetime)
-return ByteBufferUtil.bytes(rs.timestamps[idx]);
+{
+long ts = rs.timestamps[idx];
+return ts = 0 ? ByteBufferUtil.bytes(ts) : null;
+}
int ttl = rs.ttls[idx];
return ttl 0 ? ByteBufferUtil.bytes(ttl) : null;
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7005a780
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7005a780
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7005a780
Branch: refs/heads/trunk
Commit: 7005a780881c414c2166f743e5f9cd52f8ada3db
Parents: b73 65b9093
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Apr 2 11:40:01 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Apr 2 11:40:01 2013 +0200
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/Selection.java | 16 +++---
2 files changed, 13 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7005a780/CHANGES.txt
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7005a780/src/java/org/apache/cassandra/cql3/statements/Selection.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/Selection.java
index b322cda,983c35b..6a70130
--- a/src/java/org/apache/cassandra/cql3/statements/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/statements/Selection.java
@@@ -246,12 -246,12 +246,12 @@@ public abstract class Selectio
current.add(v);
}
-public void add(IColumn c)
+public void add(Column c)
{
- current.add(c == null || c.isMarkedForDelete() ? null : value(c));
+ current.add(isDead(c) ? null : value(c));
if (timestamps != null)
{
- timestamps[current.size() - 1] = c.timestamp();
+ timestamps[current.size() - 1] = isDead(c) ? -1 :
c.timestamp();
}
if (ttls != null)
{
[1/2] git commit: Fix writetime/ttl functions on columns with null values
Updated Branches:
refs/heads/trunk b7398 - 7005a7808
Fix writetime/ttl functions on columns with null values
patch by slebresne; reviewed by iamaleksey for CASSANDRA-5341
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/65b9093d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/65b9093d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/65b9093d
Branch: refs/heads/trunk
Commit: 65b9093d4905da489e472dfd565417c6865d44c8
Parents: 50aa1f7
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Apr 2 11:38:30 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Apr 2 11:38:30 2013 +0200
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/Selection.java | 16 +++---
2 files changed, 13 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/65b9093d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ca062d6..c7d64b4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -15,6 +15,7 @@
* Correctly typecheck in CQL3 even with ReversedType (CASSANDRA-5386)
* Fix streaming compressed files when using encryption (CASSANDRA-5391)
* cassandra-all 1.2.0 pom missing netty dependency (CASSANDRA-5392)
+ * Fix writetime/ttl functions on null values (CASSANDRA-5341)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/65b9093d/src/java/org/apache/cassandra/cql3/statements/Selection.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/Selection.java
b/src/java/org/apache/cassandra/cql3/statements/Selection.java
index c42b587..983c35b 100644
--- a/src/java/org/apache/cassandra/cql3/statements/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/statements/Selection.java
@@ -248,20 +248,25 @@ public abstract class Selection
public void add(IColumn c)
{
-current.add(c == null || c.isMarkedForDelete() ? null : value(c));
+current.add(isDead(c) ? null : value(c));
if (timestamps != null)
{
-timestamps[current.size() - 1] = c.timestamp();
+timestamps[current.size() - 1] = isDead(c) ? -1 :
c.timestamp();
}
if (ttls != null)
{
int ttl = -1;
-if (c instanceof ExpiringColumn)
+if (!isDead(c) c instanceof ExpiringColumn)
ttl = ((ExpiringColumn)c).getLocalDeletionTime() - (int)
(System.currentTimeMillis() / 1000);
ttls[current.size() - 1] = ttl;
}
}
+private boolean isDead(IColumn c)
+{
+return c == null || c.isMarkedForDelete();
+}
+
public void newRow() throws InvalidRequestException
{
if (current != null)
@@ -366,7 +371,10 @@ public abstract class Selection
public ByteBuffer compute(ResultSetBuilder rs)
{
if (isWritetime)
-return ByteBufferUtil.bytes(rs.timestamps[idx]);
+{
+long ts = rs.timestamps[idx];
+return ts = 0 ? ByteBufferUtil.bytes(ts) : null;
+}
int ttl = rs.ttls[idx];
return ttl 0 ? ByteBufferUtil.bytes(ttl) : null;
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure on builder cassandra-trunk while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/2503 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch trunk] 7005a780881c414c2166f743e5f9cd52f8ada3db Blamelist: Sylvain Lebresne sylv...@datastax.com BUILD FAILED: failed compile sincerely, -The Buildbot
git commit: Fix merge
Updated Branches:
refs/heads/trunk 7005a7808 - 0b20e139d
Fix merge
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0b20e139
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0b20e139
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0b20e139
Branch: refs/heads/trunk
Commit: 0b20e139d64faa3147ba068c367df4bffb278c47
Parents: 7005a78
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Apr 2 11:44:39 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Apr 2 11:44:39 2013 +0200
--
.../cassandra/cql3/statements/Selection.java |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0b20e139/src/java/org/apache/cassandra/cql3/statements/Selection.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/Selection.java
b/src/java/org/apache/cassandra/cql3/statements/Selection.java
index 6a70130..2f5b948 100644
--- a/src/java/org/apache/cassandra/cql3/statements/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/statements/Selection.java
@@ -262,7 +262,7 @@ public abstract class Selection
}
}
-private boolean isDead(IColumn c)
+private boolean isDead(Column c)
{
return c == null || c.isMarkedForDelete();
}
[jira] [Created] (CASSANDRA-5413) cqlsh returns map entries in wrong order
Swav Swiac created CASSANDRA-5413:
-
Summary: cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Bug
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Priority: Minor
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here but I can
send a text file without word wrapping if you need it)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details |
bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null |
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null |
{8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
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-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swav Swiac updated CASSANDRA-5413:
--
Attachment: cqlsh map sort order.txt
Sample output from tests.
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Bug
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Priority: Minor
Labels: cql3, cqlsh
Attachments: cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here but I
can send a text file without word wrapping if you need it)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
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-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swav Swiac updated CASSANDRA-5413:
--
Description:
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details |
bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null |
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null |
{8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
was:
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here but I can
send a text file without word wrapping if you need it)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details |
bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null |
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null |
{8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
buildbot success in ASF Buildbot on cassandra-trunk
The Buildbot has detected a restored build on builder cassandra-trunk while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/2504 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch trunk] 0b20e139d64faa3147ba068c367df4bffb278c47 Blamelist: Sylvain Lebresne sylv...@datastax.com Build succeeded! sincerely, -The Buildbot
[Cassandra Wiki] Trivial Update of Lila0054 by Lila0054
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Lila0054 page has been changed by Lila0054: http://wiki.apache.org/cassandra/Lila0054 New page: Daron is what people call him and the loves it. His family lives in Maryland.BR BR To do ceramics is a his wife doesn't like but he is doing. After being out off his job harmful ingredient he became an order clerk. Go to his can i find out more: http://www.satya.pl/
[jira] [Updated] (CASSANDRA-5404) NPE during cql3 select with token()
[
https://issues.apache.org/jira/browse/CASSANDRA-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5404:
Attachment: 5404.txt
Patch attached to handle the {{null}} correctly.
Let's note that the query itself is invalid because 'int' is not a function
that exists.
NPE during cql3 select with token()
---
Key: CASSANDRA-5404
URL: https://issues.apache.org/jira/browse/CASSANDRA-5404
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
Assignee: Sylvain Lebresne
Fix For: 1.2.4
Attachments: 5404.txt
A query such as: select * from Standard1 where token(key)
token(int(3030343330393233)) limit 1;
Produces:
{noformat}
WARN 17:53:44,448 Inputing CLQ3 blobs as strings (like key = '') is now
deprecated and will be removed in a future version. You should convert client
code to use a blob constant (key = 0x) instead (see
http://cassandra.apache.org/doc/cql3/CQL.html changelog section for more
info).
ERROR 17:57:52,312 Error occurred during processing of message.
java.lang.NullPointerException
at
org.apache.cassandra.cql3.functions.FunctionCall$Raw.isAssignableTo(FunctionCall.java:135)
at
org.apache.cassandra.cql3.functions.Functions.validateTypes(Functions.java:131)
at
org.apache.cassandra.cql3.functions.Functions.get(Functions.java:92)
at
org.apache.cassandra.cql3.functions.FunctionCall$Raw.prepare(FunctionCall.java:103)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.updateRestriction(SelectStatement.java:1246)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:959)
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:271)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:140)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1726)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4074)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4062)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5414) Unspecified initial_token with ByteOrderedPartitioner results in java.lang.NumberFormatException: Non-hex characters
Pas created CASSANDRA-5414: -- Summary: Unspecified initial_token with ByteOrderedPartitioner results in java.lang.NumberFormatException: Non-hex characters Key: CASSANDRA-5414 URL: https://issues.apache.org/jira/browse/CASSANDRA-5414 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Environment: Oracle JDK, java 1.7.0_07, amd64 (x86_64), on a Debian Squeeze, no virtual nodes, nothing fancy. Reporter: Pas Priority: Minor Using one seed, after adding the third node the fresh node chooses an illegal token, so it can't bootstrap itself. So I had to specify initial_token on each host manually. (Which, as far as I know, is recommended anyway for non-random partitioners.) java.lang.NumberFormatException: Non-hex characters in ^@^V73797374656d5f61757468 at org.apache.cassandra.utils.Hex.hexToBytes(Hex.java:60) at org.apache.cassandra.dht.AbstractByteOrderedPartitioner$1.fromString(AbstractByteOrderedPartitioner.java:167) at org.apache.cassandra.dht.BootStrapper$BootstrapTokenCallback.response(BootStrapper.java:230) at org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- 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-5397) Updates to PerRowSecondaryIndex don't use most current values
[ https://issues.apache.org/jira/browse/CASSANDRA-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616453#comment-13616453 ] Sam Tunnicliffe edited comment on CASSANDRA-5397 at 4/2/13 12:54 PM: - Patch extends the SecondaryIndexManager.Updater interface to add a commit() method. Behaviour for PerColumn indexes remains unchanged, with updates applied to the index immediately and so the commit is a no-op. For PerRow indexes, the updates are deferred until after the memtable update occurs, then actioned via the call to commit. I missed this in CASSANDRA-2897 partially because there are no implementations of PerRowSecondaryIndex in the codebase, so I've also added a unit test with a dummy implementation. was (Author: beobal): Patch extends the SecondaryIndexManager.Updater interface to add a commit() method. Behaviour for PerColumn indexes remains unchanged, with updates applied to the index immediately and so the commit is a no-op. For PerRow indexes, the updates are deferred until after the memtable update occurs, then actioned via the call to commit. I missed this in CASSANDRA-2987 partially because there are no implementations of PerRowSecondaryIndex in the codebase, so I've also added a unit test with a dummy implementation. Updates to PerRowSecondaryIndex don't use most current values -- Key: CASSANDRA-5397 URL: https://issues.apache.org/jira/browse/CASSANDRA-5397 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Minor Attachments: 5397.txt The way that updates to secondary indexes are performed using SecondaryIndexManager.Updater is flawed for PerRowSecondaryIndexes. Unlike PerColumnSecondaryIndexes, which only require the old new values for a single column, the expectation is that a PerRow indexer can be given just a key which it will use to retrieve the entire row (or as many columns as it requires) and perform its indexing on those columns. As the indexes are updated before the memtable atomic swap occurs, a per-row indexer may only read the previous values for the row, not the new ones that are being written. In the case of an insert, there is no previous value and so nothing is added to the index. -- 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-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-5413.
---
Resolution: Not A Problem
You should not rely on Map (or Set) entry order.
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Bug
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Priority: Minor
Labels: cql3, cqlsh
Attachments: cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
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-4973) Secondary Index stops returning rows when caching=ALL
[
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619781#comment-13619781
]
Alexei Bakanov commented on CASSANDRA-4973:
---
Enabling JNA didn't make any difference to the test. What made the difference
was running my test with latest C* like this:
Secondary Index stops returning rows when caching=ALL
-
Key: CASSANDRA-4973
URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2, 1.1.6
Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson
Attachments: secondary_index_rowcache_restart_test.py
I've been using cassandra on a project for a little while in development and
have recently suddenly started having an issue where the secondary index
stops working, this is happening on my new production system, we are not yet
live. Things work ok one moment, then suddenly queries to the cf through
the secondary index stop returning data. I've seen it happen on 3 CFs. I've
tried:
- various nodetools repair / scrub / rebuild_indexes options, none seem to
make a difference.
- Doing a 'update column family whatever with column_metadata=[]' then
repeating with my correct column_metadata definition. This seems to fix the
problem (temporarily) until it comes back.
The last time it happened I had just restarted cassandra, so it could be that
which is causing the issue, I've got the production system ok at the moment,
I will try restarting a bit later when its not being used and if I can get
the issue to reoccur I will add more information.
The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this
has not fixed it.
Here is an example of the create column family I'm using for one of the CFs
that affected:
create column family region
with column_type = 'Standard'
and comparator = 'UTF8Type'
and default_validation_class = 'BytesType'
and key_validation_class = 'UTF8Type'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and caching = 'KEYS_ONLY'
and column_metadata = [
{column_name : 'label',
validation_class : UTF8Type},
{column_name : 'countryCode',
validation_class : UTF8Type,
index_name : 'region_countryCode_idx',
index_type : 0},
]
and compression_options = {'sstable_compression' :
'org.apache.cassandra.io.compress.SnappyCompressor'};
I've noticed that CASSANDRA-4785 looks similar, in my case once the system
has the problem, it doesn't go away until I fix it.
--
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-4973) Secondary Index stops returning rows when caching=ALL
[
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619782#comment-13619782
]
Alexei Bakanov commented on CASSANDRA-4973:
---
Enabling JNA didn't make any difference to the test. What made the difference
was running my test with latest C* like this:
Secondary Index stops returning rows when caching=ALL
-
Key: CASSANDRA-4973
URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2, 1.1.6
Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson
Attachments: secondary_index_rowcache_restart_test.py
I've been using cassandra on a project for a little while in development and
have recently suddenly started having an issue where the secondary index
stops working, this is happening on my new production system, we are not yet
live. Things work ok one moment, then suddenly queries to the cf through
the secondary index stop returning data. I've seen it happen on 3 CFs. I've
tried:
- various nodetools repair / scrub / rebuild_indexes options, none seem to
make a difference.
- Doing a 'update column family whatever with column_metadata=[]' then
repeating with my correct column_metadata definition. This seems to fix the
problem (temporarily) until it comes back.
The last time it happened I had just restarted cassandra, so it could be that
which is causing the issue, I've got the production system ok at the moment,
I will try restarting a bit later when its not being used and if I can get
the issue to reoccur I will add more information.
The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this
has not fixed it.
Here is an example of the create column family I'm using for one of the CFs
that affected:
create column family region
with column_type = 'Standard'
and comparator = 'UTF8Type'
and default_validation_class = 'BytesType'
and key_validation_class = 'UTF8Type'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and caching = 'KEYS_ONLY'
and column_metadata = [
{column_name : 'label',
validation_class : UTF8Type},
{column_name : 'countryCode',
validation_class : UTF8Type,
index_name : 'region_countryCode_idx',
index_type : 0},
]
and compression_options = {'sstable_compression' :
'org.apache.cassandra.io.compress.SnappyCompressor'};
I've noticed that CASSANDRA-4785 looks similar, in my case once the system
has the problem, it doesn't go away until I fix it.
--
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] [Issue Comment Deleted] (CASSANDRA-4973) Secondary Index stops returning rows when caching=ALL
[
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Bakanov updated CASSANDRA-4973:
--
Comment: was deleted
(was: Enabling JNA didn't make any difference to the test. What made the
difference was running my test with latest C* like this:)
Secondary Index stops returning rows when caching=ALL
-
Key: CASSANDRA-4973
URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2, 1.1.6
Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson
Attachments: secondary_index_rowcache_restart_test.py
I've been using cassandra on a project for a little while in development and
have recently suddenly started having an issue where the secondary index
stops working, this is happening on my new production system, we are not yet
live. Things work ok one moment, then suddenly queries to the cf through
the secondary index stop returning data. I've seen it happen on 3 CFs. I've
tried:
- various nodetools repair / scrub / rebuild_indexes options, none seem to
make a difference.
- Doing a 'update column family whatever with column_metadata=[]' then
repeating with my correct column_metadata definition. This seems to fix the
problem (temporarily) until it comes back.
The last time it happened I had just restarted cassandra, so it could be that
which is causing the issue, I've got the production system ok at the moment,
I will try restarting a bit later when its not being used and if I can get
the issue to reoccur I will add more information.
The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this
has not fixed it.
Here is an example of the create column family I'm using for one of the CFs
that affected:
create column family region
with column_type = 'Standard'
and comparator = 'UTF8Type'
and default_validation_class = 'BytesType'
and key_validation_class = 'UTF8Type'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and caching = 'KEYS_ONLY'
and column_metadata = [
{column_name : 'label',
validation_class : UTF8Type},
{column_name : 'countryCode',
validation_class : UTF8Type,
index_name : 'region_countryCode_idx',
index_type : 0},
]
and compression_options = {'sstable_compression' :
'org.apache.cassandra.io.compress.SnappyCompressor'};
I've noticed that CASSANDRA-4785 looks similar, in my case once the system
has the problem, it doesn't go away until I fix it.
--
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-4973) Secondary Index stops returning rows when caching=ALL
[
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619781#comment-13619781
]
Alexei Bakanov edited comment on CASSANDRA-4973 at 4/2/13 1:19 PM:
---
Enabling JNA didn't make any difference to the test I made. What did make the
difference was running my test with latest C* version like this:
$ CASSANDRA_VERSION=1.2.3 nosetests secondary_index_rowcache_restart_test.py
While running the test with C* 1.2.1 and 1.2.2 randomly passed and failed, the
1.2.3 version passes every time I run it. What exactly was fixed in 1.2.3 that
makes the test pass every time is hard for me to tell:)
was (Author: alexeibakanov):
Enabling JNA didn't make any difference to the test. What made the
difference was running my test with latest C* like this:
Secondary Index stops returning rows when caching=ALL
-
Key: CASSANDRA-4973
URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2, 1.1.6
Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
Reporter: Daniel Strawson
Attachments: secondary_index_rowcache_restart_test.py
I've been using cassandra on a project for a little while in development and
have recently suddenly started having an issue where the secondary index
stops working, this is happening on my new production system, we are not yet
live. Things work ok one moment, then suddenly queries to the cf through
the secondary index stop returning data. I've seen it happen on 3 CFs. I've
tried:
- various nodetools repair / scrub / rebuild_indexes options, none seem to
make a difference.
- Doing a 'update column family whatever with column_metadata=[]' then
repeating with my correct column_metadata definition. This seems to fix the
problem (temporarily) until it comes back.
The last time it happened I had just restarted cassandra, so it could be that
which is causing the issue, I've got the production system ok at the moment,
I will try restarting a bit later when its not being used and if I can get
the issue to reoccur I will add more information.
The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this
has not fixed it.
Here is an example of the create column family I'm using for one of the CFs
that affected:
create column family region
with column_type = 'Standard'
and comparator = 'UTF8Type'
and default_validation_class = 'BytesType'
and key_validation_class = 'UTF8Type'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and caching = 'KEYS_ONLY'
and column_metadata = [
{column_name : 'label',
validation_class : UTF8Type},
{column_name : 'countryCode',
validation_class : UTF8Type,
index_name : 'region_countryCode_idx',
index_type : 0},
]
and compression_options = {'sstable_compression' :
'org.apache.cassandra.io.compress.SnappyCompressor'};
I've noticed that CASSANDRA-4785 looks similar, in my case once the system
has the problem, it doesn't go away until I fix it.
--
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-5415) Batch with timestamp failed
Alexey Tereschenko created CASSANDRA-5415:
-
Summary: Batch with timestamp failed
Key: CASSANDRA-5415
URL: https://issues.apache.org/jira/browse/CASSANDRA-5415
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Reporter: Alexey Tereschenko
When I create a prepared statement with the following CQL3:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
--
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-5415) Batch with timestamp failed
[
https://issues.apache.org/jira/browse/CASSANDRA-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Tereschenko updated CASSANDRA-5415:
--
Description:
When I create a prepared statement with the following CQL3 using Thrift
protocol:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
was:
When I create a prepared statement with the following CQL3:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
Batch with timestamp failed
---
Key: CASSANDRA-5415
URL: https://issues.apache.org/jira/browse/CASSANDRA-5415
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Reporter: Alexey Tereschenko
When I create a prepared statement with the following CQL3 using Thrift
protocol:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
--
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-5415) Batch with timestamp failed
[
https://issues.apache.org/jira/browse/CASSANDRA-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Tereschenko updated CASSANDRA-5415:
--
Description:
When I create a prepared statement with the following CQL3 using Thrift
protocol:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
All statements inside the batch have no individual USING TIMESTAMP.
was:
When I create a prepared statement with the following CQL3 using Thrift
protocol:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
Batch with timestamp failed
---
Key: CASSANDRA-5415
URL: https://issues.apache.org/jira/browse/CASSANDRA-5415
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Reporter: Alexey Tereschenko
When I create a prepared statement with the following CQL3 using Thrift
protocol:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
All statements inside the batch have no individual USING TIMESTAMP.
--
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-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619803#comment-13619803
]
Swav Swiac commented on CASSANDRA-5413:
---
In that case the documentation is wrong, the first paragraph states the
opposite:
A map is a typed set of key-value pairs, where keys are unique. Furthermore,
note that the map are internally sorted by their keys and will thus always be
returned in that order.
http://cassandra.apache.org/doc/cql3/CQL.html#collections
Since they are stored sorted returning them in that order should be simple,
unless of course cqlsh implementation uses plain HashMap rather than
LinkedHashmap.
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Bug
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Priority: Minor
Labels: cql3, cqlsh
Attachments: cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
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-5397) Updates to PerRowSecondaryIndex don't use most current values
[
https://issues.apache.org/jira/browse/CASSANDRA-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619808#comment-13619808
]
Sam Tunnicliffe commented on CASSANDRA-5397:
I don't really see how we can do that, especially as PRSI is typically
implemented outside of C* and the contract we give it is expressed in the
method signature {{public abstract void index(ByteBuffer rowKey);}} So the
assumption is that an update to a PRSI will be able to access the entire row at
index time.
Changes to AtomicSortedColumns are applied a column at a time so
MixedIndexUpdater has a guard to ensure that even when a mutation changes
multiple columns in the row, the index is only updated once. Obviously though,
until the last of these column updates occurs, the row is not fully updated. So
I see 2 options, defer the per-row indexing until we've finished updating the
row (as in my first patch), or remove the guard and apply the per-row update as
each column is updated. The second option has the benefit of not changing the
SIM.Updater api, but is potentially very inefficient.
Updates to PerRowSecondaryIndex don't use most current values
--
Key: CASSANDRA-5397
URL: https://issues.apache.org/jira/browse/CASSANDRA-5397
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.3
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
Priority: Minor
Attachments: 5397.txt
The way that updates to secondary indexes are performed using
SecondaryIndexManager.Updater is flawed for PerRowSecondaryIndexes. Unlike
PerColumnSecondaryIndexes, which only require the old new values for a
single column, the expectation is that a PerRow indexer can be given just a
key which it will use to retrieve the entire row (or as many columns as it
requires) and perform its indexing on those columns. As the indexes are
updated before the memtable atomic swap occurs, a per-row indexer may only
read the previous values for the row, not the new ones that are being
written. In the case of an insert, there is no previous value and so nothing
is added to the index.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619810#comment-13619810 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. it's supposed to reply with the ballot of a previously accepted value Ok. But then I think we have the following problem (at least I don't see what prevent this from happening): say you have 3 replica A, B, C and I'll use MRC for the 'most-recently committed' value, IPB for 'in-progress ballot' and IPU for 'in-porgress update'. I'll also use t0, t1, ... for ballots (where t0 t1 t2 ...), P0, P1, ... for proposers (any coordinator) and c0, c1, c2 for different column names (with say int values) inside the same row. * At t0, P0 wants to do cas(c0, null, 3). He prepares, gets all acks and propose c0=3 that all node acks. However, C dies before receiving the commit. At this point, we have the following states (): || Node || MRC || IPB || IPC || In storage || | A | t0 | | | c0=3 | | B | t0 | | | c0=3 | | C | | t0 | c0=3| | * At t1, P1 wants to do cas(c1, null, 5). He prepares and proposes with A and B answering (so on prepare he gets no IPB). However, during commit, B fails and only A gets it. At that point, C comes back up (but don't get the commit). The state is now: || Node || MRC || IPB || IPC || In storage || | A | t1 | | | c0=3,c1=5 | | B | t0 | t1 | c1=5| c0=3 | | C | | t0 | c0=3| | * At t2, P3 wants to do cas(c2, null, 7). He gets back from A and C. From A, he gets MRC=t1 and from B, IPB=t0. So IPB MRC, and the proposer decides he can proceed with his own value, because C is old and irrelevant. He thus propose, both A and C acknowledge and both get the final commit. The state is now: || Node || MRC || IPB || IPC || In storage || | A | t2 | | | c0=3,c1=5,c2=7 | | B | t0 | t1 | c1=5| c0=3 | | C | t2 | | | c2=7 | * Now B comes back. Then, at t3, P3 wants to do cas(c2, 7, 9). Everyone replica gets all message, the cas apply (whether B answer or not, since it's IPB is now too old) and we end-up in the following state: || Node || MRC || IPB || IPC || In storage || | A | t3 | | | c0=3,c1=5,c2=9 | | B | t3 | | | c0=3,c2=9 | | C | t3 | | | c2=9 | * Now at t4, P4 wants to do cas(c1, null, 3). The prepare will work in any case, and so P4 will read the value of c1 at QUORUM before the propose. However, if B and C answer first, then we don't have the correct value. We get c1 = null, making the CAS apply, while in theory c1 = 5 so the CAS shouldn't apply. In plain english, I think the problem is that we use successful round of CAS to serialize your CAS (which is standard). However, we delete the CAS state of the previous round pretty much as soon as one node has learn the value. We do replay the previous round if some of the replica that answer to prepare are on that previous round, but if replica are on an older round (than the previous one), we do move one, and thus might erase state while only one replica has learn, which is not ok. One option could be to ensure that a quorum of node has learned before starting a new round (i.e. accepting a new value on the prepare phase). But I think this require to keep the last-recently-committed 'value' too. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5415) Batch with timestamp failed
[
https://issues.apache.org/jira/browse/CASSANDRA-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5415:
--
Reviewer: slebresne
Priority: Minor (was: Major)
Tester: enigmacurry
Fix Version/s: 1.2.4
Assignee: Aleksey Yeschenko
Batch with timestamp failed
---
Key: CASSANDRA-5415
URL: https://issues.apache.org/jira/browse/CASSANDRA-5415
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Reporter: Alexey Tereschenko
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.2.4
When I create a prepared statement with the following CQL3 using Thrift
protocol:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
All statements inside the batch have no individual USING TIMESTAMP.
--
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-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reopened CASSANDRA-5413:
---
Assignee: Sylvain Lebresne
What do you think, Sylvain?
IMO guaranteeing an order ties our hands too closely to the implementation for
little benefit.
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Bug
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Assignee: Sylvain Lebresne
Priority: Minor
Labels: cql3, cqlsh
Attachments: cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
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-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619845#comment-13619845
]
Sylvain Lebresne commented on CASSANDRA-5413:
-
Didn't we said that having our sets sorted meant that they could be used
instead of lists in a lot of places (which is good because lists have some
downsides so should be used sparingly)?
I kind of think that guaranteeing the order can be convenient. Furthermore,
having the order might allow operations like slicing a set or map later on. And
as much as I agree that collections shouldn't be used in replacement of
creating a table, I do believe that being able to slice them can have some use,
if only API-wise (the same way that you can SELECT individual columns). At the
very least, I'm slightly uncomfortable cutting yourselves of the possibility of
adding collection slices one day.
On the other side, while it's true that guaranteeing the order ties somewhat
the implementation, I could be wrong but I'm really not concerned about that in
practice (and it's not like implementing a sorted set/map ties our hands very
strongly, even in the remote hypothesis what we'd change the implementation).
Overall, I like it the way it is and I think that just fixing cqlsh would be
easy. But, just my opinion.
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Bug
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Assignee: Sylvain Lebresne
Priority: Minor
Labels: cql3, cqlsh
Attachments: cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
=
[Cassandra Wiki] Trivial Update of DemiScarb by DemiScarb
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The DemiScarb page has been changed by DemiScarb: http://wiki.apache.org/cassandra/DemiScarb New page: Letisha Jarrell is what on earth people call him or her but she really liked that name.BR BR Her husband along with her live throughout the Missouri and your girlfriend parents live nearest. Software developing is all she does. What she really enjoys undertaking is to could magic but she is struggling in order to find time for doing it. She is running then maintaining a website here: http://www.BR biorezonans-warszawa.pl/page14.php
[jira] [Updated] (CASSANDRA-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5413:
--
Fix Version/s: 1.2.4
Assignee: Aleksey Yeschenko (was: Sylvain Lebresne)
WFM, assigning to Aleksey for cqlsh fix.
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Bug
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Assignee: Aleksey Yeschenko
Priority: Minor
Labels: cql3, cqlsh
Fix For: 1.2.4
Attachments: cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
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-5416) Support CQL map and list deletes within an update statement
Mike Schrag created CASSANDRA-5416: -- Summary: Support CQL map and list deletes within an update statement Key: CASSANDRA-5416 URL: https://issues.apache.org/jira/browse/CASSANDRA-5416 Project: Cassandra Issue Type: Wish Components: Core Affects Versions: 1.2.3 Reporter: Mike Schrag Priority: Minor Currently in CQL3, you can only issue a map or list delete from a delete statement, which is kind of a bummer, because it means you need to span two statements to perform, say, a non-collection column update along with a map-delete. It would be nice if the set removal syntax was just interpreted as key names for a map, or element values for a list. Removal by list index is a slightly funkier case, but you could do something like listValue - [1,2,3]. -- 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 GaryO32 by GaryO32
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The GaryO32 page has been changed by GaryO32: http://wiki.apache.org/cassandra/GaryO32 New page: There is nothing to write about myself at all.BR Finally a member of this site.BR I just wish I am useful at allBR BR Have a look at my webpage :: [[http://timthatthing.wordpress.com/2013/02/04/cheap-insurance-for-young-drivers/|please click the following page]]
[Cassandra Wiki] Trivial Update of ArdenPitc by ArdenPitc
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArdenPitc page has been changed by ArdenPitc: http://wiki.apache.org/cassandra/ArdenPitc New page: There is nothing to write about myself really.BR BR BR Finally a member of apache.org.BR I just hope I am useful at allBR BR Also visit my homepage :: [[http://stevesflightschool.com/modules.php?name=Your_Accountop=userinfousername=TodvjLand|click through the up coming internet page]]
[jira] [Commented] (CASSANDRA-4860) Estimated Row Cache Entry size incorrect (always 24?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619936#comment-13619936 ] Ryan McGuire commented on CASSANDRA-4860: - This one (v3 patch) is much better. Average read op rate is 26484. That's the best run I've seen on 1.2+ except for the run with my trunk-4860-revert.patch applied which has an average read op rate of 27809 (4.8% faster). Estimated Row Cache Entry size incorrect (always 24?) - Key: CASSANDRA-4860 URL: https://issues.apache.org/jira/browse/CASSANDRA-4860 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0, 1.2.3, 2.0 Reporter: Chris Burroughs Assignee: Vijay Fix For: 1.2.0 beta 3 Attachments: 0001-4860-v2.patch, 0001-4860-v3.patch, 0001-CASSANDRA-4860-for-11.patch, 0001-CASSANDRA-4860.patch, trunk-4860-revert.patch After running for several hours the RowCacheSize was suspicious low (ie 70 something MB) I used CASSANDRA-4859 to measure the size and number of entries on a node: In [3]: 1560504./65021 Out[3]: 24.0 In [4]: 2149464./89561 Out[4]: 24.0 In [6]: 7216096./300785 Out[6]: 23.990877204647838 That's RowCacheSize/RowCacheNumEntires . Just to prove I don't have crazy small rows the mean size of the row *keys* in the saved cache is 67 and Compacted row mean size: 355. No jamm errors in the log Config notes: row_cache_provider: ConcurrentLinkedHashCacheProvider row_cache_size_in_mb: 2048 Version info: * C*: 1.1.6 * centos 2.6.32-220.13.1.el6.x86_64 * java 6u31 Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) -- 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-4860) Estimated Row Cache Entry size incorrect (always 24?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619936#comment-13619936 ] Ryan McGuire edited comment on CASSANDRA-4860 at 4/2/13 3:49 PM: - This one (v3 patch) is much better. Average read op rate is 26484. That's the best run I've seen on 1.2+ except for the run with the trunk-4860-revert.patch applied which has an average read op rate of 27809 (4.8% faster). was (Author: enigmacurry): This one (v3 patch) is much better. Average read op rate is 26484. That's the best run I've seen on 1.2+ except for the run with my trunk-4860-revert.patch applied which has an average read op rate of 27809 (4.8% faster). Estimated Row Cache Entry size incorrect (always 24?) - Key: CASSANDRA-4860 URL: https://issues.apache.org/jira/browse/CASSANDRA-4860 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0, 1.2.3, 2.0 Reporter: Chris Burroughs Assignee: Vijay Fix For: 1.2.0 beta 3 Attachments: 0001-4860-v2.patch, 0001-4860-v3.patch, 0001-CASSANDRA-4860-for-11.patch, 0001-CASSANDRA-4860.patch, trunk-4860-revert.patch After running for several hours the RowCacheSize was suspicious low (ie 70 something MB) I used CASSANDRA-4859 to measure the size and number of entries on a node: In [3]: 1560504./65021 Out[3]: 24.0 In [4]: 2149464./89561 Out[4]: 24.0 In [6]: 7216096./300785 Out[6]: 23.990877204647838 That's RowCacheSize/RowCacheNumEntires . Just to prove I don't have crazy small rows the mean size of the row *keys* in the saved cache is 67 and Compacted row mean size: 355. No jamm errors in the log Config notes: row_cache_provider: ConcurrentLinkedHashCacheProvider row_cache_size_in_mb: 2048 Version info: * C*: 1.1.6 * centos 2.6.32-220.13.1.el6.x86_64 * java 6u31 Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) -- 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-5125) Support indexes on composite column components
[
https://issues.apache.org/jira/browse/CASSANDRA-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5125:
--
Reviewer: iamaleksey
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
Attachments: 0001-Refactor-aliases-into-column_metadata.patch,
0002-Generalize-CompositeIndex-for-all-column-type.patch,
0003-Handle-new-type-of-IndexExpression.patch,
0004-Handle-partition-key-indexing.patch
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
[Cassandra Wiki] Trivial Update of CorazonPa by CorazonPa
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The CorazonPa page has been changed by CorazonPa: http://wiki.apache.org/cassandra/CorazonPa New page: Carmen Spohn is this man's name and his particular wife doesn't as if it at all.BR He is really fond on fencing and he can be starting another thing along with thought. Wisconsin is the only place he's been residing with. His job is suer service representative but he's always hoped for his own small business. You can always find his web page here: http://www.BR BR kajaki-kaszuby.pl/
[jira] [Created] (CASSANDRA-5417) Push composites support in the storage engine
Sylvain Lebresne created CASSANDRA-5417:
---
Summary: Push composites support in the storage engine
Key: CASSANDRA-5417
URL: https://issues.apache.org/jira/browse/CASSANDRA-5417
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 2.0
CompositeType happens to be very useful and is now widely used: CQL3 heavily
rely on it, and super columns are now using it too internally. Besides,
CompositeType has been advised as a replacement of super columns on the thrift
side for a while, so it's safe to assume that it's generally used there too.
CompositeType has initially been introduced as just another AbstractType.
Meaning that the storage engine has no nothing whatsoever of composites being,
well, composite. This has the following drawbacks:
* Because internally a composite value is handled as just a ByteBuffer, we end
up doing a lot of extra work. Typically, each time we compare 2 composite
value, we end up deserializing the components (which, while it doesn't copy
data per-se because we just slice the global ByteBuffer, still waste some cpu
cycles and allocate a bunch of ByteBuffer objects). And since compare can be
called *a lot*, this is likely not negligible.
* This make CQL3 code uglier than necessary. Basically, CQL3 makes extensive
use of composites, and since it gets backs ByteBuffer from the internal
columns, it always have to check if it's actually a compositeType or not, and
then split it and pick the different parts it needs. It's only an API problem,
but having things exposed as composites directly would definitively make thinks
cleaner. In particular, in most cases, CQL3 don't care whether it has a
composite with only one component or a non-really-composite value, but we still
always distinguishes both cases. Lastly, if we do expose composites more
directly internally, it's not a lot more work to internalize better the
different parts of the cell name that CQL3 uses (what's the clustering key,
what's the actuall CQL3 column name, what's the collection element), making
things cleaner. Last but not least, there is currently a bunch of places where
methods take a ByteBuffer as argument and it's hard to know whether it expects
a cell name or a CQL3 column name. This is pretty error prone.
* It makes it hard (or impossible) to do a number of performance improvements.
Consider CASSANDRA-4175, I'm not really sure how you can do it properly (in
memory) if cell names are just ByteBuffer (since CQL3 column names are just one
of the component in general). But we also miss oportunities of sharing
prefixes. If we were able to share prefixes of composite names in memory we
would 1) lower the memory footprint and 2) potentially speed-up comparison (of
the prefixes) by checking reference equality first (also, doing prefix sharing
on-disk, which is a separate concern btw, might be easier to do if we do prefix
sharing in memory).
So I suggest pushing CompositeType support inside the storage engine. What I
mean by that concretely would be change the internal {{Column.name}} from
ByteBuffer to some CellName type. A CellName would API-wise just be a list of
ByteBuffer. But in practice, we'd have a specific CellName implementation for
not-really-composite names, and the truly composite implementation will allow
some prefix sharing. From an external API however, nothing would change, we
would pack the composite as usual before sending it back to the client, but at
least internally, comparison won't have to deserialize the components every
time, and CQL3 code will be cleaner.
--
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-5417) Push composites support in the storage engine
[
https://issues.apache.org/jira/browse/CASSANDRA-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619956#comment-13619956
]
Sylvain Lebresne commented on CASSANDRA-5417:
-
I have a patch almost done that I'll past soonish. I do note that said patch is
on top of CASSANDRA-5125 because some of the refactor of that latter ticket
made things simpler. So it someone feels like reviewing CASSANDRA-5125, that'll
help :)
Push composites support in the storage engine
-
Key: CASSANDRA-5417
URL: https://issues.apache.org/jira/browse/CASSANDRA-5417
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 2.0
CompositeType happens to be very useful and is now widely used: CQL3 heavily
rely on it, and super columns are now using it too internally. Besides,
CompositeType has been advised as a replacement of super columns on the
thrift side for a while, so it's safe to assume that it's generally used
there too.
CompositeType has initially been introduced as just another AbstractType.
Meaning that the storage engine has no nothing whatsoever of composites
being, well, composite. This has the following drawbacks:
* Because internally a composite value is handled as just a ByteBuffer, we
end up doing a lot of extra work. Typically, each time we compare 2 composite
value, we end up deserializing the components (which, while it doesn't copy
data per-se because we just slice the global ByteBuffer, still waste some cpu
cycles and allocate a bunch of ByteBuffer objects). And since compare can be
called *a lot*, this is likely not negligible.
* This make CQL3 code uglier than necessary. Basically, CQL3 makes extensive
use of composites, and since it gets backs ByteBuffer from the internal
columns, it always have to check if it's actually a compositeType or not, and
then split it and pick the different parts it needs. It's only an API
problem, but having things exposed as composites directly would definitively
make thinks cleaner. In particular, in most cases, CQL3 don't care whether it
has a composite with only one component or a non-really-composite value, but
we still always distinguishes both cases. Lastly, if we do expose composites
more directly internally, it's not a lot more work to internalize better
the different parts of the cell name that CQL3 uses (what's the clustering
key, what's the actuall CQL3 column name, what's the collection element),
making things cleaner. Last but not least, there is currently a bunch of
places where methods take a ByteBuffer as argument and it's hard to know
whether it expects a cell name or a CQL3 column name. This is pretty error
prone.
* It makes it hard (or impossible) to do a number of performance
improvements. Consider CASSANDRA-4175, I'm not really sure how you can do it
properly (in memory) if cell names are just ByteBuffer (since CQL3 column
names are just one of the component in general). But we also miss
oportunities of sharing prefixes. If we were able to share prefixes of
composite names in memory we would 1) lower the memory footprint and 2)
potentially speed-up comparison (of the prefixes) by checking reference
equality first (also, doing prefix sharing on-disk, which is a separate
concern btw, might be easier to do if we do prefix sharing in memory).
So I suggest pushing CompositeType support inside the storage engine. What I
mean by that concretely would be change the internal {{Column.name}} from
ByteBuffer to some CellName type. A CellName would API-wise just be a list of
ByteBuffer. But in practice, we'd have a specific CellName implementation for
not-really-composite names, and the truly composite implementation will allow
some prefix sharing. From an external API however, nothing would change, we
would pack the composite as usual before sending it back to the client, but
at least internally, comparison won't have to deserialize the components
every time, and CQL3 code will be cleaner.
--
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-5406) Allow CQL3 queries to do extra filter after getting the column slice on a composite primary key
[
https://issues.apache.org/jira/browse/CASSANDRA-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619975#comment-13619975
]
Sylvain Lebresne commented on CASSANDRA-5406:
-
While we've decided not to support this type of query as is, we could
definitively support it with the ALLOW FILTERING flag. I'll also note that
without having looked closely, I'm pretty sure some of the refactorings in
CASSANDRA-5125 would make this easier.
Allow CQL3 queries to do extra filter after getting the column slice on a
composite primary key
---
Key: CASSANDRA-5406
URL: https://issues.apache.org/jira/browse/CASSANDRA-5406
Project: Cassandra
Issue Type: Improvement
Reporter: Jeremiah Jordan
Priority: Minor
Let the following work:
{noformat}
CREATE TABLE ChequeDeDup2 (
bucketId int,
transitAba int,
transitAccount bigint,
serialNo int,
amount bigint,
subjectId uuid,
channelInd ascii,
creditAba int,
creditAccount bigint,
sourceTs timestamp,
PRIMARY KEY (bucketId, transitAba, transitAccount, serialNo,
amount, subjectId)
)
select * from ChequeDeDup2 where bucketId = 198 and transitAba = 101
and transitAccount = 198 and serialNo = 1 and amount = -1 order by
transitAba desc , transitAccount desc, serialNo desc, amount desc,
subjectId DESC limit 5;
Bad Request: PRIMARY KEY part transitAccount cannot be restricted (preceding
part transitAba is either not restricted or by a non-EQ relation)
{noformat}
The assumption seems to be that it is better to serialize all the data with
transitAba = 198 back to the client side. But it is *less* efficient for
the server to serialize all this data back to the client than it is to
execute subsequent filters.
The user should be allowed to trade off the CPU cost of filtering the data on
the server side with the IO cost of serializing all that 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] [Updated] (CASSANDRA-4860) Estimated Row Cache Entry size incorrect (always 24?)
[ https://issues.apache.org/jira/browse/CASSANDRA-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-4860: - Attachment: 4860-perf-test.zip Ryan, Micro benchmark shows v3 is better, is there any chance you are hitting the same key in the key cache often? The reason for asking is that you might have a smaller key cache since the calculation is more accurate. If yes then i would increase the keycache and try. To be clear the Meter.measure() is bug and cannot be used in production and can cause OOM. Estimated Row Cache Entry size incorrect (always 24?) - Key: CASSANDRA-4860 URL: https://issues.apache.org/jira/browse/CASSANDRA-4860 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0, 1.2.3, 2.0 Reporter: Chris Burroughs Assignee: Vijay Fix For: 1.2.0 beta 3 Attachments: 0001-4860-v2.patch, 0001-4860-v3.patch, 0001-CASSANDRA-4860-for-11.patch, 0001-CASSANDRA-4860.patch, 4860-perf-test.zip, trunk-4860-revert.patch After running for several hours the RowCacheSize was suspicious low (ie 70 something MB) I used CASSANDRA-4859 to measure the size and number of entries on a node: In [3]: 1560504./65021 Out[3]: 24.0 In [4]: 2149464./89561 Out[4]: 24.0 In [6]: 7216096./300785 Out[6]: 23.990877204647838 That's RowCacheSize/RowCacheNumEntires . Just to prove I don't have crazy small rows the mean size of the row *keys* in the saved cache is 67 and Compacted row mean size: 355. No jamm errors in the log Config notes: row_cache_provider: ConcurrentLinkedHashCacheProvider row_cache_size_in_mb: 2048 Version info: * C*: 1.1.6 * centos 2.6.32-220.13.1.el6.x86_64 * java 6u31 Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) -- 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-5293) formalize that timestamps are epoch-in-micros in 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620007#comment-13620007 ] Sylvain Lebresne commented on CASSANDRA-5293: - Just to clarity on what my opinion is here, I guess I'm just asking what is the actual suggestion in practice. I'm absolutely fine saying that from now on, new features might assume that timestamps are epoch-in-micros, and that user should update to that convention to use new features (CASSANDRA-3919 being one such feature, CASSANDRA-5062 being another one). But I'd rather avoid retro-fitting that new assumption in old code, and make tombstones deletion based on the client timestamp instead of the localDeletionTime. Again, maybe that wasn't part of the suggestion. But if that was, I think that's a bit too harsh. Again, even if people epoch-in-milliseconds, moving to epoch-in-microseconds is costly. And there is people using epoch-in-nanoseconds (see CASSANDRA-5412) for which it would be *very* costly. formalize that timestamps are epoch-in-micros in 2.0 Key: CASSANDRA-5293 URL: https://issues.apache.org/jira/browse/CASSANDRA-5293 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Fix For: 2.0 We've worked around don't assume timestamps are actually timestamps but the utility is not worth the complexity and lost opportunities to optimize this imposes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5418) repair freezing
Igor Ivanov created CASSANDRA-5418:
--
Summary: repair freezing
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2
Environment: 5 nodes, RackInferring snitch, OpenVZ VMs, Centos 6,
Oracle JVM with JNA enabled.
Reporter: Igor Ivanov
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
{quote}
Then I see frozen status in *nodetool netstats* and repair never completes.
--
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-5404) NPE during cql3 select with token()
[
https://issues.apache.org/jira/browse/CASSANDRA-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620014#comment-13620014
]
Brandon Williams commented on CASSANDRA-5404:
-
bq. Let's note that the query itself is invalid because 'int' is not a function
that exists.
Yeah, I'll admit I was trying to do something whackass there. +1
NPE during cql3 select with token()
---
Key: CASSANDRA-5404
URL: https://issues.apache.org/jira/browse/CASSANDRA-5404
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
Assignee: Sylvain Lebresne
Fix For: 1.2.4
Attachments: 5404.txt
A query such as: select * from Standard1 where token(key)
token(int(3030343330393233)) limit 1;
Produces:
{noformat}
WARN 17:53:44,448 Inputing CLQ3 blobs as strings (like key = '') is now
deprecated and will be removed in a future version. You should convert client
code to use a blob constant (key = 0x) instead (see
http://cassandra.apache.org/doc/cql3/CQL.html changelog section for more
info).
ERROR 17:57:52,312 Error occurred during processing of message.
java.lang.NullPointerException
at
org.apache.cassandra.cql3.functions.FunctionCall$Raw.isAssignableTo(FunctionCall.java:135)
at
org.apache.cassandra.cql3.functions.Functions.validateTypes(Functions.java:131)
at
org.apache.cassandra.cql3.functions.Functions.get(Functions.java:92)
at
org.apache.cassandra.cql3.functions.FunctionCall$Raw.prepare(FunctionCall.java:103)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.updateRestriction(SelectStatement.java:1246)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:959)
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:271)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:140)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1726)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4074)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4062)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Fix NPE during cql3 select with token()
Updated Branches:
refs/heads/cassandra-1.2 65b9093d4 - b82027ccb
Fix NPE during cql3 select with token()
patch by slebresne; reviewed by driftx for CASSANDRA-5404
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b82027cc
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b82027cc
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b82027cc
Branch: refs/heads/cassandra-1.2
Commit: b82027ccbc315bfd46f760204c71358e5f85b254
Parents: 65b9093
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Apr 2 19:22:48 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Apr 2 19:22:48 2013 +0200
--
CHANGES.txt|1 +
.../cassandra/cql3/functions/FunctionCall.java |6 +-
.../cassandra/cql3/statements/Selection.java |2 ++
3 files changed, 8 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b82027cc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c7d64b4..727ede8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -16,6 +16,7 @@
* Fix streaming compressed files when using encryption (CASSANDRA-5391)
* cassandra-all 1.2.0 pom missing netty dependency (CASSANDRA-5392)
* Fix writetime/ttl functions on null values (CASSANDRA-5341)
+ * Fix NPE during cql3 select with token() (CASSANDRA-5404)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b82027cc/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
--
diff --git a/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
b/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
index 01c26af..14a9b78 100644
--- a/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
+++ b/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
@@ -132,7 +132,11 @@ public class FunctionCall extends Term.NonTerminal
public boolean isAssignableTo(ColumnSpecification receiver)
{
AbstractType? returnType = Functions.getReturnType(functionName,
receiver.ksName, receiver.cfName);
-return receiver.type.asCQL3Type().equals(returnType.asCQL3Type());
+// Note: if returnType == null, it means the function doesn't
exist. We may get this if an undefined function
+// is used as argument of another, existing, function. In that
case, we return true here because we'll catch
+// the fact that the method is undefined latter anyway and with a
more helpful error message that if we were
+// to return false here.
+return returnType == null ||
receiver.type.asCQL3Type().equals(returnType.asCQL3Type());
}
@Override
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b82027cc/src/java/org/apache/cassandra/cql3/statements/Selection.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/Selection.java
b/src/java/org/apache/cassandra/cql3/statements/Selection.java
index 983c35b..e4e59c5 100644
--- a/src/java/org/apache/cassandra/cql3/statements/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/statements/Selection.java
@@ -117,6 +117,8 @@ public abstract class Selection
args.add(makeSelector(cfDef, rawArg, names, null));
AbstractType? returnType =
Functions.getReturnType(withFun.functionName, cfDef.cfm.ksName,
cfDef.cfm.cfName);
+if (returnType == null)
+throw new InvalidRequestException(String.format(Unknown
function '%s', withFun.functionName));
ColumnSpecification spec = makeFunctionSpec(cfDef, withFun,
returnType);
Function fun = Functions.get(withFun.functionName, args, spec);
if (metadata != null)
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b2a949ec Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b2a949ec Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b2a949ec Branch: refs/heads/trunk Commit: b2a949ecda7d54f981a39af1b5aac8f50c0a88f9 Parents: 0b20e13 b82027c Author: Sylvain Lebresne sylv...@datastax.com Authored: Tue Apr 2 19:23:48 2013 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Tue Apr 2 19:23:48 2013 +0200 -- CHANGES.txt|1 + .../cassandra/cql3/functions/FunctionCall.java |6 +- .../cassandra/cql3/statements/Selection.java |2 ++ 3 files changed, 8 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/b2a949ec/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/b2a949ec/src/java/org/apache/cassandra/cql3/statements/Selection.java --
[1/2] git commit: Fix NPE during cql3 select with token()
Updated Branches:
refs/heads/trunk 0b20e139d - b2a949ecd
Fix NPE during cql3 select with token()
patch by slebresne; reviewed by driftx for CASSANDRA-5404
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b82027cc
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b82027cc
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b82027cc
Branch: refs/heads/trunk
Commit: b82027ccbc315bfd46f760204c71358e5f85b254
Parents: 65b9093
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Apr 2 19:22:48 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Apr 2 19:22:48 2013 +0200
--
CHANGES.txt|1 +
.../cassandra/cql3/functions/FunctionCall.java |6 +-
.../cassandra/cql3/statements/Selection.java |2 ++
3 files changed, 8 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b82027cc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c7d64b4..727ede8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -16,6 +16,7 @@
* Fix streaming compressed files when using encryption (CASSANDRA-5391)
* cassandra-all 1.2.0 pom missing netty dependency (CASSANDRA-5392)
* Fix writetime/ttl functions on null values (CASSANDRA-5341)
+ * Fix NPE during cql3 select with token() (CASSANDRA-5404)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b82027cc/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
--
diff --git a/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
b/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
index 01c26af..14a9b78 100644
--- a/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
+++ b/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
@@ -132,7 +132,11 @@ public class FunctionCall extends Term.NonTerminal
public boolean isAssignableTo(ColumnSpecification receiver)
{
AbstractType? returnType = Functions.getReturnType(functionName,
receiver.ksName, receiver.cfName);
-return receiver.type.asCQL3Type().equals(returnType.asCQL3Type());
+// Note: if returnType == null, it means the function doesn't
exist. We may get this if an undefined function
+// is used as argument of another, existing, function. In that
case, we return true here because we'll catch
+// the fact that the method is undefined latter anyway and with a
more helpful error message that if we were
+// to return false here.
+return returnType == null ||
receiver.type.asCQL3Type().equals(returnType.asCQL3Type());
}
@Override
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b82027cc/src/java/org/apache/cassandra/cql3/statements/Selection.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/Selection.java
b/src/java/org/apache/cassandra/cql3/statements/Selection.java
index 983c35b..e4e59c5 100644
--- a/src/java/org/apache/cassandra/cql3/statements/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/statements/Selection.java
@@ -117,6 +117,8 @@ public abstract class Selection
args.add(makeSelector(cfDef, rawArg, names, null));
AbstractType? returnType =
Functions.getReturnType(withFun.functionName, cfDef.cfm.ksName,
cfDef.cfm.cfName);
+if (returnType == null)
+throw new InvalidRequestException(String.format(Unknown
function '%s', withFun.functionName));
ColumnSpecification spec = makeFunctionSpec(cfDef, withFun,
returnType);
Function fun = Functions.get(withFun.functionName, args, spec);
if (metadata != null)
[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:
Attachment: (was:
0002-Generalize-CompositeIndex-for-all-column-type.patch)
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
Attachments: 0001-Refactor-aliases-into-column_metadata.txt,
0002-Generalize-CompositeIndex-for-all-column-type.txt,
0003-Handle-new-type-of-IndexExpression.txt,
0004-Handle-partition-key-indexing.txt
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] [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:
Attachment: (was: 0001-Refactor-aliases-into-column_metadata.patch)
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
Attachments: 0001-Refactor-aliases-into-column_metadata.txt,
0002-Generalize-CompositeIndex-for-all-column-type.txt,
0003-Handle-new-type-of-IndexExpression.txt,
0004-Handle-partition-key-indexing.txt
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] [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:
Attachment: (was: 0003-Handle-new-type-of-IndexExpression.patch)
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
Attachments: 0001-Refactor-aliases-into-column_metadata.txt,
0002-Generalize-CompositeIndex-for-all-column-type.txt,
0003-Handle-new-type-of-IndexExpression.txt,
0004-Handle-partition-key-indexing.txt
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] [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:
Attachment: (was: 0004-Handle-partition-key-indexing.patch)
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
Attachments: 0001-Refactor-aliases-into-column_metadata.txt,
0002-Generalize-CompositeIndex-for-all-column-type.txt,
0003-Handle-new-type-of-IndexExpression.txt,
0004-Handle-partition-key-indexing.txt
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] [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:
Attachment: 0004-Handle-partition-key-indexing.txt
0003-Handle-new-type-of-IndexExpression.txt
0002-Generalize-CompositeIndex-for-all-column-type.txt
0001-Refactor-aliases-into-column_metadata.txt
Rebased patches attached.
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
Attachments: 0001-Refactor-aliases-into-column_metadata.txt,
0002-Generalize-CompositeIndex-for-all-column-type.txt,
0003-Handle-new-type-of-IndexExpression.txt,
0004-Handle-partition-key-indexing.txt
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
git commit: Fix cf name extraction from manifest in Directories.migrateFile()
Updated Branches:
refs/heads/cassandra-1.1 b4d26bb4e - d4744e178
Fix cf name extraction from manifest in Directories.migrateFile()
patch by Marcus Eriksson; reviewed by Aleksey Yeschenko for
CASSANDRA-5242
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d4744e17
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d4744e17
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d4744e17
Branch: refs/heads/cassandra-1.1
Commit: d4744e178df071dbffe74499335d8ca6fd7c395e
Parents: b4d26bb
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Apr 2 20:54:06 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Apr 2 20:54:06 2013 +0300
--
CHANGES.txt |1 +
src/java/org/apache/cassandra/db/Directories.java | 10 +-
2 files changed, 10 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d4744e17/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0580d15..d82bb74 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -11,6 +11,7 @@
* Add UseTLAB JVM flag (CASSANDRA-5361)
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
+ * Fix cf name extraction from manifest in Directories.migrateFile()
(CASSANDRA-5242)
1.1.10
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d4744e17/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 7ee2823..7867875 100644
--- a/src/java/org/apache/cassandra/db/Directories.java
+++ b/src/java/org/apache/cassandra/db/Directories.java
@@ -554,7 +554,7 @@ public class Directories
String name = file.getName();
boolean isManifest = name.endsWith(LeveledManifest.EXTENSION);
String cfname = isManifest
- ? name.substring(0, name.length() -
LeveledManifest.EXTENSION.length())
+ ? getCfNameFromManifest(name)
: name.substring(0,
name.indexOf(Component.separator));
int idx = cfname.indexOf(SECONDARY_INDEX_NAME_SEPARATOR); // idx
0 = secondary index
@@ -571,6 +571,14 @@ public class Directories
}
}
+private static String getCfNameFromManifest(String name)
+{
+String withoutExt = name.substring(0, name.length() -
LeveledManifest.EXTENSION.length());
+return withoutExt.endsWith(-old) || withoutExt.endsWith(-tmp)
+? withoutExt.substring(0, withoutExt.length() - 4)
+: withoutExt;
+}
+
// Hack for tests, don't use otherwise
static void overrideDataDirectoriesForTest(String loc)
{
[2/2] git commit: Merge branch 'cassandra-1.1' into cassandra-1.2
Merge branch 'cassandra-1.1' into cassandra-1.2 Conflicts: CHANGES.txt src/java/org/apache/cassandra/db/Directories.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2156fb22 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2156fb22 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2156fb22 Branch: refs/heads/cassandra-1.2 Commit: 2156fb22e6455a0f7b5da34bbe9b7cca3ab9c037 Parents: b82027c d4744e1 Author: Aleksey Yeschenko alek...@apache.org Authored: Tue Apr 2 21:05:16 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Tue Apr 2 21:05:16 2013 +0300 -- CHANGES.txt |1 + src/java/org/apache/cassandra/db/Directories.java | 10 +- 2 files changed, 10 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2156fb22/CHANGES.txt -- diff --cc CHANGES.txt index 727ede8,d82bb74..273b6e6 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,51 -1,4 +1,52 @@@ -1.1.11 +1.2.4 + * Change default stream throughput from 400 to 200 mbps (CASSANDRA-5036) + * Gossiper logs DOWN for symmetry with UP (CASSANDRA-5187) + * Fix mixing prepared statements between keyspaces (CASSANDRA-5352) + * Fix consistency level during bootstrap - strike 3 (CASSANDRA-5354) + * Fix transposed arguments in AlreadyExistsException (CASSANDRA-5362) + * Improve asynchronous hint delivery (CASSANDRA-5179) + * Fix Guava dependency version (12.0 - 13.0.1) for Maven (CASSANDRA-5364) + * Validate that provided CQL3 collection value are 64K (CASSANDRA-5355) + * Make upgradeSSTable skip current version sstables by default (CASSANDRA-5366) + * Optimize min/max timestamp collection (CASSANDRA-5373) + * Invalid streamId in cql binary protocol when using invalid CL (CASSANDRA-5164) + * Fix validation for IN where clauses with collections (CASSANDRA-5376) + * Copy resultSet on count query to avoid ConcurrentModificationException (CASSANDRA-5382) + * Correctly typecheck in CQL3 even with ReversedType (CASSANDRA-5386) + * Fix streaming compressed files when using encryption (CASSANDRA-5391) + * cassandra-all 1.2.0 pom missing netty dependency (CASSANDRA-5392) + * Fix writetime/ttl functions on null values (CASSANDRA-5341) + * Fix NPE during cql3 select with token() (CASSANDRA-5404) +Merged from 1.1: + * cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052) + * Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372) ++ * Fix cf name extraction from manifest in Directories.migrateFile() (CASSANDRA-5242) + + +1.2.3 + * add check for sstable overlap within a level on startup (CASSANDRA-5327) + * replace ipv6 colons in jmx object names (CASSANDRA-5298, 5328) + * Avoid allocating SSTableBoundedScanner during repair when the range does + not intersect the sstable (CASSANDRA-5249) + * Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292) + * Fix composite comparator with super columns (CASSANDRA-5287) + * Fix insufficient validation of UPDATE queries against counter cfs + (CASSANDRA-5300) + * Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285) + * Handle null values when executing prepared statement (CASSANDRA-5081) + * Add netty to pom dependencies (CASSANDRA-5181) + * Include type arguments in Thrift CQLPreparedResult (CASSANDRA-5311) + * Fix compaction not removing columns when bf_fp_ratio is 1 (CASSANDRA-5182) + * cli: Warn about missing CQL3 tables in schema descriptions (CASSANDRA-5309) + * Re-enable unknown option in replication/compaction strategies option for + backward compatibility (CASSANDRA-4795) + * Add binary protocol support to stress (CASSANDRA-4993) + * cqlsh: Fix COPY FROM value quoting and null handling (CASSANDRA-5305) + * Fix repair -pr for vnodes (CASSANDRA-5329) + * Relax CL for auth queries for non-default users (CASSANDRA-5310) + * Fix AssertionError during repair (CASSANDRA-5245) + * Don't announce migrations to pre-1.2 nodes (CASSANDRA-5334) +Merged from 1.1: * Update offline scrub for 1.0 - 1.1 directory structure (CASSANDRA-5195) * add tmp flag to Descriptor hashcode (CASSANDRA-4021) * fix logging of Found table data in data directories when only system tables http://git-wip-us.apache.org/repos/asf/cassandra/blob/2156fb22/src/java/org/apache/cassandra/db/Directories.java -- diff --cc src/java/org/apache/cassandra/db/Directories.java index c0af0da,7867875..e80e05d --- a/src/java/org/apache/cassandra/db/Directories.java +++ b/src/java/org/apache/cassandra/db/Directories.java @@@ -639,37 -546,28 +639,37 @@@ public class Directorie
[1/2] git commit: Fix cf name extraction from manifest in Directories.migrateFile()
Updated Branches:
refs/heads/cassandra-1.2 b82027ccb - 2156fb22e
Fix cf name extraction from manifest in Directories.migrateFile()
patch by Marcus Eriksson; reviewed by Aleksey Yeschenko for
CASSANDRA-5242
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d4744e17
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d4744e17
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d4744e17
Branch: refs/heads/cassandra-1.2
Commit: d4744e178df071dbffe74499335d8ca6fd7c395e
Parents: b4d26bb
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Apr 2 20:54:06 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Apr 2 20:54:06 2013 +0300
--
CHANGES.txt |1 +
src/java/org/apache/cassandra/db/Directories.java | 10 +-
2 files changed, 10 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d4744e17/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0580d15..d82bb74 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -11,6 +11,7 @@
* Add UseTLAB JVM flag (CASSANDRA-5361)
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
+ * Fix cf name extraction from manifest in Directories.migrateFile()
(CASSANDRA-5242)
1.1.10
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d4744e17/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 7ee2823..7867875 100644
--- a/src/java/org/apache/cassandra/db/Directories.java
+++ b/src/java/org/apache/cassandra/db/Directories.java
@@ -554,7 +554,7 @@ public class Directories
String name = file.getName();
boolean isManifest = name.endsWith(LeveledManifest.EXTENSION);
String cfname = isManifest
- ? name.substring(0, name.length() -
LeveledManifest.EXTENSION.length())
+ ? getCfNameFromManifest(name)
: name.substring(0,
name.indexOf(Component.separator));
int idx = cfname.indexOf(SECONDARY_INDEX_NAME_SEPARATOR); // idx
0 = secondary index
@@ -571,6 +571,14 @@ public class Directories
}
}
+private static String getCfNameFromManifest(String name)
+{
+String withoutExt = name.substring(0, name.length() -
LeveledManifest.EXTENSION.length());
+return withoutExt.endsWith(-old) || withoutExt.endsWith(-tmp)
+? withoutExt.substring(0, withoutExt.length() - 4)
+: withoutExt;
+}
+
// Hack for tests, don't use otherwise
static void overrideDataDirectoriesForTest(String loc)
{
[1/3] git commit: Fix cf name extraction from manifest in Directories.migrateFile()
Updated Branches:
refs/heads/trunk b2a949ecd - 313c79a1d
Fix cf name extraction from manifest in Directories.migrateFile()
patch by Marcus Eriksson; reviewed by Aleksey Yeschenko for
CASSANDRA-5242
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d4744e17
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d4744e17
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d4744e17
Branch: refs/heads/trunk
Commit: d4744e178df071dbffe74499335d8ca6fd7c395e
Parents: b4d26bb
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Apr 2 20:54:06 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Apr 2 20:54:06 2013 +0300
--
CHANGES.txt |1 +
src/java/org/apache/cassandra/db/Directories.java | 10 +-
2 files changed, 10 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d4744e17/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0580d15..d82bb74 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -11,6 +11,7 @@
* Add UseTLAB JVM flag (CASSANDRA-5361)
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
+ * Fix cf name extraction from manifest in Directories.migrateFile()
(CASSANDRA-5242)
1.1.10
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d4744e17/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 7ee2823..7867875 100644
--- a/src/java/org/apache/cassandra/db/Directories.java
+++ b/src/java/org/apache/cassandra/db/Directories.java
@@ -554,7 +554,7 @@ public class Directories
String name = file.getName();
boolean isManifest = name.endsWith(LeveledManifest.EXTENSION);
String cfname = isManifest
- ? name.substring(0, name.length() -
LeveledManifest.EXTENSION.length())
+ ? getCfNameFromManifest(name)
: name.substring(0,
name.indexOf(Component.separator));
int idx = cfname.indexOf(SECONDARY_INDEX_NAME_SEPARATOR); // idx
0 = secondary index
@@ -571,6 +571,14 @@ public class Directories
}
}
+private static String getCfNameFromManifest(String name)
+{
+String withoutExt = name.substring(0, name.length() -
LeveledManifest.EXTENSION.length());
+return withoutExt.endsWith(-old) || withoutExt.endsWith(-tmp)
+? withoutExt.substring(0, withoutExt.length() - 4)
+: withoutExt;
+}
+
// Hack for tests, don't use otherwise
static void overrideDataDirectoriesForTest(String loc)
{
[2/3] git commit: Merge branch 'cassandra-1.1' into cassandra-1.2
Merge branch 'cassandra-1.1' into cassandra-1.2 Conflicts: CHANGES.txt src/java/org/apache/cassandra/db/Directories.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2156fb22 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2156fb22 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2156fb22 Branch: refs/heads/trunk Commit: 2156fb22e6455a0f7b5da34bbe9b7cca3ab9c037 Parents: b82027c d4744e1 Author: Aleksey Yeschenko alek...@apache.org Authored: Tue Apr 2 21:05:16 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Tue Apr 2 21:05:16 2013 +0300 -- CHANGES.txt |1 + src/java/org/apache/cassandra/db/Directories.java | 10 +- 2 files changed, 10 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2156fb22/CHANGES.txt -- diff --cc CHANGES.txt index 727ede8,d82bb74..273b6e6 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,51 -1,4 +1,52 @@@ -1.1.11 +1.2.4 + * Change default stream throughput from 400 to 200 mbps (CASSANDRA-5036) + * Gossiper logs DOWN for symmetry with UP (CASSANDRA-5187) + * Fix mixing prepared statements between keyspaces (CASSANDRA-5352) + * Fix consistency level during bootstrap - strike 3 (CASSANDRA-5354) + * Fix transposed arguments in AlreadyExistsException (CASSANDRA-5362) + * Improve asynchronous hint delivery (CASSANDRA-5179) + * Fix Guava dependency version (12.0 - 13.0.1) for Maven (CASSANDRA-5364) + * Validate that provided CQL3 collection value are 64K (CASSANDRA-5355) + * Make upgradeSSTable skip current version sstables by default (CASSANDRA-5366) + * Optimize min/max timestamp collection (CASSANDRA-5373) + * Invalid streamId in cql binary protocol when using invalid CL (CASSANDRA-5164) + * Fix validation for IN where clauses with collections (CASSANDRA-5376) + * Copy resultSet on count query to avoid ConcurrentModificationException (CASSANDRA-5382) + * Correctly typecheck in CQL3 even with ReversedType (CASSANDRA-5386) + * Fix streaming compressed files when using encryption (CASSANDRA-5391) + * cassandra-all 1.2.0 pom missing netty dependency (CASSANDRA-5392) + * Fix writetime/ttl functions on null values (CASSANDRA-5341) + * Fix NPE during cql3 select with token() (CASSANDRA-5404) +Merged from 1.1: + * cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052) + * Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372) ++ * Fix cf name extraction from manifest in Directories.migrateFile() (CASSANDRA-5242) + + +1.2.3 + * add check for sstable overlap within a level on startup (CASSANDRA-5327) + * replace ipv6 colons in jmx object names (CASSANDRA-5298, 5328) + * Avoid allocating SSTableBoundedScanner during repair when the range does + not intersect the sstable (CASSANDRA-5249) + * Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292) + * Fix composite comparator with super columns (CASSANDRA-5287) + * Fix insufficient validation of UPDATE queries against counter cfs + (CASSANDRA-5300) + * Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285) + * Handle null values when executing prepared statement (CASSANDRA-5081) + * Add netty to pom dependencies (CASSANDRA-5181) + * Include type arguments in Thrift CQLPreparedResult (CASSANDRA-5311) + * Fix compaction not removing columns when bf_fp_ratio is 1 (CASSANDRA-5182) + * cli: Warn about missing CQL3 tables in schema descriptions (CASSANDRA-5309) + * Re-enable unknown option in replication/compaction strategies option for + backward compatibility (CASSANDRA-4795) + * Add binary protocol support to stress (CASSANDRA-4993) + * cqlsh: Fix COPY FROM value quoting and null handling (CASSANDRA-5305) + * Fix repair -pr for vnodes (CASSANDRA-5329) + * Relax CL for auth queries for non-default users (CASSANDRA-5310) + * Fix AssertionError during repair (CASSANDRA-5245) + * Don't announce migrations to pre-1.2 nodes (CASSANDRA-5334) +Merged from 1.1: * Update offline scrub for 1.0 - 1.1 directory structure (CASSANDRA-5195) * add tmp flag to Descriptor hashcode (CASSANDRA-4021) * fix logging of Found table data in data directories when only system tables http://git-wip-us.apache.org/repos/asf/cassandra/blob/2156fb22/src/java/org/apache/cassandra/db/Directories.java -- diff --cc src/java/org/apache/cassandra/db/Directories.java index c0af0da,7867875..e80e05d --- a/src/java/org/apache/cassandra/db/Directories.java +++ b/src/java/org/apache/cassandra/db/Directories.java @@@ -639,37 -546,28 +639,37 @@@ public class Directorie
buildbot failure in ASF Buildbot on cassandra-1.1
The Buildbot has detected a new failure on builder cassandra-1.1 while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-1.1/builds/161 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra-1.1] d4744e178df071dbffe74499335d8ca6fd7c395e Blamelist: Aleksey Yeschenko alek...@apache.org BUILD FAILED: failed shell sincerely, -The Buildbot
[jira] [Commented] (CASSANDRA-5293) formalize that timestamps are epoch-in-micros in 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620099#comment-13620099 ] Jonathan Ellis commented on CASSANDRA-5293: --- That sounds reasonable. formalize that timestamps are epoch-in-micros in 2.0 Key: CASSANDRA-5293 URL: https://issues.apache.org/jira/browse/CASSANDRA-5293 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Fix For: 2.0 We've worked around don't assume timestamps are actually timestamps but the utility is not worth the complexity and lost opportunities to optimize this imposes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: IndexHelper.skipBloomFilters won't skip non-SHA filters patch by Carl Yeksigian; reviewed by jasobrown for CASSANDRA-5385
Updated Branches:
refs/heads/cassandra-1.2 2156fb22e - 4f75875c2
IndexHelper.skipBloomFilters won't skip non-SHA filters
patch by Carl Yeksigian; reviewed by jasobrown for CASSANDRA-5385
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4f75875c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4f75875c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4f75875c
Branch: refs/heads/cassandra-1.2
Commit: 4f75875c2ec1b5324d2c4afea5251fb02fadf268
Parents: 2156fb2
Author: Jason Brown jasedbr...@gmail.com
Authored: Tue Apr 2 11:23:54 2013 -0700
Committer: Jason Brown jasedbr...@gmail.com
Committed: Tue Apr 2 11:23:54 2013 -0700
--
CHANGES.txt|1 +
.../db/columniterator/IndexedSliceReader.java | 10 +-
.../db/columniterator/SimpleSliceReader.java |8 +-
.../apache/cassandra/io/sstable/IndexHelper.java | 23 +-
.../io/sstable/SSTableIdentityIterator.java|9 +-
test/unit/org/apache/cassandra/db/ScrubTest.java | 243 ---
6 files changed, 30 insertions(+), 264 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4f75875c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 273b6e6..7e906ce 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -17,6 +17,7 @@
* cassandra-all 1.2.0 pom missing netty dependency (CASSANDRA-5392)
* Fix writetime/ttl functions on null values (CASSANDRA-5341)
* Fix NPE during cql3 select with token() (CASSANDRA-5404)
+ * IndexHelper.skipBloomFilters won't skip non-SHA filters (CASSANDRA-5385)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4f75875c/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
--
diff --git
a/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
b/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
index db0130e..9b34a6a 100644
--- a/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
+++ b/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
@@ -33,6 +33,7 @@ import org.apache.cassandra.db.RowIndexEntry;
import org.apache.cassandra.db.filter.ColumnSlice;
import org.apache.cassandra.db.marshal.AbstractType;
import org.apache.cassandra.io.sstable.CorruptSSTableException;
+import org.apache.cassandra.io.sstable.Descriptor;
import org.apache.cassandra.io.sstable.IndexHelper;
import org.apache.cassandra.io.sstable.IndexHelper.IndexInfo;
import org.apache.cassandra.io.sstable.SSTableReader;
@@ -74,14 +75,15 @@ class IndexedSliceReader extends
AbstractIteratorOnDiskAtom implements OnDiskA
try
{
-if (sstable.descriptor.version.hasPromotedIndexes)
+Descriptor.Version version = sstable.descriptor.version;
+if (version.hasPromotedIndexes)
{
this.indexes = indexEntry.columnsIndex();
if (indexes.isEmpty())
{
setToRowStart(sstable, indexEntry, input);
this.emptyColumnFamily =
ColumnFamily.create(sstable.metadata);
-
emptyColumnFamily.delete(DeletionInfo.serializer().deserializeFromSSTable(file,
sstable.descriptor.version));
+
emptyColumnFamily.delete(DeletionInfo.serializer().deserializeFromSSTable(file,
version));
fetcher = new SimpleBlockFetcher();
}
else
@@ -94,10 +96,10 @@ class IndexedSliceReader extends
AbstractIteratorOnDiskAtom implements OnDiskA
else
{
setToRowStart(sstable, indexEntry, input);
-IndexHelper.skipBloomFilter(file);
+IndexHelper.skipBloomFilter(file, version.filterType);
this.indexes = IndexHelper.deserializeIndex(file);
this.emptyColumnFamily = ColumnFamily.create(sstable.metadata);
-
emptyColumnFamily.delete(DeletionInfo.serializer().deserializeFromSSTable(file,
sstable.descriptor.version));
+
emptyColumnFamily.delete(DeletionInfo.serializer().deserializeFromSSTable(file,
version));
fetcher = indexes.isEmpty()
? new SimpleBlockFetcher()
: new IndexedBlockFetcher(file.getFilePointer() + 4);
// We still have the column count to
[jira] [Commented] (CASSANDRA-5418) repair freezing
[
https://issues.apache.org/jira/browse/CASSANDRA-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620117#comment-13620117
]
Brandon Williams commented on CASSANDRA-5418:
-
You have corruption and need to run scrub first. That said, we could probably
at least abort the repair session in this case. What do you think [~yukim]?
repair freezing
---
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2
Environment: 5 nodes, RackInferring snitch, OpenVZ VMs, Centos 6,
Oracle JVM with JNA enabled.
Reporter: Igor Ivanov
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
[1/2] git commit: IndexHelper.skipBloomFilters won't skip non-SHA filters patch by Carl Yeksigian; reviewed by jasobrown for CASSANDRA-5385
Updated Branches:
refs/heads/trunk 313c79a1d - ae1f7be73
IndexHelper.skipBloomFilters won't skip non-SHA filters
patch by Carl Yeksigian; reviewed by jasobrown for CASSANDRA-5385
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4f75875c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4f75875c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4f75875c
Branch: refs/heads/trunk
Commit: 4f75875c2ec1b5324d2c4afea5251fb02fadf268
Parents: 2156fb2
Author: Jason Brown jasedbr...@gmail.com
Authored: Tue Apr 2 11:23:54 2013 -0700
Committer: Jason Brown jasedbr...@gmail.com
Committed: Tue Apr 2 11:23:54 2013 -0700
--
CHANGES.txt|1 +
.../db/columniterator/IndexedSliceReader.java | 10 +-
.../db/columniterator/SimpleSliceReader.java |8 +-
.../apache/cassandra/io/sstable/IndexHelper.java | 23 +-
.../io/sstable/SSTableIdentityIterator.java|9 +-
test/unit/org/apache/cassandra/db/ScrubTest.java | 243 ---
6 files changed, 30 insertions(+), 264 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4f75875c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 273b6e6..7e906ce 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -17,6 +17,7 @@
* cassandra-all 1.2.0 pom missing netty dependency (CASSANDRA-5392)
* Fix writetime/ttl functions on null values (CASSANDRA-5341)
* Fix NPE during cql3 select with token() (CASSANDRA-5404)
+ * IndexHelper.skipBloomFilters won't skip non-SHA filters (CASSANDRA-5385)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4f75875c/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
--
diff --git
a/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
b/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
index db0130e..9b34a6a 100644
--- a/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
+++ b/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
@@ -33,6 +33,7 @@ import org.apache.cassandra.db.RowIndexEntry;
import org.apache.cassandra.db.filter.ColumnSlice;
import org.apache.cassandra.db.marshal.AbstractType;
import org.apache.cassandra.io.sstable.CorruptSSTableException;
+import org.apache.cassandra.io.sstable.Descriptor;
import org.apache.cassandra.io.sstable.IndexHelper;
import org.apache.cassandra.io.sstable.IndexHelper.IndexInfo;
import org.apache.cassandra.io.sstable.SSTableReader;
@@ -74,14 +75,15 @@ class IndexedSliceReader extends
AbstractIteratorOnDiskAtom implements OnDiskA
try
{
-if (sstable.descriptor.version.hasPromotedIndexes)
+Descriptor.Version version = sstable.descriptor.version;
+if (version.hasPromotedIndexes)
{
this.indexes = indexEntry.columnsIndex();
if (indexes.isEmpty())
{
setToRowStart(sstable, indexEntry, input);
this.emptyColumnFamily =
ColumnFamily.create(sstable.metadata);
-
emptyColumnFamily.delete(DeletionInfo.serializer().deserializeFromSSTable(file,
sstable.descriptor.version));
+
emptyColumnFamily.delete(DeletionInfo.serializer().deserializeFromSSTable(file,
version));
fetcher = new SimpleBlockFetcher();
}
else
@@ -94,10 +96,10 @@ class IndexedSliceReader extends
AbstractIteratorOnDiskAtom implements OnDiskA
else
{
setToRowStart(sstable, indexEntry, input);
-IndexHelper.skipBloomFilter(file);
+IndexHelper.skipBloomFilter(file, version.filterType);
this.indexes = IndexHelper.deserializeIndex(file);
this.emptyColumnFamily = ColumnFamily.create(sstable.metadata);
-
emptyColumnFamily.delete(DeletionInfo.serializer().deserializeFromSSTable(file,
sstable.descriptor.version));
+
emptyColumnFamily.delete(DeletionInfo.serializer().deserializeFromSSTable(file,
version));
fetcher = indexes.isEmpty()
? new SimpleBlockFetcher()
: new IndexedBlockFetcher(file.getFilePointer() + 4);
// We still have the column count to
[2/2] git commit: Merge remote-tracking branch 'apache/cassandra-1.2' into trunk
Merge remote-tracking branch 'apache/cassandra-1.2' into trunk
Conflicts:
src/java/org/apache/cassandra/db/columniterator/SimpleSliceReader.java
src/java/org/apache/cassandra/io/sstable/SSTableIdentityIterator.java
test/unit/org/apache/cassandra/db/ScrubTest.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae1f7be7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae1f7be7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae1f7be7
Branch: refs/heads/trunk
Commit: ae1f7be73422b72fe5a2dc2170a99c55c0bf5f0d
Parents: 313c79a 4f75875
Author: Jason Brown jasedbr...@gmail.com
Authored: Tue Apr 2 11:47:41 2013 -0700
Committer: Jason Brown jasedbr...@gmail.com
Committed: Tue Apr 2 11:47:41 2013 -0700
--
CHANGES.txt|1 +
.../org/apache/cassandra/db/RowIndexEntry.java |2 +-
.../db/columniterator/IndexedSliceReader.java | 10 +-
.../db/columniterator/SSTableNamesIterator.java|2 +-
.../db/columniterator/SimpleSliceReader.java |8 +-
.../apache/cassandra/io/sstable/IndexHelper.java | 23 +-
.../io/sstable/SSTableIdentityIterator.java|8 +-
test/unit/org/apache/cassandra/db/ScrubTest.java | 245 ---
8 files changed, 31 insertions(+), 268 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae1f7be7/CHANGES.txt
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae1f7be7/src/java/org/apache/cassandra/db/RowIndexEntry.java
--
diff --cc src/java/org/apache/cassandra/db/RowIndexEntry.java
index 6982a77,e9f08b2..2a8dcfe
--- a/src/java/org/apache/cassandra/db/RowIndexEntry.java
+++ b/src/java/org/apache/cassandra/db/RowIndexEntry.java
@@@ -86,23 -94,33 +86,23 @@@ public class RowIndexEntr
}
}
-public RowIndexEntry deserializePositionOnly(DataInput dis,
Descriptor.Version version) throws IOException
+public RowIndexEntry deserialize(DataInput in, Descriptor.Version
version) throws IOException
{
-long position = dis.readLong();
+long position = in.readLong();
if (version.hasPromotedIndexes)
{
-int size = dis.readInt();
-if (size 0)
-FileUtils.skipBytesFully(dis, size);
-}
-return new RowIndexEntry(position);
-}
-
-public RowIndexEntry deserialize(DataInput dis, Descriptor.Version
version) throws IOException
-{
-long position = dis.readLong();
-if (version.hasPromotedIndexes)
-{
-int size = dis.readInt();
+int size = in.readInt();
if (size 0)
{
-DeletionInfo delInfo =
DeletionInfo.serializer().deserializeFromSSTable(dis, version);
-int entries = dis.readInt();
+DeletionInfo delInfo =
DeletionInfo.serializer().deserializeFromSSTable(in, version);
+int entries = in.readInt();
ListIndexHelper.IndexInfo columnsIndex = new
ArrayListIndexHelper.IndexInfo(entries);
for (int i = 0; i entries; i++)
-
columnsIndex.add(IndexHelper.IndexInfo.deserialize(dis));
-IFilter bf = FilterFactory.deserialize(dis,
version.filterType, false);
-return new IndexedEntry(position, delInfo, columnsIndex,
bf);
+
columnsIndex.add(IndexHelper.IndexInfo.deserialize(in));
+
+if (version.hasRowLevelBF)
- IndexHelper.skipBloomFilter(in);
++IndexHelper.skipBloomFilter(in, version.filterType);
+return new IndexedEntry(position, delInfo, columnsIndex);
}
else
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae1f7be7/src/java/org/apache/cassandra/db/columniterator/IndexedSliceReader.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae1f7be7/src/java/org/apache/cassandra/db/columniterator/SSTableNamesIterator.java
--
diff --cc
src/java/org/apache/cassandra/db/columniterator/SSTableNamesIterator.java
index e7257bf,da4631d..633
--- a/src/java/org/apache/cassandra/db/columniterator/SSTableNamesIterator.java
+++ b/src/java/org/apache/cassandra/db/columniterator/SSTableNamesIterator.java
@@@
[jira] [Commented] (CASSANDRA-5385) IndexHelper.skipBloomFilters won't skip non-SHA filters
[ https://issues.apache.org/jira/browse/CASSANDRA-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620128#comment-13620128 ] Jason Brown commented on CASSANDRA-5385: There is a problem with ScrubTest, and we decided, on the IRC, to can it for now. It will be rewritten as part of #4180. Committed to cassandra-1.2 and trunk. Thanks, Carl! IndexHelper.skipBloomFilters won't skip non-SHA filters --- Key: CASSANDRA-5385 URL: https://issues.apache.org/jira/browse/CASSANDRA-5385 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0, 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 1.2.4, 2.0 Attachments: 5385.patch Currently, if the bloom filter is not of SHA type, we do not properly skip the bytes. We need to read out the number of bytes, as happens in the Murmur deserializer, then skip that many bytes instead of just skipping the hash size. The version needs to be passed into the method as well, so that it knows what type of index it is, and does the appropriate skipping. -- 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-5400) Allow multiple ports to gossip from a single IP address
[ https://issues.apache.org/jira/browse/CASSANDRA-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620131#comment-13620131 ] Brandon Williams commented on CASSANDRA-5400: - Trunk has moved along a bit quickly, can you rebase? Allow multiple ports to gossip from a single IP address --- Key: CASSANDRA-5400 URL: https://issues.apache.org/jira/browse/CASSANDRA-5400 Project: Cassandra Issue Type: New Feature Affects Versions: 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 2.0 Attachments: 5400.txt If a fat client is running on the same machine as a Cassandra node, the fat client must be allocated a new IP address. However, since the node is now a part of the gossip, the other nodes in the ring must be able to talk to it. This means that a local only address (127.0.0.n) won't actually work for the rest of the ring. This also would allow for multiple Cassandra service instances to run on a single machine, or from a group of machines behind a NAT. The change is simple in concept: instead of using an InetAddress, use a different class. Instead of using an InetSocketAddress, which would still tie us to using InetAddress, I've added a new class, CassandraInstanceEndpoint. The serializer allows for reading a serialized Inet4Address or Inet6Address; also, the message service can still communicate with non-CassandraInstanceEndpoint aware 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-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-5413:
-
Attachment: 5413.txt
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Bug
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Assignee: Aleksey Yeschenko
Priority: Minor
Labels: cql3, cqlsh
Fix For: 1.2.4
Attachments: 5413.txt, cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure on builder cassandra-trunk while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/2507 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch trunk] ae1f7be73422b72fe5a2dc2170a99c55c0bf5f0d Blamelist: Jason Brown jasedbr...@gmail.com BUILD FAILED: failed shell sincerely, -The Buildbot
[jira] [Updated] (CASSANDRA-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-5413:
-
Priority: Trivial (was: Minor)
Issue Type: Improvement (was: Bug)
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Improvement
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Assignee: Aleksey Yeschenko
Priority: Trivial
Labels: cql3, cqlsh
Fix For: 1.2.4
Attachments: 5413.txt, cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
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-5413) cqlsh returns map entries in wrong order
[
https://issues.apache.org/jira/browse/CASSANDRA-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620138#comment-13620138
]
Brandon Williams commented on CASSANDRA-5413:
-
+1
cqlsh returns map entries in wrong order
Key: CASSANDRA-5413
URL: https://issues.apache.org/jira/browse/CASSANDRA-5413
Project: Cassandra
Issue Type: Improvement
Components: API, Tools
Affects Versions: 1.2.3
Environment: Cassandra 1.2.3 on Ubuntu 12.04, Java(TM) SE Runtime
Environment (build 1.6.0_43-b01), running in VMWare player 5.0.0 build-812388
on Windows 7 Professional 32bit
Reporter: Swav Swiac
Assignee: Aleksey Yeschenko
Priority: Trivial
Labels: cql3, cqlsh
Fix For: 1.2.4
Attachments: 5413.txt, cqlsh map sort order.txt
The elements in the map timeuuid,decimal are returned in cqlsh in an order
that is neither sorted by name, value or timestamp.
Below is output from cqlsh and cassandra cli. (looks a bit messy here, I have
attached a text file without word wrapping)
cqlsh:iBidTest select * from lots ;
event_id | lot_id | bids_accepted | bids_details
| bids_temp
| minimum | number | title
--++---+--+--+-++---
a4a70900-24e1-11df-8924-001ff3591711 | 1 | null | null
|
null | 200 | 2 | New lot 2
a4a70900-24e1-11df-8924-001ff3591711 | 3 | null | null
| {8b457e90-9ae2-11e2-9bcb-a1f164a2d4a3: 1000,
9606ca50-9ae2-11e2-9bcb-a1f164a2d4a3: 650,
908fb640-9ae2-11e2-9bcb-a1f164a2d4a3: 600,
7d930650-9ae2-11e2-9bcb-a1f164a2d4a3: 500,
a1ef7f10-9ae2-11e2-9bcb-a1f164a2d4a3: 1250,
9aedd360-9ae2-11e2-9bcb-a1f164a2d4a3: 950} | 100 | 1 | New lot 1
[default@ibidtest] get lots[a4a70900-24e1-11df-8924-001ff3591711];
= (column=1:, value=, timestamp=1364829909818000)
= (column=1:minimum, value=00c8, timestamp=1364829397026000)
= (column=1:number, value=32, timestamp=1364829909818000)
= (column=1:title, value=4e6577206c6f742032, timestamp=1364829397026000)
= (column=3:, value=, timestamp=1364830894466000)
= (column=3:bids_temp:7d9306509ae211e29bcba1f164a2d4a3, value=01f4,
timestamp=1364830833463000)
= (column=3:bids_temp:8b457e909ae211e29bcba1f164a2d4a3, value=03e8,
timestamp=1364830856441000)
= (column=3:bids_temp:908fb6409ae211e29bcba1f164a2d4a3, value=0258,
timestamp=1364830865317000)
= (column=3:bids_temp:9606ca509ae211e29bcba1f164a2d4a3, value=028a,
timestamp=1364830874485000)
= (column=3:bids_temp:9aedd3609ae211e29bcba1f164a2d4a3, value=03b6,
timestamp=1364830882711000)
= (column=3:bids_temp:a1ef7f109ae211e29bcba1f164a2d4a3, value=04e2,
timestamp=1364830894466000)
= (column=3:minimum, value=64, timestamp=1364829412417000)
= (column=3:number, value=31, timestamp=136482985202)
= (column=3:title, value=4e6577206c6f742031, timestamp=1364829412417000)
Returned 14 results.
Elapsed time: 130 msec(s).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: cqlsh: Print maps ordered by key, sort sets
Updated Branches:
refs/heads/cassandra-1.2 4f75875c2 - 3f883bf4d
cqlsh: Print maps ordered by key, sort sets
patch by Aleksey Yeschenko; reviewed by Brandon Williams for
CASSANDRA-5413
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3f883bf4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3f883bf4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3f883bf4
Branch: refs/heads/cassandra-1.2
Commit: 3f883bf4d514cf8175d5d7bcbb6af16908905bdb
Parents: 4f75875
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Apr 2 22:08:59 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Apr 2 22:08:59 2013 +0300
--
CHANGES.txt |1 +
pylib/cqlshlib/formatting.py |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f883bf4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7e906ce..58ba39a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -18,6 +18,7 @@
* Fix writetime/ttl functions on null values (CASSANDRA-5341)
* Fix NPE during cql3 select with token() (CASSANDRA-5404)
* IndexHelper.skipBloomFilters won't skip non-SHA filters (CASSANDRA-5385)
+ * cqlsh: Print maps ordered by key, sort sets (CASSANDRA-5413)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f883bf4/pylib/cqlshlib/formatting.py
--
diff --git a/pylib/cqlshlib/formatting.py b/pylib/cqlshlib/formatting.py
index b970eb9..a3d4666 100644
--- a/pylib/cqlshlib/formatting.py
+++ b/pylib/cqlshlib/formatting.py
@@ -202,7 +202,7 @@ def format_value_list(val, encoding, colormap, time_format,
float_precision, sub
@formatter_for('set')
def format_value_set(val, encoding, colormap, time_format, float_precision,
subtypes, nullval, **_):
-return format_simple_collection(subtypes[0], val, '{', '}', encoding,
colormap,
+return format_simple_collection(subtypes[0], sorted(val), '{', '}',
encoding, colormap,
time_format, float_precision, nullval)
@formatter_for('map')
@@ -213,7 +213,7 @@ def format_value_map(val, encoding, colormap, time_format,
float_precision, subt
nullval=nullval)
subkeytype, subvaltype = subtypes
-subs = [(subformat(k, subkeytype), subformat(v, subvaltype)) for (k, v) in
val.items()]
+subs = [(subformat(k, subkeytype), subformat(v, subvaltype)) for (k, v) in
sorted(val.items())]
bval = '{' + ', '.join(k.strval + ': ' + v.strval for (k, v) in subs) + '}'
lb, comma, colon, rb = [colormap['collection'] + s + colormap['reset']
for s in ('{', ', ', ': ', '}')]
[1/2] git commit: cqlsh: Print maps ordered by key, sort sets
Updated Branches:
refs/heads/trunk ae1f7be73 - 493fccd18
cqlsh: Print maps ordered by key, sort sets
patch by Aleksey Yeschenko; reviewed by Brandon Williams for
CASSANDRA-5413
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3f883bf4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3f883bf4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3f883bf4
Branch: refs/heads/trunk
Commit: 3f883bf4d514cf8175d5d7bcbb6af16908905bdb
Parents: 4f75875
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Apr 2 22:08:59 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Apr 2 22:08:59 2013 +0300
--
CHANGES.txt |1 +
pylib/cqlshlib/formatting.py |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f883bf4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7e906ce..58ba39a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -18,6 +18,7 @@
* Fix writetime/ttl functions on null values (CASSANDRA-5341)
* Fix NPE during cql3 select with token() (CASSANDRA-5404)
* IndexHelper.skipBloomFilters won't skip non-SHA filters (CASSANDRA-5385)
+ * cqlsh: Print maps ordered by key, sort sets (CASSANDRA-5413)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f883bf4/pylib/cqlshlib/formatting.py
--
diff --git a/pylib/cqlshlib/formatting.py b/pylib/cqlshlib/formatting.py
index b970eb9..a3d4666 100644
--- a/pylib/cqlshlib/formatting.py
+++ b/pylib/cqlshlib/formatting.py
@@ -202,7 +202,7 @@ def format_value_list(val, encoding, colormap, time_format,
float_precision, sub
@formatter_for('set')
def format_value_set(val, encoding, colormap, time_format, float_precision,
subtypes, nullval, **_):
-return format_simple_collection(subtypes[0], val, '{', '}', encoding,
colormap,
+return format_simple_collection(subtypes[0], sorted(val), '{', '}',
encoding, colormap,
time_format, float_precision, nullval)
@formatter_for('map')
@@ -213,7 +213,7 @@ def format_value_map(val, encoding, colormap, time_format,
float_precision, subt
nullval=nullval)
subkeytype, subvaltype = subtypes
-subs = [(subformat(k, subkeytype), subformat(v, subvaltype)) for (k, v) in
val.items()]
+subs = [(subformat(k, subkeytype), subformat(v, subvaltype)) for (k, v) in
sorted(val.items())]
bval = '{' + ', '.join(k.strval + ': ' + v.strval for (k, v) in subs) + '}'
lb, comma, colon, rb = [colormap['collection'] + s + colormap['reset']
for s in ('{', ', ', ': ', '}')]
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/493fccd1 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/493fccd1 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/493fccd1 Branch: refs/heads/trunk Commit: 493fccd1879dd532aab00d254bb642ba0762c310 Parents: ae1f7be 3f883bf Author: Aleksey Yeschenko alek...@apache.org Authored: Tue Apr 2 22:10:46 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Tue Apr 2 22:10:46 2013 +0300 -- CHANGES.txt |1 + pylib/cqlshlib/formatting.py |4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/493fccd1/CHANGES.txt --
[jira] [Commented] (CASSANDRA-5293) formalize that timestamps are epoch-in-micros in 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620144#comment-13620144 ] Sean Bridges commented on CASSANDRA-5293: - This will break a lot of our code as we use non epoch-in-micro values as timestamps quite a bit. It is very handy for ensuring order when you have another monotonically increasing id available. As an example we compute meta data for versioned objects, and store the meta data in cassandra. The version id is a monotonically increasing long, and we write the meta data to cassandra with a timestamp of the version id. Due to retries, multiple machines may be processing the same object with different version ids, but since we always write to cassandra with a timestamp of the version id, the latest version id always wins. We have a couple other use cases, but having a user set timestamp that does not have to be an epoch-in-micros is very useful. If you want a real timestamp, perhaps it is better to add a new timestamp-micros field which is set by the co-ordinator, and not visible to thrift/cql. formalize that timestamps are epoch-in-micros in 2.0 Key: CASSANDRA-5293 URL: https://issues.apache.org/jira/browse/CASSANDRA-5293 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Fix For: 2.0 We've worked around don't assume timestamps are actually timestamps but the utility is not worth the complexity and lost opportunities to optimize this imposes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot success in ASF Buildbot on cassandra-1.1
The Buildbot has detected a restored build on builder cassandra-1.1 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/cassandra-1.1/builds/162 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: forced: by IRC user driftx on channel #cassandra-dev: lies Build Source Stamp: HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
[jira] [Created] (CASSANDRA-5419) Employ column differencing (as done for read repairs) during node repairs
Ahmed Bashir created CASSANDRA-5419: --- Summary: Employ column differencing (as done for read repairs) during node repairs Key: CASSANDRA-5419 URL: https://issues.apache.org/jira/browse/CASSANDRA-5419 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.10 Environment: Production Reporter: Ahmed Bashir In particular for wide rows, the headroom required for node repairs can be substantial given that entire rows are streamed for any and all row hash discrepancies. This headroom must be sustained until compaction slowly compacts these newly streamed SSTables and reduces the overall load on each instance. The overall footprint of node repairs would be greatly reduced if we employed differencing at the column level and sent over row mutations, similar to what is done during read repair. This is a great alternative for deployments wherein sending over entire rows rather than the deltas is not an option. Since node repairs can now specify start and end tokens (i.e. subrange repairs), the additional computation can be broken down easily, and it's a welcome trade-off for significantly less streaming, compaction, and temporary headroom requirements. -- 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-5419) Employ column differencing (as done for read repairs) during node repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620191#comment-13620191 ] Brandon Williams commented on CASSANDRA-5419: - I think this is doable, but it will definitely need to be on subranges only since we'll be dealing with quite a significant amount of bloat in the heap if we maintain merkle trees for each row, and probably require a flag to specify it since you really only want to do this on CFs with wide rows. That said, the good news is a 'lean' tree of 2**16 on the rows is plenty good enough, since a row with 10M columns would still only transfer 153 columns if one was damaged. Employ column differencing (as done for read repairs) during node repairs -- Key: CASSANDRA-5419 URL: https://issues.apache.org/jira/browse/CASSANDRA-5419 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.10 Environment: Production Reporter: Ahmed Bashir Labels: compaction, repair In particular for wide rows, the headroom required for node repairs can be substantial given that entire rows are streamed for any and all row hash discrepancies. This headroom must be sustained until compaction slowly compacts these newly streamed SSTables and reduces the overall load on each instance. The overall footprint of node repairs would be greatly reduced if we employed differencing at the column level and sent over row mutations, similar to what is done during read repair. This is a great alternative for deployments wherein sending over entire rows rather than the deltas is not an option. Since node repairs can now specify start and end tokens (i.e. subrange repairs), the additional computation can be broken down easily, and it's a welcome trade-off for significantly less streaming, compaction, and temporary headroom requirements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Add yaml network topology snitch for mixed ec2/other envs Patch by Eric Dong, reviewed by brandonwilliams for CASSANDRA-5339
Updated Branches: refs/heads/trunk 493fccd18 - 81cbdc531 Add yaml network topology snitch for mixed ec2/other envs Patch by Eric Dong, reviewed by brandonwilliams for CASSANDRA-5339 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/81cbdc53 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/81cbdc53 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/81cbdc53 Branch: refs/heads/trunk Commit: 81cbdc531265a6279c9584719a6d2f807bc9d2c4 Parents: 493fccd Author: Brandon Williams brandonwilli...@apache.org Authored: Tue Apr 2 14:55:47 2013 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Tue Apr 2 14:56:32 2013 -0500 -- CHANGES.txt|1 + conf/cassandra-topology.yaml | 25 + .../locator/YamlFileNetworkTopologySnitch.java | 568 +++ test/conf/cassandra-topology.yaml | 74 ++ .../locator/YamlFileNetworkTopologySnitchTest.java | 117 +++ 5 files changed, 785 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/81cbdc53/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 7c8d80a..060561f 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.0 + * Add yaml network topology snitch for mixed ec2/other envs (CASSANDRA-5339) * Log when a node is down longer than the hint window (CASSANDRA-4554) * Optimize tombstone creation for ExpiringColumns (CASSANDRA-4917) * Improve LeveledScanner work estimation (CASSANDRA-5250) http://git-wip-us.apache.org/repos/asf/cassandra/blob/81cbdc53/conf/cassandra-topology.yaml -- diff --git a/conf/cassandra-topology.yaml b/conf/cassandra-topology.yaml new file mode 100644 index 000..11c37d0 --- /dev/null +++ b/conf/cassandra-topology.yaml @@ -0,0 +1,25 @@ +# YAML topology configuration file for Cassandra, +# to be used with YamlFileNetworkTopologySnitch. + +# The topology, as a list of data centers. +topology: +# Each data center has a name and a list of racks. +- dc_name: DC1 + racks: + # Each rack has a name and a list of nodes. + - rack_name: c1 +nodes: +# Each node has a broadcast address (required) +# and a data-center-local address (optional). +# If dc_local_address is specified, its peers +# in the same data center will attempt to +# reconnect over that address instead. +- broadcast_address: 1.2.3.4 + dc_local_address: 5.6.7.8 + +# Default data center name for unknown nodes; defaults to UNKNOWN +# default_dc_name: UNKNOWN + +# Default rack name for unknown nodes +# default_rack_name: UNKNOWN; defaults to UNKNOWN + http://git-wip-us.apache.org/repos/asf/cassandra/blob/81cbdc53/src/java/org/apache/cassandra/locator/YamlFileNetworkTopologySnitch.java -- diff --git a/src/java/org/apache/cassandra/locator/YamlFileNetworkTopologySnitch.java b/src/java/org/apache/cassandra/locator/YamlFileNetworkTopologySnitch.java new file mode 100644 index 000..e1f1a95 --- /dev/null +++ b/src/java/org/apache/cassandra/locator/YamlFileNetworkTopologySnitch.java @@ -0,0 +1,568 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * License); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.cassandra.locator; + +import java.io.InputStream; +import java.net.InetAddress; +import java.util.Collections; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +import org.apache.cassandra.exceptions.ConfigurationException; +import org.apache.cassandra.gms.ApplicationState; +import org.apache.cassandra.gms.EndpointState; +import org.apache.cassandra.gms.Gossiper; +import org.apache.cassandra.gms.IEndpointStateChangeSubscriber; +import org.apache.cassandra.gms.VersionedValue; +import
[jira] [Assigned] (CASSANDRA-5339) YAML network topology snitch supporting preferred addresses
[ https://issues.apache.org/jira/browse/CASSANDRA-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-5339: --- Assignee: Eric Dong YAML network topology snitch supporting preferred addresses --- Key: CASSANDRA-5339 URL: https://issues.apache.org/jira/browse/CASSANDRA-5339 Project: Cassandra Issue Type: New Feature Reporter: Eric Dong Assignee: Eric Dong Priority: Minor Fix For: 2.0 Attachments: CASSANDRA-5339-1.patch In order to support having a Cassandra cluster spanning multiple data centers, some in Amazon EC2 and some not, I'm submitting a YAML network topology snitch that allows one to configure 'preferred addresses' such as a data-center-local address. The new snitch reconnects to the node via the preferred address using the same reconnection trick present in Ec2MultiRegionSnitch. I chose a new YAML format instead of trying to extend cassandra-topology.properties because it is easier to read and allows for future extensibility. Pull request to follow. -- 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-5339) YAML network topology snitch supporting preferred addresses
[ https://issues.apache.org/jira/browse/CASSANDRA-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620214#comment-13620214 ] Brandon Williams commented on CASSANDRA-5339: - Also added cassandra-topology.yaml to the debian package. YAML network topology snitch supporting preferred addresses --- Key: CASSANDRA-5339 URL: https://issues.apache.org/jira/browse/CASSANDRA-5339 Project: Cassandra Issue Type: New Feature Reporter: Eric Dong Assignee: Eric Dong Priority: Minor Fix For: 2.0 Attachments: CASSANDRA-5339-1.patch In order to support having a Cassandra cluster spanning multiple data centers, some in Amazon EC2 and some not, I'm submitting a YAML network topology snitch that allows one to configure 'preferred addresses' such as a data-center-local address. The new snitch reconnects to the node via the preferred address using the same reconnection trick present in Ec2MultiRegionSnitch. I chose a new YAML format instead of trying to extend cassandra-topology.properties because it is easier to read and allows for future extensibility. Pull request to follow. -- 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 DarrellHa by DarrellHa
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The DarrellHa page has been changed by DarrellHa: http://wiki.apache.org/cassandra/DarrellHa New page: Alvaro Corrado is what you can call me but it's not the most masculine name. Invoicing has been my profession temporarly. I am really fond of brewing beer at home and I'm trying to transform it into a profession.BR My house is now in Arizona and I don't plan on changing it.BR BR my web blog ... [[http://resveratrol-products.com/best-resveratrol-products.html|perfect resveratrol]]
[jira] [Commented] (CASSANDRA-5400) Allow multiple ports to gossip from a single IP address
[ https://issues.apache.org/jira/browse/CASSANDRA-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620218#comment-13620218 ] Jonathan Ellis commented on CASSANDRA-5400: --- Possibly easier: post a git branch so we can check out and not need to care what trunk does until commit time. Allow multiple ports to gossip from a single IP address --- Key: CASSANDRA-5400 URL: https://issues.apache.org/jira/browse/CASSANDRA-5400 Project: Cassandra Issue Type: New Feature Affects Versions: 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 2.0 Attachments: 5400.txt If a fat client is running on the same machine as a Cassandra node, the fat client must be allocated a new IP address. However, since the node is now a part of the gossip, the other nodes in the ring must be able to talk to it. This means that a local only address (127.0.0.n) won't actually work for the rest of the ring. This also would allow for multiple Cassandra service instances to run on a single machine, or from a group of machines behind a NAT. The change is simple in concept: instead of using an InetAddress, use a different class. Instead of using an InetSocketAddress, which would still tie us to using InetAddress, I've added a new class, CassandraInstanceEndpoint. The serializer allows for reading a serialized Inet4Address or Inet6Address; also, the message service can still communicate with non-CassandraInstanceEndpoint aware 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] [Commented] (CASSANDRA-5400) Allow multiple ports to gossip from a single IP address
[ https://issues.apache.org/jira/browse/CASSANDRA-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620234#comment-13620234 ] Carl Yeksigian commented on CASSANDRA-5400: --- The branch is at: https://github.com/carlyeks/cassandra/tree/cie Allow multiple ports to gossip from a single IP address --- Key: CASSANDRA-5400 URL: https://issues.apache.org/jira/browse/CASSANDRA-5400 Project: Cassandra Issue Type: New Feature Affects Versions: 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 2.0 Attachments: 5400.txt If a fat client is running on the same machine as a Cassandra node, the fat client must be allocated a new IP address. However, since the node is now a part of the gossip, the other nodes in the ring must be able to talk to it. This means that a local only address (127.0.0.n) won't actually work for the rest of the ring. This also would allow for multiple Cassandra service instances to run on a single machine, or from a group of machines behind a NAT. The change is simple in concept: instead of using an InetAddress, use a different class. Instead of using an InetSocketAddress, which would still tie us to using InetAddress, I've added a new class, CassandraInstanceEndpoint. The serializer allows for reading a serialized Inet4Address or Inet6Address; also, the message service can still communicate with non-CassandraInstanceEndpoint aware 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] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620253#comment-13620253 ] Jonathan Ellis commented on CASSANDRA-5062: --- bq. One option could be to ensure that a quorum of node has learned before starting a new round Right. But I don't think keeping the last commit value fixes this for the general case, since a replica can miss arbitrarily many updates while the other two nodes are the quorum. We could hint the commit, but that doesn't help since the next CAS request could go to a different coordinator. So I think we'd have to hint to one of the other replicas, and have the replica include whether it has un-replayed hints for its peers in the promise (and disqualify the target from the quorum until it does get replayed). But that still leaves a window for all the replicas to become unavailable to the coordinator between (partial) learn, and hint generation. We could use a batchlog-like approach, where each peer generates a hint precursor that it will turn into an actual hint if it doesn't get the all-clear from the coordinator in time. (I think we might even be able to use the actual batchlog code here.) Performance might even be acceptable, judging from the batchlog precedent... This is definitely messy though. Better ideas? Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5400) Allow multiple ports to gossip from a single IP address
[ https://issues.apache.org/jira/browse/CASSANDRA-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620255#comment-13620255 ] Brandon Williams commented on CASSANDRA-5400: - Ok, can you merge trunk into that? :) Allow multiple ports to gossip from a single IP address --- Key: CASSANDRA-5400 URL: https://issues.apache.org/jira/browse/CASSANDRA-5400 Project: Cassandra Issue Type: New Feature Affects Versions: 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 2.0 Attachments: 5400.txt If a fat client is running on the same machine as a Cassandra node, the fat client must be allocated a new IP address. However, since the node is now a part of the gossip, the other nodes in the ring must be able to talk to it. This means that a local only address (127.0.0.n) won't actually work for the rest of the ring. This also would allow for multiple Cassandra service instances to run on a single machine, or from a group of machines behind a NAT. The change is simple in concept: instead of using an InetAddress, use a different class. Instead of using an InetSocketAddress, which would still tie us to using InetAddress, I've added a new class, CassandraInstanceEndpoint. The serializer allows for reading a serialized Inet4Address or Inet6Address; also, the message service can still communicate with non-CassandraInstanceEndpoint aware 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-5385) IndexHelper.skipBloomFilters won't skip non-SHA filters
[ https://issues.apache.org/jira/browse/CASSANDRA-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian resolved CASSANDRA-5385. --- Resolution: Fixed IndexHelper.skipBloomFilters won't skip non-SHA filters --- Key: CASSANDRA-5385 URL: https://issues.apache.org/jira/browse/CASSANDRA-5385 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0, 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 1.2.4, 2.0 Attachments: 5385.patch Currently, if the bloom filter is not of SHA type, we do not properly skip the bytes. We need to read out the number of bytes, as happens in the Murmur deserializer, then skip that many bytes instead of just skipping the hash size. The version needs to be passed into the method as well, so that it knows what type of index it is, and does the appropriate skipping. -- 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-5400) Allow multiple ports to gossip from a single IP address
[ https://issues.apache.org/jira/browse/CASSANDRA-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620260#comment-13620260 ] Jonathan Ellis commented on CASSANDRA-5400: --- Sorry, I didn't realize Brandon was ready to commit. Guess you do want to rebase on trunk. Allow multiple ports to gossip from a single IP address --- Key: CASSANDRA-5400 URL: https://issues.apache.org/jira/browse/CASSANDRA-5400 Project: Cassandra Issue Type: New Feature Affects Versions: 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 2.0 Attachments: 5400.txt If a fat client is running on the same machine as a Cassandra node, the fat client must be allocated a new IP address. However, since the node is now a part of the gossip, the other nodes in the ring must be able to talk to it. This means that a local only address (127.0.0.n) won't actually work for the rest of the ring. This also would allow for multiple Cassandra service instances to run on a single machine, or from a group of machines behind a NAT. The change is simple in concept: instead of using an InetAddress, use a different class. Instead of using an InetSocketAddress, which would still tie us to using InetAddress, I've added a new class, CassandraInstanceEndpoint. The serializer allows for reading a serialized Inet4Address or Inet6Address; also, the message service can still communicate with non-CassandraInstanceEndpoint aware 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] [Commented] (CASSANDRA-5397) Updates to PerRowSecondaryIndex don't use most current values
[ https://issues.apache.org/jira/browse/CASSANDRA-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620266#comment-13620266 ] Jonathan Ellis commented on CASSANDRA-5397: --- What guard are you talking about? Have things changed since CASSANDRA-4458 was opened? Updates to PerRowSecondaryIndex don't use most current values -- Key: CASSANDRA-5397 URL: https://issues.apache.org/jira/browse/CASSANDRA-5397 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Minor Attachments: 5397.txt The way that updates to secondary indexes are performed using SecondaryIndexManager.Updater is flawed for PerRowSecondaryIndexes. Unlike PerColumnSecondaryIndexes, which only require the old new values for a single column, the expectation is that a PerRow indexer can be given just a key which it will use to retrieve the entire row (or as many columns as it requires) and perform its indexing on those columns. As the indexes are updated before the memtable atomic swap occurs, a per-row indexer may only read the previous values for the row, not the new ones that are being written. In the case of an insert, there is no previous value and so nothing is added to the index. -- 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] [Issue Comment Deleted] (CASSANDRA-5397) Updates to PerRowSecondaryIndex don't use most current values
[ https://issues.apache.org/jira/browse/CASSANDRA-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5397: -- Comment: was deleted (was: What guard are you talking about? Have things changed since CASSANDRA-4458 was opened?) Updates to PerRowSecondaryIndex don't use most current values -- Key: CASSANDRA-5397 URL: https://issues.apache.org/jira/browse/CASSANDRA-5397 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Minor Attachments: 5397.txt The way that updates to secondary indexes are performed using SecondaryIndexManager.Updater is flawed for PerRowSecondaryIndexes. Unlike PerColumnSecondaryIndexes, which only require the old new values for a single column, the expectation is that a PerRow indexer can be given just a key which it will use to retrieve the entire row (or as many columns as it requires) and perform its indexing on those columns. As the indexes are updated before the memtable atomic swap occurs, a per-row indexer may only read the previous values for the row, not the new ones that are being written. In the case of an insert, there is no previous value and so nothing is added to the index. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620269#comment-13620269 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. But I don't think keeping the last commit value fixes this for the general case What I had in mind was that on result of the prepare, we would wait for a quorum of people agreeing on the last MRC (i.e. a quorum has learn the last value) before allowing to proceed with our own value. Provided we always ensure that, then we can ensure that for every column in a CAS, then in any quorum at least one node has seen the last update for that column. However, if we don't do anything more, we may not be able to make progress, because if for a quorum of 2, the answer we get from a prepare is say MRC=t2 from node A and some very old state from node B, then we can't proceed because we don't have a quorum agreeing on t2 MRC, but we can't make progress either because we don't know how to bring B to MRC=t2. But if A had sent the most-recent-committed value corresponding to t2, then we could repair B (making it learn basically) and then start again the algorithm (we can even optimize a bit by sending the repair in the same message than the new prepare). Note that B might have missed more than the last commit, but as long as we make sure a QUORUM learn the value of every round before proposing, we're good. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-5419) Employ column differencing (as done for read repairs) during node repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-5419. --- Resolution: Duplicate Detecting diffs smaller than a row is actually the hard part. (See link.) Employ column differencing (as done for read repairs) during node repairs -- Key: CASSANDRA-5419 URL: https://issues.apache.org/jira/browse/CASSANDRA-5419 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.10 Environment: Production Reporter: Ahmed Bashir Labels: compaction, repair In particular for wide rows, the headroom required for node repairs can be substantial given that entire rows are streamed for any and all row hash discrepancies. This headroom must be sustained until compaction slowly compacts these newly streamed SSTables and reduces the overall load on each instance. The overall footprint of node repairs would be greatly reduced if we employed differencing at the column level and sent over row mutations, similar to what is done during read repair. This is a great alternative for deployments wherein sending over entire rows rather than the deltas is not an option. Since node repairs can now specify start and end tokens (i.e. subrange repairs), the additional computation can be broken down easily, and it's a welcome trade-off for significantly less streaming, compaction, and temporary headroom requirements. -- 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] [Issue Comment Deleted] (CASSANDRA-5419) Employ column differencing (as done for read repairs) during node repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5419: -- Comment: was deleted (was: Detecting diffs smaller than a row is actually the hard part. (See link.)) Employ column differencing (as done for read repairs) during node repairs -- Key: CASSANDRA-5419 URL: https://issues.apache.org/jira/browse/CASSANDRA-5419 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.10 Environment: Production Reporter: Ahmed Bashir Labels: compaction, repair In particular for wide rows, the headroom required for node repairs can be substantial given that entire rows are streamed for any and all row hash discrepancies. This headroom must be sustained until compaction slowly compacts these newly streamed SSTables and reduces the overall load on each instance. The overall footprint of node repairs would be greatly reduced if we employed differencing at the column level and sent over row mutations, similar to what is done during read repair. This is a great alternative for deployments wherein sending over entire rows rather than the deltas is not an option. Since node repairs can now specify start and end tokens (i.e. subrange repairs), the additional computation can be broken down easily, and it's a welcome trade-off for significantly less streaming, compaction, and temporary headroom requirements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620273#comment-13620273 ] Jonathan Ellis commented on CASSANDRA-5062: --- Oh. Yeah, that's a lot simpler. :) Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5400) Allow multiple ports to gossip from a single IP address
[ https://issues.apache.org/jira/browse/CASSANDRA-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-5400: Reviewer: brandon.williams Allow multiple ports to gossip from a single IP address --- Key: CASSANDRA-5400 URL: https://issues.apache.org/jira/browse/CASSANDRA-5400 Project: Cassandra Issue Type: New Feature Affects Versions: 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 2.0 Attachments: 5400.txt If a fat client is running on the same machine as a Cassandra node, the fat client must be allocated a new IP address. However, since the node is now a part of the gossip, the other nodes in the ring must be able to talk to it. This means that a local only address (127.0.0.n) won't actually work for the rest of the ring. This also would allow for multiple Cassandra service instances to run on a single machine, or from a group of machines behind a NAT. The change is simple in concept: instead of using an InetAddress, use a different class. Instead of using an InetSocketAddress, which would still tie us to using InetAddress, I've added a new class, CassandraInstanceEndpoint. The serializer allows for reading a serialized Inet4Address or Inet6Address; also, the message service can still communicate with non-CassandraInstanceEndpoint aware 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-5400) Allow multiple ports to gossip from a single IP address
[ https://issues.apache.org/jira/browse/CASSANDRA-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-5400: -- Attachment: 5400-v2.txt Applied against trunk. Most updates were in the YamlNetworkDescriptor; LegacySSTablesTest is failing, but it is in trunk as well. Allow multiple ports to gossip from a single IP address --- Key: CASSANDRA-5400 URL: https://issues.apache.org/jira/browse/CASSANDRA-5400 Project: Cassandra Issue Type: New Feature Affects Versions: 2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Fix For: 2.0 Attachments: 5400.txt, 5400-v2.txt If a fat client is running on the same machine as a Cassandra node, the fat client must be allocated a new IP address. However, since the node is now a part of the gossip, the other nodes in the ring must be able to talk to it. This means that a local only address (127.0.0.n) won't actually work for the rest of the ring. This also would allow for multiple Cassandra service instances to run on a single machine, or from a group of machines behind a NAT. The change is simple in concept: instead of using an InetAddress, use a different class. Instead of using an InetSocketAddress, which would still tie us to using InetAddress, I've added a new class, CassandraInstanceEndpoint. The serializer allows for reading a serialized Inet4Address or Inet6Address; also, the message service can still communicate with non-CassandraInstanceEndpoint aware 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
