[jira] [Commented] (CASSANDRA-3729) support counter debug mode on thrift interface
[ https://issues.apache.org/jira/browse/CASSANDRA-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184796#comment-13184796 ] Sylvain Lebresne commented on CASSANDRA-3729: - I think the thrift interface is too user visible for something like this. Maybe a JMX method (in some debug MBean) would be less of a problem. That being said, it's not really something we can ask people to turn on to help troubleshooting a problem they would have with counters as it would break counter reads. Logging contexts at debug in the log (which we more or less do, though maybe we can improve it a bit) seems more useful for that. And if it's really just for the 4 of us developers working on counters, we can recompile the code with 1 line commented to get the same behavior if we so wish. So not sure I feel it's worth taking the chance that someone hit that trigger in production by accident. support counter debug mode on thrift interface -- Key: CASSANDRA-3729 URL: https://issues.apache.org/jira/browse/CASSANDRA-3729 Project: Cassandra Issue Type: Improvement Reporter: Peter Schuller Assignee: Peter Schuller Priority: Minor Attachments: trunk-3729.txt Attaching a patch against trunk to add a counter debug mode on the thrift interface, allowing clients to decode and inspect counter contexts. This is all Stu's code, except that I generated the thrift stuff so any mistakes there are mine. This was extremely useful internally on an 0.8. The patch is not yet tested on trunk, but if you think this can go in I will spend effort to test it soonish. It's not very invasive (other than the generated thrift code), so it feels okay to have it if we maybe document that it is not a supported interface (clearly in the thrift spec). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184804#comment-13184804 ] Shotaro Kamio commented on CASSANDRA-1123: -- Thrift request timeout should be interesting as well. Because a user gets time-out exception, but server doesn't have any log about that. In our production cluster, we added logging where timedout exception is thrown. It logs warning message with the query itself for later investigation. Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Aaron Morton Fix For: 1.2 Attachments: 1123-3.patch.gz In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Have isIndexBuilt expunge all tombstones
Updated Branches: refs/heads/cassandra-1.0 1e7501381 - c1f125b9b Have isIndexBuilt expunge all tombstones Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c1f125b9 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c1f125b9 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c1f125b9 Branch: refs/heads/cassandra-1.0 Commit: c1f125b9b61a1aafb65c0466a43ceddbf9e8e9f9 Parents: 1e75013 Author: Sylvain Lebresne sylv...@datastax.com Authored: Thu Jan 12 09:11:25 2012 +0100 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Thu Jan 12 09:11:25 2012 +0100 -- src/java/org/apache/cassandra/db/SystemTable.java |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1f125b9/src/java/org/apache/cassandra/db/SystemTable.java -- diff --git a/src/java/org/apache/cassandra/db/SystemTable.java b/src/java/org/apache/cassandra/db/SystemTable.java index 19e9f15..8f1adfc 100644 --- a/src/java/org/apache/cassandra/db/SystemTable.java +++ b/src/java/org/apache/cassandra/db/SystemTable.java @@ -382,7 +382,7 @@ public class SystemTable QueryFilter filter = QueryFilter.getNamesFilter(decorate(ByteBufferUtil.bytes(table)), new QueryPath(INDEX_CF), ByteBufferUtil.bytes(indexName)); -return cfs.getColumnFamily(filter) != null; +return ColumnFamilyStore.removeDeleted(cfs.getColumnFamily(filter), Integer.MAX_VALUE) != null; } public static void setIndexBuilt(String table, String indexName)
Git Push Summary
Updated Tags: refs/tags/1.0.7-tentative [created] c1f125b9b
[jira] [Commented] (CASSANDRA-3729) support counter debug mode on thrift interface
[ https://issues.apache.org/jira/browse/CASSANDRA-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184820#comment-13184820 ] Peter Schuller commented on CASSANDRA-3729: --- Just to be clear, it's a per-client setting whether or not the counters are returned un-encoded or not. So one of the nice features is that you can take a running Cassandra instance (e.g. in production) and connect your client to it, enable debug mode *for your connection*, and inspect. Before this I was doing sstable2json to filter out the key I wanted so I could iterate quickly, and then continuously rebuilding Cassandra with increasing amounts of debug loggings enabled. Doable, but it was very nice to have this ;) A JMX setting sounds like it would be global. The reason to put it at the thrift level to begin with is that it's per-connection. How about this: Suppose we create a developer-only service that extends the public service? Everything built using the public interface would not even be aware additional calls exist. Hmm. Or just have a separate thrift service with debug/dev-only calls, with e.g., a get_counter_context() or something like that. I dunno. I understand the reluctance to dirty the public interface, yet this was so very useful. support counter debug mode on thrift interface -- Key: CASSANDRA-3729 URL: https://issues.apache.org/jira/browse/CASSANDRA-3729 Project: Cassandra Issue Type: Improvement Reporter: Peter Schuller Assignee: Peter Schuller Priority: Minor Attachments: trunk-3729.txt Attaching a patch against trunk to add a counter debug mode on the thrift interface, allowing clients to decode and inspect counter contexts. This is all Stu's code, except that I generated the thrift stuff so any mistakes there are mine. This was extremely useful internally on an 0.8. The patch is not yet tested on trunk, but if you think this can go in I will spend effort to test it soonish. It's not very invasive (other than the generated thrift code), so it feels okay to have it if we maybe document that it is not a supported interface (clearly in the thrift spec). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3729) support counter debug mode on thrift interface
[ https://issues.apache.org/jira/browse/CASSANDRA-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184831#comment-13184831 ] Sylvain Lebresne commented on CASSANDRA-3729: - bq. Just to be clear, it's a per-client setting I missed that, sorry. It does is better than a JMX setting then. bq. Suppose we create a developer-only service that extends the public service? I suppose some form of debug console (which could take the form of a separate thrift service + some debug shell to connect to it) wouldn't be a crazy idea if it's clearly separated from the public API. Feels like a bit of work for just getting counter contexts, but maybe we can find other uses for it (for instance, we could disable access to the system keyspace from the public API, but enable it from the debug console). support counter debug mode on thrift interface -- Key: CASSANDRA-3729 URL: https://issues.apache.org/jira/browse/CASSANDRA-3729 Project: Cassandra Issue Type: Improvement Reporter: Peter Schuller Assignee: Peter Schuller Priority: Minor Attachments: trunk-3729.txt Attaching a patch against trunk to add a counter debug mode on the thrift interface, allowing clients to decode and inspect counter contexts. This is all Stu's code, except that I generated the thrift stuff so any mistakes there are mine. This was extremely useful internally on an 0.8. The patch is not yet tested on trunk, but if you think this can go in I will spend effort to test it soonish. It's not very invasive (other than the generated thrift code), so it feels okay to have it if we maybe document that it is not a supported interface (clearly in the thrift spec). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184839#comment-13184839 ] Sylvain Lebresne commented on CASSANDRA-3634: - If we are trading some (one time) additional work on the driver's author to support prepared statement against a potential 10%, I'd be in favor of the binary approach (given that prepared statement are an optimization for performance in the first place, and without saying that we shouldn't care about making driver's author life as easy as possible). Now I'd mention that I think the binary approach is actually more problematic for custom comparators, because drivers will need to expose a way for the user to either say how to pack their strings, or to directly provide pre-serialized binary. Which then put a little more burden on the user (of course the user knows of to serialize the strings for his custom comparator since he write the comparator, but this means a duplication of code for him, possibly in multiple languages, which is no fun). compare string vs. binary prepared statement parameters --- Key: CASSANDRA-3634 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.1 Perform benchmarks to compare the performance of string and pre-serialized binary parameters to prepared statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3727) Fix unit tests failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-3727.
-
Resolution: Fixed
I still had intermittent failure of columnFamilyStoreTest, but because
SystemTable.isIndexBuilt() was suffering from the same 'I forgot to expunge
tombstones' problem than SystemTable.loadTokens(). I took on myself to commit
the same fix for that instance directly (and check no other method had this
problem).
So closing this as all tests are now passing.
However I'd be interested to know if anyone else is seeing the 'unable to
create link' stack trace during tests, because if so we should probably open
another ticket to investigate.
Fix unit tests failure
--
Key: CASSANDRA-3727
URL: https://issues.apache.org/jira/browse/CASSANDRA-3727
Project: Cassandra
Issue Type: Bug
Components: Tests
Affects Versions: 1.0.7
Reporter: Sylvain Lebresne
Priority: Blocker
Fix For: 1.0.7
Attachments: 3727.txt, CASSANDRA-3727-CliTest-timeout-fix.patch
On current 1.0 branch (and on my machine: Linux), I have the following unit
test failures:
* CliTest and EmbeddedCassandraTest: they both first kind of pass (JUnit
first prints a message with no failures in it), then hang until JUnit timeout
and fails with a 'Timeout occurred'. In other word, the tests themselves are
passing, but something they do prevents the process to exit cleanly leading
to a JUnit timeout. I don't want to discard that as not a problem, because if
something can make the process not exit cleanly, this can be a pain for
restarts (and in particular upgrades) and hence would be basically a
regression. I'm marking the ticket as blocker (for the release of 1.0.7)
mostly because of this one.
* SystemTableTest: throws an assertionError. I haven't checked yet, so that
could be an easy one to fix.
* RemoveTest: it fails, saying that '/127.0.0.1:7010 is in use by another
process' (consistently). But I have no other process running on port 7010.
It's likely just of problem of the test, but it's new and in the meantime
removes are not tested.
* I also see a bunch of stack trace with errors like:
{noformat}
[junit] ERROR 10:01:59,007 Fatal exception in thread
Thread[NonPeriodicTasks:1,5,main]
[junit] java.lang.RuntimeException: java.io.IOException: Unable to create
hard link from build/test/cassandra/data/Keyspace1/Indexed1-hc-1-Index.db to
/home/mcmanus/Git/cassandra/build/test/cassandra/data/Keyspace1/backups/Indexed1-hc-1-Index.db
(errno 17)
{noformat}
(with SSTableReaderTest). This does not make the tests fail, but it is still
worth investigating. It may be due to CASSANDRA-3101.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Git Push Summary
Updated Tags: refs/tags/1.0.7-tentative [deleted] c1f125b9b
git commit: Fix mistake in NEWS file
Updated Branches: refs/heads/cassandra-1.0 c1f125b9b - d7e40a1cd Fix mistake in NEWS file Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d7e40a1c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d7e40a1c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d7e40a1c Branch: refs/heads/cassandra-1.0 Commit: d7e40a1cdd3394ea5f5178e1b01ff693a0f173c2 Parents: c1f125b Author: Sylvain Lebresne sylv...@datastax.com Authored: Thu Jan 12 10:30:25 2012 +0100 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Thu Jan 12 10:30:25 2012 +0100 -- NEWS.txt | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/d7e40a1c/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 2356faa..2c29606 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -15,6 +15,13 @@ Upgrading - - Nothing specific to 1.0.7, please report to instruction for 1.0.6 +Other +- +- Adds new setstreamthroughput to nodetool to configure streaming + throttling +- Adds JMX property to get/set rpc_timeout_in_ms at runtime +- Allow configuring (per-CF) bloom_filter_fp_chance + 1.0.6 = @@ -29,13 +36,6 @@ Upgrading setting the right value and then run scrub on the column family. - Please report to instruction for 1.0.5 if coming from an older version. -Other -- -- Adds new setstreamthroughput to nodetool to configure streaming - throttling -- Adds JMX property to get/set rpc_timeout_in_ms at runtime -- Allow configuring (per-CF) bloom_filter_fp_chance - 1.0.5 =
Git Push Summary
Updated Tags: refs/tags/1.0.7-tentative [created] d7e40a1cd
[jira] [Created] (CASSANDRA-3730) If some streaming sessions fail on decommission, decommission hangs
If some streaming sessions fail on decommission, decommission hangs --- Key: CASSANDRA-3730 URL: https://issues.apache.org/jira/browse/CASSANDRA-3730 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1 Environment: FreeBSD Reporter: Vitalii Tymchyshyn Currently cassandra do not handle StreamOutSession fails, e.g.: // Instead of just not calling the callback on failure, we could have // allow to register a specific callback for failures, but we leave // that to a future ticket (likely CASSANDRA-3112) if (callback != null success) callback.run(); This means that if during decommission a node that receives decommission data fails or (my case) the node that tries to decommission becomes overloaded, the streaming session fails and decommission don't know anything about this. This makes it hard to decommission overloaded nodes because I need to restart the node to restart decommission. Also I can see next errors because of streaming files try to get streaming session that is closed by gossip: ERROR [Streaming to /10.112.0.216:1] 2012-01-11 15:57:28,882 AbstractCassandraDaemon.java (line 138) Fatal exception in thread Thread[Streaming to /10.112.0.216:1,5,main] java.lang.NullPointerException at org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:97) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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:679) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3731) bad data size in compactionstats
bad data size in compactionstats Key: CASSANDRA-3731 URL: https://issues.apache.org/jira/browse/CASSANDRA-3731 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.6 Environment: debian, oracle java 1.6.26 LeveledCompaction with 4096M (file size limit is 4096MB) count of sstables 500 Reporter: Zenek Kraweznik pending tasks: -2147483648 compaction type keyspace column family bytes compacted bytes total progress Compaction Archive Messages 35050352366 *0* n/a 0 bytes total is visible on this node (nodetool ring is reporting 37.18GB). After every compactions bytes total is about 73x (i guess it is not compress data size), but this value isn't saved anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3732) Update POM generation after migration to git
Update POM generation after migration to git Key: CASSANDRA-3732 URL: https://issues.apache.org/jira/browse/CASSANDRA-3732 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Sylvain Lebresne Assignee: Stephen Connolly Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185043#comment-13185043 ] Jonathan Ellis commented on CASSANDRA-1123: --- The CassandraServer class logs timeouts at DEBUG level (see CASSANDRA-3661). But I agree this would be a useful event to record. Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Aaron Morton Fix For: 1.2 Attachments: 1123-3.patch.gz In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185045#comment-13185045 ] Jonathan Ellis commented on CASSANDRA-3634: --- bq. this means a duplication of code for him, possibly in multiple languages, which is no fun True, but that's the case for a String-based api as well as a binary one. compare string vs. binary prepared statement parameters --- Key: CASSANDRA-3634 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.1 Perform benchmarks to compare the performance of string and pre-serialized binary parameters to prepared statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Priority: Minor
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
{noformat}
Introducing by CASSANDRA-3554. The problem is that until a compaction on hints
occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185055#comment-13185055
]
Jonathan Ellis commented on CASSANDRA-3733:
---
Why doesn't this take care of it?
{code}
. if (rowsReplayed 0)
{
hintStore.forceFlush();
try
{
CompactionManager.instance.submitMaximal(hintStore,
Integer.MAX_VALUE).get();
}
catch (Exception e)
{
throw new RuntimeException(e);
}
}
{code}
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Priority: Minor
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3733:
Description:
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on hints
occurs, tombstones are present causing the isEmpty() check to be false.
was:
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
{noformat}
Introducing by CASSANDRA-3554. The problem is that until a compaction on hints
occurs, tombstones are present causing the isEmpty() check to be false.
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Priority: Minor
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3668) Performance of sstableloader is affected in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-3668: -- Attachment: 3688-reply_before_closing_writer.txt So far I found one place that can improve throughput. Right now, node that receive streaming replies finished after finalizing sstable, but that takes some time (few hundred msec / per data file), so sender has to wait that amount of time before transferring next file. Attached patch modifies this behavior so that node can send reply as soon as receiving whole data file and sender can proceed immediately to send next file. Manish, could you try this patch and see how it improves? It can be applied on cassandra 1.0.6 as well as the latest cassandra-1.0 branch. I'm still investigating other improvements especially buffering. If I find anything, I will post them here. Performance of sstableloader is affected in 1.0.x - Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.0.7 Reporter: Manish Zope Assignee: Yuki Morishita Fix For: 1.0.8 Attachments: 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3668) Performance of sstableloader is affected in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185061#comment-13185061 ] Jonathan Ellis commented on CASSANDRA-3668: --- bq. Attached patch modifies this behavior so that node can send reply as soon as receiving whole data file Doesn't this mean that if the target restarts after acking the stream, but before finishing the 2ary index builds, that data will never be indexed but we'll have no indication it didn't happen? If this is the bottleneck I'd rather add a concurrency option to the bulk loader as a workaround. Performance of sstableloader is affected in 1.0.x - Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.0.7 Reporter: Manish Zope Assignee: Yuki Morishita Fix For: 1.0.8 Attachments: 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3733:
Attachment: 3733.txt
Patch to make flushes blocking.
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Priority: Minor
Attachments: 3733.txt
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185063#comment-13185063
]
Jonathan Ellis commented on CASSANDRA-3733:
---
+1
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Priority: Minor
Attachments: 3733.txt
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Block on flush before submitting compaction for hints. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3733
Updated Branches:
refs/heads/cassandra-1.0 d7e40a1cd - cafeeebd1
Block on flush before submitting compaction for hints.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3733
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cafeeebd
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cafeeebd
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cafeeebd
Branch: refs/heads/cassandra-1.0
Commit: cafeeebd17b208e12313bea9da0972e6f4c5cdf8
Parents: d7e40a1
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Jan 12 10:54:22 2012 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Jan 12 10:54:22 2012 -0600
--
.../apache/cassandra/db/HintedHandOffManager.java |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/cafeeebd/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
index 0b92821..a83fbab 100644
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
@@ -179,7 +179,7 @@ public class HintedHandOffManager implements
HintedHandOffManagerMBean
{
logger_.info(Deleting any stored hints for + endpoint);
rm.apply();
-hintStore.forceFlush();
+hintStore.forceBlockingFlush();
CompactionManager.instance.submitMaximal(hintStore,
Integer.MAX_VALUE);
}
catch (Exception e)
@@ -359,9 +359,9 @@ public class HintedHandOffManager implements
HintedHandOffManagerMBean
if (rowsReplayed 0)
{
-hintStore.forceFlush();
try
{
+hintStore.forceBlockingFlush();
CompactionManager.instance.submitMaximal(hintStore,
Integer.MAX_VALUE).get();
}
catch (Exception e)
[jira] [Resolved] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3733.
-
Resolution: Fixed
Committed.
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Minor
Fix For: 1.0.8
Attachments: 3733.txt
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185065#comment-13185065
]
Jonathan Ellis commented on CASSANDRA-3733:
---
the tombstone buffering on the next attempt could cause OOMs similar to
CASSANDRA-3681, as well.
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Priority: Minor
Fix For: 1.0.8
Attachments: 3733.txt
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3668) Performance of sstableloader is affected in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185069#comment-13185069 ] Sylvain Lebresne commented on CASSANDRA-3668: - Isn't CASSANDRA-3494 that concurrency option? Performance of sstableloader is affected in 1.0.x - Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.0.7 Reporter: Manish Zope Assignee: Yuki Morishita Fix For: 1.0.8 Attachments: 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[4/4] git commit: Have isIndexBuilt expunge all tombstones
Have isIndexBuilt expunge all tombstones Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c1f125b9 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c1f125b9 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c1f125b9 Branch: refs/heads/trunk Commit: c1f125b9b61a1aafb65c0466a43ceddbf9e8e9f9 Parents: 1e75013 Author: Sylvain Lebresne sylv...@datastax.com Authored: Thu Jan 12 09:11:25 2012 +0100 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Thu Jan 12 09:11:25 2012 +0100 -- src/java/org/apache/cassandra/db/SystemTable.java |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1f125b9/src/java/org/apache/cassandra/db/SystemTable.java -- diff --git a/src/java/org/apache/cassandra/db/SystemTable.java b/src/java/org/apache/cassandra/db/SystemTable.java index 19e9f15..8f1adfc 100644 --- a/src/java/org/apache/cassandra/db/SystemTable.java +++ b/src/java/org/apache/cassandra/db/SystemTable.java @@ -382,7 +382,7 @@ public class SystemTable QueryFilter filter = QueryFilter.getNamesFilter(decorate(ByteBufferUtil.bytes(table)), new QueryPath(INDEX_CF), ByteBufferUtil.bytes(indexName)); -return cfs.getColumnFamily(filter) != null; +return ColumnFamilyStore.removeDeleted(cfs.getColumnFamily(filter), Integer.MAX_VALUE) != null; } public static void setIndexBuilt(String table, String indexName)
[1/4] git commit: Merge branch 'cassandra-1.0' into trunk
Updated Branches: refs/heads/trunk b3a378c02 - cfd9399dc Merge branch 'cassandra-1.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cfd9399d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cfd9399d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cfd9399d Branch: refs/heads/trunk Commit: cfd9399dce96127c868b35fcc91dcd8514165b41 Parents: b3a378c cafeeeb Author: Brandon Williams brandonwilli...@apache.org Authored: Thu Jan 12 10:58:34 2012 -0600 Committer: Brandon Williams brandonwilli...@apache.org Committed: Thu Jan 12 10:58:34 2012 -0600 -- NEWS.txt | 14 +++--- .../apache/cassandra/db/HintedHandOffManager.java |4 ++-- src/java/org/apache/cassandra/db/SystemTable.java |2 +- 3 files changed, 10 insertions(+), 10 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cfd9399d/NEWS.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cfd9399d/src/java/org/apache/cassandra/db/HintedHandOffManager.java --
[3/4] git commit: Fix mistake in NEWS file
Fix mistake in NEWS file Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d7e40a1c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d7e40a1c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d7e40a1c Branch: refs/heads/trunk Commit: d7e40a1cdd3394ea5f5178e1b01ff693a0f173c2 Parents: c1f125b Author: Sylvain Lebresne sylv...@datastax.com Authored: Thu Jan 12 10:30:25 2012 +0100 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Thu Jan 12 10:30:25 2012 +0100 -- NEWS.txt | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/d7e40a1c/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index 2356faa..2c29606 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -15,6 +15,13 @@ Upgrading - - Nothing specific to 1.0.7, please report to instruction for 1.0.6 +Other +- +- Adds new setstreamthroughput to nodetool to configure streaming + throttling +- Adds JMX property to get/set rpc_timeout_in_ms at runtime +- Allow configuring (per-CF) bloom_filter_fp_chance + 1.0.6 = @@ -29,13 +36,6 @@ Upgrading setting the right value and then run scrub on the column family. - Please report to instruction for 1.0.5 if coming from an older version. -Other -- -- Adds new setstreamthroughput to nodetool to configure streaming - throttling -- Adds JMX property to get/set rpc_timeout_in_ms at runtime -- Allow configuring (per-CF) bloom_filter_fp_chance - 1.0.5 =
[2/4] git commit: Block on flush before submitting compaction for hints. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3733
Block on flush before submitting compaction for hints.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3733
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cafeeebd
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cafeeebd
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cafeeebd
Branch: refs/heads/trunk
Commit: cafeeebd17b208e12313bea9da0972e6f4c5cdf8
Parents: d7e40a1
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Jan 12 10:54:22 2012 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Jan 12 10:54:22 2012 -0600
--
.../apache/cassandra/db/HintedHandOffManager.java |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/cafeeebd/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
index 0b92821..a83fbab 100644
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
@@ -179,7 +179,7 @@ public class HintedHandOffManager implements
HintedHandOffManagerMBean
{
logger_.info(Deleting any stored hints for + endpoint);
rm.apply();
-hintStore.forceFlush();
+hintStore.forceBlockingFlush();
CompactionManager.instance.submitMaximal(hintStore,
Integer.MAX_VALUE);
}
catch (Exception e)
@@ -359,9 +359,9 @@ public class HintedHandOffManager implements
HintedHandOffManagerMBean
if (rowsReplayed 0)
{
-hintStore.forceFlush();
try
{
+hintStore.forceBlockingFlush();
CompactionManager.instance.submitMaximal(hintStore,
Integer.MAX_VALUE).get();
}
catch (Exception e)
[jira] [Commented] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185070#comment-13185070
]
Jonathan Ellis commented on CASSANDRA-3733:
---
Can you commit to 0.8 too?
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Minor
Fix For: 1.0.8
Attachments: 3733.txt
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185071#comment-13185071 ] Sylvain Lebresne commented on CASSANDRA-3634: - bq. that's the case for a String-based api as well as a binary one. For String-based, the translation from String-binary would happen server side, where we do have the custom comparator and thus the fromString() method (which have to be written from the comparator anyway). With binary, you would have to write the comparator.fromString(), but also have the same client side. compare string vs. binary prepared statement parameters --- Key: CASSANDRA-3634 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.1 Perform benchmarks to compare the performance of string and pre-serialized binary parameters to prepared statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3668) Performance of sstableloader is affected in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185072#comment-13185072 ] Jonathan Ellis commented on CASSANDRA-3668: --- I don't think so, since that just adds thread-per-target, not multiple-threads-to-single-target. Performance of sstableloader is affected in 1.0.x - Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.0.7 Reporter: Manish Zope Assignee: Yuki Morishita Fix For: 1.0.8 Attachments: 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3733:
--
Affects Version/s: (was: 1.0.7)
0.6
Fix Version/s: (was: 1.0.8)
1.0.7
0.8.10
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.6
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Minor
Fix For: 0.8.10, 1.0.7
Attachments: 3733.txt
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185071#comment-13185071 ] Sylvain Lebresne edited comment on CASSANDRA-3634 at 1/12/12 5:13 PM: -- bq. that's the case for a String-based api as well as a binary one. For String-based, the translation from String-binary would happen server side, where we do have the custom comparator and thus the fromString() method (which have to be written from the comparator anyway). With binary, you would have to write the comparator.fromString(), but also have the same client side. Of course, that is if the client has its customely-comparable prepared statement parameters in a string form to begin with. On the other side, taking binary would likely make it much more easier to take binary data (like pictures), without forcing a binary-string client-side followed by a string-binary decoding server side. Which is probably a bigger deal than the custom comparator thingy now that I think of that. So (and unless I don't understand anything on this issue and what's above is completely false), I'm clearly in favor of binary. was (Author: slebresne): bq. that's the case for a String-based api as well as a binary one. For String-based, the translation from String-binary would happen server side, where we do have the custom comparator and thus the fromString() method (which have to be written from the comparator anyway). With binary, you would have to write the comparator.fromString(), but also have the same client side. compare string vs. binary prepared statement parameters --- Key: CASSANDRA-3634 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.1 Perform benchmarks to compare the performance of string and pre-serialized binary parameters to prepared statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Block on flush before submitting compaction for hints. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3733
Updated Branches:
refs/heads/cassandra-0.8 70a350e6e - aacbb1ca9
Block on flush before submitting compaction for hints.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3733
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/aacbb1ca
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/aacbb1ca
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/aacbb1ca
Branch: refs/heads/cassandra-0.8
Commit: aacbb1ca9c0e7a1992dfc92c096dd885ab149154
Parents: 70a350e
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Jan 12 10:54:22 2012 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Jan 12 11:08:50 2012 -0600
--
.../apache/cassandra/db/HintedHandOffManager.java |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/aacbb1ca/src/java/org/apache/cassandra/db/HintedHandOffManager.java
--
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
index 1f9c7d2..f038aed 100644
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
@@ -225,7 +225,7 @@ public class HintedHandOffManager implements
HintedHandOffManagerMBean
{
logger_.info(Deleting any stored hints for + ipaddr);
rm.apply();
-hintStore.forceFlush();
+hintStore.forceBlockingFlush();
CompactionManager.instance.submitMajor(hintStore, 0,
Integer.MAX_VALUE);
}
catch (Exception e)
@@ -365,9 +365,9 @@ public class HintedHandOffManager implements
HintedHandOffManagerMBean
if (rowsReplayed 0)
{
-hintStore.forceFlush();
try
{
+hintStore.forceBlockingFlush();
CompactionManager.instance.submitMajor(hintStore, 0,
Integer.MAX_VALUE).get();
}
catch (Exception e)
[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185078#comment-13185078 ] Jonathan Ellis commented on CASSANDRA-3634: --- That's not what I meant. Suppose I have a custom geohash type. In a String-based PS world, I need to provide a geohash.toString method for each client driver. In a binary-based PS world, I need to provide a geohash.toByteBuffer method. So either way you're going to have to write custom code per client driver. compare string vs. binary prepared statement parameters --- Key: CASSANDRA-3634 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.1 Perform benchmarks to compare the performance of string and pre-serialized binary parameters to prepared statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
[
https://issues.apache.org/jira/browse/CASSANDRA-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185080#comment-13185080
]
Brandon Williams commented on CASSANDRA-3733:
-
Done in aacbb1ca9c0e7a1992dfc92c096dd885ab149154
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.6
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Minor
Fix For: 0.8.10, 1.0.7
Attachments: 3733.txt
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint
/10.179.111.137
{noformat}
Introduced by CASSANDRA-3554. The problem is that until a compaction on
hints occurs, tombstones are present causing the isEmpty() check to be false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185078#comment-13185078 ] Jonathan Ellis edited comment on CASSANDRA-3634 at 1/12/12 5:18 PM: That's not what I meant. Suppose I have a custom geohash type. In a String-based PS world, I need to provide a geohash.toString method for each client driver. In a binary-based PS world, I need to provide a geohash.toByteBuffer method. So either way you're going to have to write custom code per client driver. Update: this comment was obsoleted before I posted it by concurrent editing. :) was (Author: jbellis): That's not what I meant. Suppose I have a custom geohash type. In a String-based PS world, I need to provide a geohash.toString method for each client driver. In a binary-based PS world, I need to provide a geohash.toByteBuffer method. So either way you're going to have to write custom code per client driver. compare string vs. binary prepared statement parameters --- Key: CASSANDRA-3634 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.1 Perform benchmarks to compare the performance of string and pre-serialized binary parameters to prepared statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185078#comment-13185078 ] Jonathan Ellis edited comment on CASSANDRA-3634 at 1/12/12 5:18 PM: That's not what I meant. Suppose I have a custom geohash type. In a String-based PS world, I need to provide a geohash.toString method for each client driver. In a binary-based PS world, I need to provide a geohash.toByteBuffer method. So either way you're going to have to write custom code per client driver. Update: this comment was obsoleted before I posted it by concurrent editing. It sounds like we are in violent agreement. was (Author: jbellis): That's not what I meant. Suppose I have a custom geohash type. In a String-based PS world, I need to provide a geohash.toString method for each client driver. In a binary-based PS world, I need to provide a geohash.toByteBuffer method. So either way you're going to have to write custom code per client driver. Update: this comment was obsoleted before I posted it by concurrent editing. :) compare string vs. binary prepared statement parameters --- Key: CASSANDRA-3634 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.1 Perform benchmarks to compare the performance of string and pre-serialized binary parameters to prepared statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: update changes for 3733
Updated Branches: refs/heads/cassandra-1.0 cafeeebd1 - 3509f3d35 update changes for 3733 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3509f3d3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3509f3d3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3509f3d3 Branch: refs/heads/cassandra-1.0 Commit: 3509f3d35d10c3e8dd7a1bdd6d3a13307462c96d Parents: cafeeeb Author: Brandon Williams brandonwilli...@apache.org Authored: Thu Jan 12 11:22:23 2012 -0600 Committer: Brandon Williams brandonwilli...@apache.org Committed: Thu Jan 12 11:22:23 2012 -0600 -- CHANGES.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3509f3d3/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c0f2c66..39211a4 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -37,6 +37,7 @@ Merged from 0.8: when a key alias is involved (CASSANDRA-3700) * fix CLI `show schema` command insert of an extra comma in column_metadata (CASSANDRA-3714) + * block on flush before compacting hints (may prevent OOM) (CASSANDRA-3733) 1.0.6
git commit: update changes for 3733
Updated Branches: refs/heads/cassandra-0.8 aacbb1ca9 - 9ecaa2a5c update changes for 3733 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9ecaa2a5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9ecaa2a5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9ecaa2a5 Branch: refs/heads/cassandra-0.8 Commit: 9ecaa2a5c0549c1da1ebca0869f1c00fe1cad9e8 Parents: aacbb1c Author: Brandon Williams brandonwilli...@apache.org Authored: Thu Jan 12 11:23:05 2012 -0600 Committer: Brandon Williams brandonwilli...@apache.org Committed: Thu Jan 12 11:23:05 2012 -0600 -- CHANGES.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ecaa2a5/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 42218a7..64b2747 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -2,6 +2,7 @@ * prevent new nodes from thinking down nodes are up forever (CASSANDRA-3626) * use correct list of replicas for LOCAL_QUORUM reads when read repair is disabled (CASSANDRA-3696) + * block on flush before compacting hints (may prevent OOM) (CASSANDRA-3733) 0.8.9
[jira] [Commented] (CASSANDRA-3668) Performance of sstableloader is affected in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185087#comment-13185087 ] Sylvain Lebresne commented on CASSANDRA-3668: - You're right. Probably wouldn't be too hard to allow the per-targer executor to use more than one thread (and modify streaming accordingly to it's able to give to each thread a different file). And that would be streaming generic actually, so all the better for bootstrap and such. Performance of sstableloader is affected in 1.0.x - Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.0.7 Reporter: Manish Zope Assignee: Yuki Morishita Fix For: 1.0.8 Attachments: 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3281) Add an AbstractType anytype which stores meta data on a per column basis
[ https://issues.apache.org/jira/browse/CASSANDRA-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185092#comment-13185092 ] Sylvain Lebresne commented on CASSANDRA-3281: - If we added support for null values in DynamicCompositeType (which I think wouldn't be too hard), with CASSANDRA-3657 (which is not perfect I understand but would allow to add new DCT aliases on-demand) and with CASSANDRA-3625, would there be still a lot of missing things? Add an AbstractType anytype which stores meta data on a per column basis Key: CASSANDRA-3281 URL: https://issues.apache.org/jira/browse/CASSANDRA-3281 Project: Cassandra Issue Type: New Feature Reporter: Edward Capriolo Priority: Minor A pet project of mine is an AbstractType for Cassandra that stores metadata of the type in the column. https://github.com/edwardcapriolo/Cassandra-AnyType I described my use case any my design decisions here. https://github.com/edwardcapriolo/Cassandra-AnyType/blob/master/README . The biggest cases were needing to support null and '' as keys, column names, and column values, however I also think the technique used to serialize Java Objects as JSON but compare as a Java object is novel. Side node: (The AbstractType interface has changed multiple times between 0.6.X, 0.7.X, and 1.0.0-beta. I hope it stabilizes! ) If people would like AnyType (or parts of it ) incorporated into Cassandra that would be great. I am willing to tweak change it based on other peoples ideas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3703) log Compaction Active tasks in StatusLogger instead of n/a
[
https://issues.apache.org/jira/browse/CASSANDRA-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185106#comment-13185106
]
Jonathan Ellis commented on CASSANDRA-3703:
---
validationexecutor extends compactionexecutor and inherits the behavior we
want. (note that CE.compactions is static for just this reason.)
log Compaction Active tasks in StatusLogger instead of n/a
--
Key: CASSANDRA-3703
URL: https://issues.apache.org/jira/browse/CASSANDRA-3703
Project: Cassandra
Issue Type: Improvement
Reporter: Jackson Chung
Assignee: Jonathan Ellis
Priority: Minor
Labels: compaction
Fix For: 1.0.8
Attachments: 3703.txt
currently StatusLogger log:
{noformat}
logger.info(String.format(%-25s%10s%10s,
CompactionManager, n/a,
CompactionManager.instance.getPendingTasks()));
{noformat}
It'd be great if it could actually log the number of active tasks being
processed. Without looking into the code, I thought there was no compaction
running when reading the log.
{code: title=CompactionManager.java}
public int getActiveCompactions()
{
return CompactionExecutor.compactions.size();
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3722) Send Hints to Dynamic Snitch when Compaction or repair is going on for a node.
[ https://issues.apache.org/jira/browse/CASSANDRA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185125#comment-13185125 ] Jonathan Ellis commented on CASSANDRA-3722: --- you could base it on latency instead of pending count... Send Hints to Dynamic Snitch when Compaction or repair is going on for a node. -- Key: CASSANDRA-3722 URL: https://issues.apache.org/jira/browse/CASSANDRA-3722 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Reporter: Vijay Assignee: Vijay Priority: Minor Currently Dynamic snitch looks at the latency for figuring out which node will be better serving the requests, this works great but there is a part of the traffic sent to collect this data... There is also a window when Snitch doesn't know about some major event which are going to happen on the node (Node which is going to receive the data request). It would be great if we can send some sort hints to the Snitch so they can score based on known events causing higher latencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3722) Send Hints to Dynamic Snitch when Compaction or repair is going on for a node.
[ https://issues.apache.org/jira/browse/CASSANDRA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185131#comment-13185131 ] Brandon Williams commented on CASSANDRA-3722: - bq. you could base it on latency instead of pending count... I'm not sure I understand, do you mean the latency the pending reads would have if they came back at the time of calculating the scores? I was thinking about doing that since we have the timestamps in EM. Send Hints to Dynamic Snitch when Compaction or repair is going on for a node. -- Key: CASSANDRA-3722 URL: https://issues.apache.org/jira/browse/CASSANDRA-3722 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Reporter: Vijay Assignee: Vijay Priority: Minor Currently Dynamic snitch looks at the latency for figuring out which node will be better serving the requests, this works great but there is a part of the traffic sent to collect this data... There is also a window when Snitch doesn't know about some major event which are going to happen on the node (Node which is going to receive the data request). It would be great if we can send some sort hints to the Snitch so they can score based on known events causing higher latencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3722) Send Hints to Dynamic Snitch when Compaction or repair is going on for a node.
[ https://issues.apache.org/jira/browse/CASSANDRA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185138#comment-13185138 ] Vijay commented on CASSANDRA-3722: -- Probably after CASSANDRA-3723 we might be able to include the wait time in the queue, but the problem with that is that until we send the traffic actual traffic to the suspected node we will not know it, we should actually send occasional requests to those nodes to get this data (Not sure how we can throttle to be fewer requests)... Something like Test/Real messages to see if they are back to normal SLA's (which does a complete end to end read from the disk), if we dont want to publish major events. Send Hints to Dynamic Snitch when Compaction or repair is going on for a node. -- Key: CASSANDRA-3722 URL: https://issues.apache.org/jira/browse/CASSANDRA-3722 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Reporter: Vijay Assignee: Vijay Priority: Minor Currently Dynamic snitch looks at the latency for figuring out which node will be better serving the requests, this works great but there is a part of the traffic sent to collect this data... There is also a window when Snitch doesn't know about some major event which are going to happen on the node (Node which is going to receive the data request). It would be great if we can send some sort hints to the Snitch so they can score based on known events causing higher latencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185152#comment-13185152
]
Sylvain Lebresne commented on CASSANDRA-2474:
-
The patch is coming along rather well I think, but I still have a few details
to fix/clean up.
The patch does involve a number of language changes (which I strongly believe
are for the best), and the introduction of a native way to deal with wide rows
have a bunch of consequences. So let me list a number of those changes and see
on which you disagree, so we discuss that sooner than later:
* The '..' notation for slices is removed. It just doesn't work with the new
way to handle wide rows (and composites).
* I've made static definitions (i.e, those definitions that don't use COMPACT
STORAGE basically) really static. That is, inserting a column that is not
defined is not accepted, and there is no way to do something that translate as
a column slice on a static CF. The reason is twofold: I think this is good for
the user to have the validation that it doesn't make a basic typo when
inserting a column (thus inserting the wrong column). But also, I believe that
it makes the language much more coherent.
* Column definitions for static (and sparse) CF are all UTF8 strings (as
discussed above).
* I'm going to make all column definition case insensitive, unless they are
enclosed in single or double quotes (I've heard it's how PostgreSQL does it
more or less). If you have a better idea ...
* My current patch don't really allow creating a secondary index on a non
static CF, because it's not clear how that would work from the syntax and I'm
sure I see good use for that. Does that bother someone ? :)
* Currently, prepared statement allows you to write {{SELECT ? FROM users WHERE
? 3}}. I.e, you can have marker in place of a column definition (I call
'column definition' a name defined in the CREATE TABLE basically). I think it
could make sense to disallow that. The rational being that this patch make
select more complicated, it has more work to do to validate the query is
correct and to generate the query itself. If we were to disallow markers in
place of column definition, a fair amount of that preprocessing could be done
during the preparation phase in theory, which would be faster and allow to
return a number of errors more quickly. Besides, column definition are small
string, so allowing marker for them doesn't seem to be any real win.
Now, I do have a problem I'm not sure how to deal with: I'm not sure how to
deal with the limit for slices. The problem is that a slice on a wide row will
now return a number of CqlRow, not one with many columns. So it sound like we
should use the LIMIT. However, when you do say {{SELECT * FROM CF;}} (of if you
query multiple keys with IN), then it's unclear what you do with the LIMIT. I
unfortunately don't have a good solution for that yet.
I'm also not sure have the REVERSED just after the SELECT is still the right
choice after this patch.
I'll also note that this patch (with the things above) make it so that in the
CqlMetadata (in the result), the name_types are not useful anymore (since this
is always UTF8), and neither is the default comparator and default validation
types, as we can always set the type of each columns in the value_types map. I
suppose the best way to proceed is to mark them deprecated for now and remove
them in the next version.
In any case, I'm attaching the dtest file I'm using to test this patch
(cql_test.py) because I think it's a great way to see what this patch is about.
Lastly, because of the scale of the changes this patch does, I don't think it
is a good candidate to hide the change behind a runtime flag. It would be
messy and I think would make it less clear that both
* previous behavior is unchanged without the flag turned on
* new behavior works as expected when the flag is on
CQL support for compound columns and wide rows
--
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
Labels: cql
Fix For: 1.1
Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,
cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
If you think it
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2474: Attachment: cql_tests.py CQL support for compound columns and wide rows -- Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Critical Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185200#comment-13185200 ] paul cannon commented on CASSANDRA-2474: bq. I'll also note that this patch (with the things above) make it so that in the CqlMetadata (in the result), the name_types are not useful anymore (since this is always UTF8), and neither is the default comparator and default validation types, as we can always set the type of each columns in the value_types map. I suppose the best way to proceed is to mark them deprecated for now and remove them in the next version. This seems possibly too far. Clients ought to be able to know what a CF's default comparator and validation types are, even if they're not necessary to deserialize column values. Also, cqlsh has an ASSUME facility similar to the cli one. You can tell cqlsh to deserialize columns without an explicit column type as though they were something different. Would this still be possible without being able to tell whether column values had an explicit column_metadata type, or whether they were using the default? CQL support for compound columns and wide rows -- Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Critical Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3722) Send Hints to Dynamic Snitch when Compaction or repair is going on for a node.
[ https://issues.apache.org/jira/browse/CASSANDRA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185217#comment-13185217 ] Jonathan Ellis commented on CASSANDRA-3722: --- bq. the problem with that is that until we send the traffic actual traffic to the suspected node we will not know it Right, so I'm saying instead of gossiping an indirect indicator like compaction status, we could gossip read latency directly. Send Hints to Dynamic Snitch when Compaction or repair is going on for a node. -- Key: CASSANDRA-3722 URL: https://issues.apache.org/jira/browse/CASSANDRA-3722 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Reporter: Vijay Assignee: Vijay Priority: Minor Currently Dynamic snitch looks at the latency for figuring out which node will be better serving the requests, this works great but there is a part of the traffic sent to collect this data... There is also a window when Snitch doesn't know about some major event which are going to happen on the node (Node which is going to receive the data request). It would be great if we can send some sort hints to the Snitch so they can score based on known events causing higher latencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185225#comment-13185225 ] Sylvain Lebresne commented on CASSANDRA-2474: - bq. Clients ought to be able to know what a CF's default comparator and validation types are, even if they're not necessary to deserialize column values. I think one of the goal is to not necessarily stick to C* internal notion, as supported by the fact that specifying the comparator and default_validator during creates will be removed. Basically, why should we expose internal detail that are useless (which I'm claiming they are after this patch) for the client? bq. Would this still be possible without being able to tell whether column values had an explicit column_metadata type, or whether they were using the default? I don't see any problem to having an ASSUME facility with what I'm proposing. Maybe it will be more clear with the patch, but I really thing that after the patch those info adds really no value to the resultSet. CQL support for compound columns and wide rows -- Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Critical Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185228#comment-13185228 ] T Jake Luciani edited comment on CASSANDRA-2474 at 1/12/12 8:51 PM: bq. My current patch don't really allow creating a secondary index on a non static CF, because it's not clear how that would work from the syntax and I'm sure I see good use for that. Does that bother someone ? CASSANDRA-3680 will add support for this at a later time was (Author: tjake): .bq My current patch don't really allow creating a secondary index on a non static CF, because it's not clear how that would work from the syntax and I'm sure I see good use for that. Does that bother someone ? CASSANDRA-3680 will add support for this at a later time CQL support for compound columns and wide rows -- Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Critical Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185228#comment-13185228 ] T Jake Luciani commented on CASSANDRA-2474: --- .bq My current patch don't really allow creating a secondary index on a non static CF, because it's not clear how that would work from the syntax and I'm sure I see good use for that. Does that bother someone ? CASSANDRA-3680 will add support for this at a later time CQL support for compound columns and wide rows -- Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Critical Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185250#comment-13185250 ] Jonathan Ellis commented on CASSANDRA-2474: --- (BTW, why test this with dtest instead of just single node mode?) CQL support for compound columns and wide rows -- Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Critical Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185249#comment-13185249 ] Jonathan Ellis commented on CASSANDRA-2474: --- bq. The '..' notation for slices is removed Personally I'd rather support both for one release to make the transition easier, but with neither super nor composite support I doubt many people are using the current .., so if doing both adds a lot of complexity I'm okay with this. bq. I've made static definitions (i.e, those definitions that don't use COMPACT STORAGE basically) really static. I'm a little uneasy about this, but the only use cases I've been able to come up with make more sense as a COMPACT STORAGE wide row. So it's probably a good change. bq. Currently, prepared statement allows you to write SELECT ? FROM users WHERE ? 3. I.e, you can have marker in place of a column definition (I call 'column definition' a name defined in the CREATE TABLE basically). I think it could make sense to disallow that. +1 bq. However, when you do say SELECT * FROM CF; (of if you query multiple keys with IN), then it's unclear what you do with the LIMIT I don't think it's unclear at all, but maybe that's because of my SQL background. :) Granted, it doesn't make a great deal of sense to use IN + LIMIT, but if someone does, the LIMIT should take precedence. bq. I'm also not sure have the REVERSED just after the SELECT is still the right choice after this patch. What if we allowed ORDER BY DESC instead? (This is not quite valid SQL, which requires ORDER BY expr [ASC|DESC], but it's close.) CQL support for compound columns and wide rows -- Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Critical Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3101) Should check for errors when calling /bin/ln
[ https://issues.apache.org/jira/browse/CASSANDRA-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185296#comment-13185296 ] Jonathan Ellis commented on CASSANDRA-3101: --- bq. cmd /c mklink /H seems a much more clunky way to make a hard link, and I think the logic is backwards: fsutil hardlink create is supported in all Windows versions since Windows Server 2000, except XP mklink does not require admin privileges, so that's the preferred method, but it was introduced in Vista. fsutil is present on XP+ so we use it as a fallback: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil.mspx?mfr=true Should check for errors when calling /bin/ln Key: CASSANDRA-3101 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.4 Reporter: paul cannon Assignee: Vijay Priority: Minor Labels: lhf Fix For: 1.0.7 Attachments: 0001-0001-throw-IOE-while-calling-bin-ln-v2.patch, 0001-3101-throw-IOE-while-calling-bin-ln-v3.patch, 0001-3101-throw-IOE-while-calling-bin-ln.patch It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not check for any errors in the execution of the hard-link-making utility. This could be bad if, for example, the user has put the snapshot directory on a different filesystem from the data directory. The hard linking would fail and the sstable snapshots would not exist, but no error would be reported. It does look like errors with the more direct JNA link() call are handled correctly- an exception is thrown. The WithExec version should probably do the same thing. Definitely it would be enough to check the process exit value from /bin/ln for nonzero in the *nix case, but I don't know whether 'fsutil hardlink create' or 'cmd /c mklink /H' return nonzero on failure. For bonus points, use any output from the Process's error stream in the text of the exception, to aid in debugging problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185301#comment-13185301
]
paul cannon commented on CASSANDRA-2474:
bq. I don't see any problem to having an ASSUME facility with what I'm
proposing. Maybe it will be more clear with the patch, but I really thing that
after the patch those info adds really no value to the resultSet.
Example:
{noformat}
CREATE COLUMNFAMILY columnfam (keyname uuid PRIMARY KEY, username utf8) WITH
default_validation = blob;
ASSUME columnfam VALUES ARE float;
{noformat}
In this situation, cqlsh should deserialize 'keyname' values as uuid, and
'username' values as utf8, but any other column values should be deserialized
as float. cqlsh currently makes the distinction by seeing whether the type for
a value is given in the CqlMetadata.value_types field. It sounds like your
proposal involves sending a type for every column in the result; am I
misinterpreting that?
I guess cqlsh could query the columnfamily options itself whenever it needed to
determine the default_validation, but that seems like it kind of makes
CqlMetadata useless.
CQL support for compound columns and wide rows
--
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
Labels: cql
Fix For: 1.1
Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,
cql_tests.py, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3101) Should check for errors when calling /bin/ln
[ https://issues.apache.org/jira/browse/CASSANDRA-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185304#comment-13185304 ] paul cannon commented on CASSANDRA-3101: aha, thanks for clarification. Should check for errors when calling /bin/ln Key: CASSANDRA-3101 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.4 Reporter: paul cannon Assignee: Vijay Priority: Minor Labels: lhf Fix For: 1.0.7 Attachments: 0001-0001-throw-IOE-while-calling-bin-ln-v2.patch, 0001-3101-throw-IOE-while-calling-bin-ln-v3.patch, 0001-3101-throw-IOE-while-calling-bin-ln.patch It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not check for any errors in the execution of the hard-link-making utility. This could be bad if, for example, the user has put the snapshot directory on a different filesystem from the data directory. The hard linking would fail and the sstable snapshots would not exist, but no error would be reported. It does look like errors with the more direct JNA link() call are handled correctly- an exception is thrown. The WithExec version should probably do the same thing. Definitely it would be enough to check the process exit value from /bin/ln for nonzero in the *nix case, but I don't know whether 'fsutil hardlink create' or 'cmd /c mklink /H' return nonzero on failure. For bonus points, use any output from the Process's error stream in the text of the exception, to aid in debugging problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3722) Send Hints to Dynamic Snitch when Compaction or repair is going on for a node.
[ https://issues.apache.org/jira/browse/CASSANDRA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185316#comment-13185316 ] Vijay commented on CASSANDRA-3722: -- will do. Send Hints to Dynamic Snitch when Compaction or repair is going on for a node. -- Key: CASSANDRA-3722 URL: https://issues.apache.org/jira/browse/CASSANDRA-3722 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Reporter: Vijay Assignee: Vijay Priority: Minor Currently Dynamic snitch looks at the latency for figuring out which node will be better serving the requests, this works great but there is a part of the traffic sent to collect this data... There is also a window when Snitch doesn't know about some major event which are going to happen on the node (Node which is going to receive the data request). It would be great if we can send some sort hints to the Snitch so they can score based on known events causing higher latencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3722) Send Hints to Dynamic Snitch when Compaction or repair is going on for a node.
[ https://issues.apache.org/jira/browse/CASSANDRA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185319#comment-13185319 ] Brandon Williams commented on CASSANDRA-3722: - bq. Right, so I'm saying instead of gossiping an indirect indicator like compaction status, we could gossip read latency directly. I'm not sure that's a good solution either due to the propagation time. Especially in the case that the repair is staggered across the replica set, there's a good chance you're penalizing the wrong host after the first one until the state is propagated to you. Send Hints to Dynamic Snitch when Compaction or repair is going on for a node. -- Key: CASSANDRA-3722 URL: https://issues.apache.org/jira/browse/CASSANDRA-3722 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Reporter: Vijay Assignee: Vijay Priority: Minor Currently Dynamic snitch looks at the latency for figuring out which node will be better serving the requests, this works great but there is a part of the traffic sent to collect this data... There is also a window when Snitch doesn't know about some major event which are going to happen on the node (Node which is going to receive the data request). It would be great if we can send some sort hints to the Snitch so they can score based on known events causing higher latencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3734) Support native link w/o JNA in Java7
Support native link w/o JNA in Java7 Key: CASSANDRA-3734 URL: https://issues.apache.org/jira/browse/CASSANDRA-3734 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 1.2 Java7 provides native support for hard links: http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#createLink(java.nio.file.Path, java.nio.file.Path) We should prefer this method when Java7 is the host. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3710) Add a configuration option to disable snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185326#comment-13185326 ] Jonathan Ellis commented on CASSANDRA-3710: --- Another option would be to use Java7: CASSANDRA-3734 Add a configuration option to disable snapshots --- Key: CASSANDRA-3710 URL: https://issues.apache.org/jira/browse/CASSANDRA-3710 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams Fix For: 1.0.8 Let me first say, I hate this idea. It gives cassandra the ability to permanently delete data at a large scale without any means of recovery. However, I've seen this requested multiple times, and it is in fact useful in some scenarios, such as when your application is using an embedded cassandra instance for testing and need to truncate, which without JNA will timeout more often than not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3734) Support native link w/o JNA in Java7
[ https://issues.apache.org/jira/browse/CASSANDRA-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185325#comment-13185325 ] Jonathan Ellis commented on CASSANDRA-3734: --- http://stackoverflow.com/a/4526126 explains how to stub this in with an interface so we can continue to use JNA/exec for Java6 hosts. (But, developers will need Java7 to build.) Support native link w/o JNA in Java7 Key: CASSANDRA-3734 URL: https://issues.apache.org/jira/browse/CASSANDRA-3734 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 1.2 Java7 provides native support for hard links: http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#createLink(java.nio.file.Path, java.nio.file.Path) We should prefer this method when Java7 is the host. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3735) Fix Unable to create hard link SSTableReaderTest error messages
Fix Unable to create hard link SSTableReaderTest error messages
-
Key: CASSANDRA-3735
URL: https://issues.apache.org/jira/browse/CASSANDRA-3735
Project: Cassandra
Issue Type: Bug
Reporter: Jonathan Ellis
Priority: Minor
Sample failure (on Windows):
{noformat}
[junit] java.io.IOException: Exception while executing the command: cmd /c
mklink /H
C:\Users\Jonathan\projects\cassandra\git\build\test\cassandra\data\Keyspace1\backups\Standard1-hc-1-Index.db
c:\Users\Jonathan\projects\cassandra\git\build\test\cassandra\data\Keyspace1\Standard1-hc-1-Index.db,command
error Code: 1, command output: Cannot create a file when that file already
exists.
[junit]
[junit] at org.apache.cassandra.utils.CLibrary.exec(CLibrary.java:213)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLinkWithExec(CLibrary.java:188)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLink(CLibrary.java:151)
[junit] at
org.apache.cassandra.io.sstable.SSTableReader.createLinks(SSTableReader.java:833)
[junit] at
org.apache.cassandra.db.DataTracker$1.runMayThrow(DataTracker.java:161)
[junit] at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[junit] at java.lang.Thread.run(Thread.java:662)
[junit] ERROR 17:10:17,111 Fatal exception in thread
Thread[NonPeriodicTasks:1,5,main]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: update createHardLink calls
Updated Branches: refs/heads/cassandra-1.0 3509f3d35 - f2cb27279 update createHardLink calls Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f2cb2727 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f2cb2727 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f2cb2727 Branch: refs/heads/cassandra-1.0 Commit: f2cb272798ca44d88d13b1f0d69d9a9e7ab70a15 Parents: 3509f3d Author: Jonathan Ellis jbel...@apache.org Authored: Thu Jan 12 17:14:54 2012 -0600 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Jan 12 17:16:03 2012 -0600 -- test/unit/org/apache/cassandra/db/ScrubTest.java |2 +- .../cassandra/io/sstable/SSTableReaderTest.java|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f2cb2727/test/unit/org/apache/cassandra/db/ScrubTest.java -- diff --git a/test/unit/org/apache/cassandra/db/ScrubTest.java b/test/unit/org/apache/cassandra/db/ScrubTest.java index 0e7a2dc..36ff064 100644 --- a/test/unit/org/apache/cassandra/db/ScrubTest.java +++ b/test/unit/org/apache/cassandra/db/ScrubTest.java @@ -68,7 +68,7 @@ public class ScrubTest extends CleanupHelper if (srcFile.getName().equals(.svn)) continue; File destFile = new File(destDirs[0]+File.separator+srcFile.getName()); -CLibrary.createHardLinkWithExec(srcFile, destFile); +CLibrary.createHardLink(srcFile, destFile); destFile = new File(destDirs[0]+File.separator+srcFile.getName()); http://git-wip-us.apache.org/repos/asf/cassandra/blob/f2cb2727/test/unit/org/apache/cassandra/io/sstable/SSTableReaderTest.java -- diff --git a/test/unit/org/apache/cassandra/io/sstable/SSTableReaderTest.java b/test/unit/org/apache/cassandra/io/sstable/SSTableReaderTest.java index f9ee9e3..aff92cf 100644 --- a/test/unit/org/apache/cassandra/io/sstable/SSTableReaderTest.java +++ b/test/unit/org/apache/cassandra/io/sstable/SSTableReaderTest.java @@ -231,7 +231,7 @@ public class SSTableReaderTest extends CleanupHelper if (!srcFile.getName().startsWith(Indexed1)) continue; File destFile = new File(destDirs[0] + File.separator + srcFile.getName()); -CLibrary.createHardLinkWithExec(srcFile, destFile); +CLibrary.createHardLink(srcFile, destFile); destFile = new File(destDirs[0] + File.separator + srcFile.getName());
[jira] [Updated] (CASSANDRA-3735) Fix Unable to create hard link SSTableReaderTest error messages
[
https://issues.apache.org/jira/browse/CASSANDRA-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3735:
--
Attachment: 0002-remove-incremental-backups-before-reloading-sstables.patch
0001-fix-generation-update-in-loadNewSSTables.patch
Two parts:
first makes it so loadNewSSTables won't reset sstable generation to a lower
value than it currently is.
second removes the (hard linked) sstables from the incremental backups
directory, so that when loadNewSSTables links them back in they won't conflict.
patch 2 doesn't actually work on Windows because something is keeping the Data
component open. Java6 just says delete failed; java7's Files.delete says
java.nio.file.FileSystemException:
build\test\cassandra\data\Keyspace1\backups\Standard1-hc-1-Data.db: The process
cannot access the file because it is being used by another process.
I'm guessing it's counting something (what?) that opened the original Data,
towards the link entry as well. But, this should be enough to make the
messages go away on Linux, which takes a more permissive view of deleting files
opened elsewhere.
Fix Unable to create hard link SSTableReaderTest error messages
-
Key: CASSANDRA-3735
URL: https://issues.apache.org/jira/browse/CASSANDRA-3735
Project: Cassandra
Issue Type: Bug
Reporter: Jonathan Ellis
Priority: Minor
Attachments: 0001-fix-generation-update-in-loadNewSSTables.patch,
0002-remove-incremental-backups-before-reloading-sstables.patch
Sample failure (on Windows):
{noformat}
[junit] java.io.IOException: Exception while executing the command: cmd
/c mklink /H
C:\Users\Jonathan\projects\cassandra\git\build\test\cassandra\data\Keyspace1\backups\Standard1-hc-1-Index.db
c:\Users\Jonathan\projects\cassandra\git\build\test\cassandra\data\Keyspace1\Standard1-hc-1-Index.db,command
error Code: 1, command output: Cannot create a file when that file already
exists.
[junit]
[junit] at org.apache.cassandra.utils.CLibrary.exec(CLibrary.java:213)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLinkWithExec(CLibrary.java:188)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLink(CLibrary.java:151)
[junit] at
org.apache.cassandra.io.sstable.SSTableReader.createLinks(SSTableReader.java:833)
[junit] at
org.apache.cassandra.db.DataTracker$1.runMayThrow(DataTracker.java:161)
[junit] at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[junit] at java.lang.Thread.run(Thread.java:662)
[junit] ERROR 17:10:17,111 Fatal exception in thread
Thread[NonPeriodicTasks:1,5,main]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3735) Fix Unable to create hard link SSTableReaderTest error messages
[
https://issues.apache.org/jira/browse/CASSANDRA-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185330#comment-13185330
]
Jonathan Ellis edited comment on CASSANDRA-3735 at 1/12/12 11:29 PM:
-
Two parts:
first makes it so loadNewSSTables won't reset sstable generation to a lower
value than it currently is.
second removes the (hard linked) sstables from the incremental backups
directory, so that when loadNewSSTables links them back in they won't conflict.
patch 2 doesn't actually work on Windows because something is keeping the Data
component open. Java6 just says delete failed; java7's Files.delete says
java.nio.file.FileSystemException:
build\test\cassandra\data\Keyspace1\backups\Standard1-hc-1-Data.db: The process
cannot access the file because it is being used by another process. (Even
after I prototyped CASSANDRA-3734 to use Files.createLink instead of
ProcessBuilder, so that's not the other process.)
I'm guessing it's counting something (what?) that opened the original Data,
towards the link entry as well. But, this should be enough to make the
messages go away on Linux, which takes a more permissive view of deleting files
opened elsewhere.
was (Author: jbellis):
Two parts:
first makes it so loadNewSSTables won't reset sstable generation to a lower
value than it currently is.
second removes the (hard linked) sstables from the incremental backups
directory, so that when loadNewSSTables links them back in they won't conflict.
patch 2 doesn't actually work on Windows because something is keeping the Data
component open. Java6 just says delete failed; java7's Files.delete says
java.nio.file.FileSystemException:
build\test\cassandra\data\Keyspace1\backups\Standard1-hc-1-Data.db: The process
cannot access the file because it is being used by another process.
I'm guessing it's counting something (what?) that opened the original Data,
towards the link entry as well. But, this should be enough to make the
messages go away on Linux, which takes a more permissive view of deleting files
opened elsewhere.
Fix Unable to create hard link SSTableReaderTest error messages
-
Key: CASSANDRA-3735
URL: https://issues.apache.org/jira/browse/CASSANDRA-3735
Project: Cassandra
Issue Type: Bug
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
Attachments: 0001-fix-generation-update-in-loadNewSSTables.patch,
0002-remove-incremental-backups-before-reloading-sstables.patch
Sample failure (on Windows):
{noformat}
[junit] java.io.IOException: Exception while executing the command: cmd
/c mklink /H
C:\Users\Jonathan\projects\cassandra\git\build\test\cassandra\data\Keyspace1\backups\Standard1-hc-1-Index.db
c:\Users\Jonathan\projects\cassandra\git\build\test\cassandra\data\Keyspace1\Standard1-hc-1-Index.db,command
error Code: 1, command output: Cannot create a file when that file already
exists.
[junit]
[junit] at org.apache.cassandra.utils.CLibrary.exec(CLibrary.java:213)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLinkWithExec(CLibrary.java:188)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLink(CLibrary.java:151)
[junit] at
org.apache.cassandra.io.sstable.SSTableReader.createLinks(SSTableReader.java:833)
[junit] at
org.apache.cassandra.db.DataTracker$1.runMayThrow(DataTracker.java:161)
[junit] at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[junit] at java.lang.Thread.run(Thread.java:662)
[junit] ERROR 17:10:17,111 Fatal exception in thread
Thread[NonPeriodicTasks:1,5,main]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Reporter: Jackson Chung
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a -Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting the
replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
Removing token 122029383590318827259508597176866581733 for /50.56.58.55
{noformat}
in the above, /50.56.58.55 was the replaced IP.
tried adding the Gossiper.instance.removeEndpoint(endpoint); in the
StorageService.java where the message 'Nodes %s and %s have the same token %s.
Ignoring %s,' seems only have fixed this temporary. Here is a ring output:
{noformat}
riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
60502102442797279294142560823234402248
50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
85070591730234615865843651857942052864
{noformat}
gossipinfo:
{noformat}
$ ./bin/nodetool -h localhost gossipinfo
/50.56.58.55
LOAD:6835.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.58.55
STATUS:NORMAL,85070591730234615865843651857942052864
RELEASE_VERSION:1.0.7-SNAPSHOT
/50.56.59.68
LOAD:6835.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.59.68
STATUS:NORMAL,60502102442797279294142560823234402248
RELEASE_VERSION:1.0.7-SNAPSHOT
action-quick2/50.56.31.186
LOAD:11387.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.31.186
STATUS:NORMAL,85070591730234615865843651857942052864
RELEASE_VERSION:1.0.7-SNAPSHOT
{noformat}
Note that at 1 point earlier it seems to have been removed:
$ ./bin/nodetool -h localhost gossipinfo
/50.56.59.68
LOAD:13815.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.59.68
STATUS:NORMAL,60502102442797279294142560823234402248
RELEASE_VERSION:1.0.7-SNAPSHOT
[jira] [Updated] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3736:
Reviewer: brandon.williams
Component/s: Core
Affects Version/s: 1.0.0
Fix Version/s: 1.0.7
Assignee: Vijay
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
Removing token 122029383590318827259508597176866581733 for /50.56.58.55
{noformat}
in the above, /50.56.58.55 was the replaced IP.
tried adding the Gossiper.instance.removeEndpoint(endpoint); in the
StorageService.java where the message 'Nodes %s and %s have the same token
%s. Ignoring %s,' seems only have fixed this temporary. Here is a ring
output:
{noformat}
riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
60502102442797279294142560823234402248
50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
85070591730234615865843651857942052864
{noformat}
gossipinfo:
{noformat}
$ ./bin/nodetool -h localhost gossipinfo
/50.56.58.55
LOAD:6835.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.58.55
STATUS:NORMAL,85070591730234615865843651857942052864
RELEASE_VERSION:1.0.7-SNAPSHOT
/50.56.59.68
LOAD:6835.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.59.68
[jira] [Commented] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185379#comment-13185379
]
Vijay commented on CASSANDRA-3736:
--
Hi Jackson, Just a clarification is 50.56.58.55 up and cassandra is running?
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
This happens when the replaced node is running or resurrected.
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
Removing token 122029383590318827259508597176866581733 for /50.56.58.55
{noformat}
in the above, /50.56.58.55 was the replaced IP.
tried adding the Gossiper.instance.removeEndpoint(endpoint); in the
StorageService.java where the message 'Nodes %s and %s have the same token
%s. Ignoring %s,' seems only have fixed this temporary. Here is a ring
output:
{noformat}
riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
60502102442797279294142560823234402248
50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
85070591730234615865843651857942052864
{noformat}
gossipinfo:
{noformat}
$ ./bin/nodetool -h localhost gossipinfo
/50.56.58.55
LOAD:6835.0
SCHEMA:--1000--
[jira] [Commented] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185385#comment-13185385
]
David Strauss commented on CASSANDRA-3736:
--
Hi Vijay,
I filed the ticket with DataStax that prompted this issue. I'm not 100% certain
whether the node we replaced was fully and consistently offline from the point
we performed the replacement. I *believe* it was, especially because the
-Dreplace_token refuses to work if the node being replaced is online and we
took no further action to bring the replaced node back (its VM wasn't
initializing any network interfaces other than lo).
Even if the replaced node comes back, it shouldn't be allowed to re-join the
ring with a token already owned by an Up node. It should be subjected to the
same condition -Dreplace_token is, where the token being used by the new ring
member must be owned by a Down node.
David
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
Removing token 122029383590318827259508597176866581733 for /50.56.58.55
{noformat}
in the above, /50.56.58.55 was the replaced IP.
tried adding the Gossiper.instance.removeEndpoint(endpoint); in the
StorageService.java where the message 'Nodes %s and %s have the same token
%s. Ignoring %s,' seems only have fixed this temporary. Here is a ring
output:
{noformat}
riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
50.56.59.68 datacenter1 rack1
[jira] [Issue Comment Edited] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185385#comment-13185385
]
David Strauss edited comment on CASSANDRA-3736 at 1/13/12 1:52 AM:
---
Hi Vijay,
I filed the ticket with DataStax that prompted this issue. I'm not 100% certain
whether the node we replaced was fully and consistently offline from the point
we performed the replacement. I *believe* it was, especially because the
-Dreplace_token refuses to work if the node being replaced is online -- and we
took no further action to bring the replaced node back (its VM wasn't
initializing any network interfaces other than lo).
Even if the replaced node comes back, it shouldn't be allowed to re-join the
ring with a token already owned by an Up node. It should be subjected to the
same condition -Dreplace_token is, where the token being used by the new ring
member must be owned by a Down node.
David
was (Author: davidstrauss):
Hi Vijay,
I filed the ticket with DataStax that prompted this issue. I'm not 100% certain
whether the node we replaced was fully and consistently offline from the point
we performed the replacement. I *believe* it was, especially because the
-Dreplace_token refuses to work if the node being replaced is online and we
took no further action to bring the replaced node back (its VM wasn't
initializing any network interfaces other than lo).
Even if the replaced node comes back, it shouldn't be allowed to re-join the
ring with a token already owned by an Up node. It should be subjected to the
same condition -Dreplace_token is, where the token being used by the new ring
member must be owned by a Down node.
David
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress
[jira] [Issue Comment Edited] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185385#comment-13185385
]
David Strauss edited comment on CASSANDRA-3736 at 1/13/12 1:52 AM:
---
Hi Vijay,
I filed the ticket with DataStax that prompted this issue. I'm not 100% certain
whether the node we replaced was fully and consistently offline from the point
we performed the replacement. I *believe* it was, especially because the
-Dreplace_token refuses to work if the node being replaced is online --- and we
took no further action to bring the replaced node back (its VM wasn't
initializing any network interfaces other than lo).
Even if the replaced node comes back, it shouldn't be allowed to re-join the
ring with a token already owned by an Up node. It should be subjected to the
same condition -Dreplace_token is, where the token being used by the new ring
member must be owned by a Down node.
David
was (Author: davidstrauss):
Hi Vijay,
I filed the ticket with DataStax that prompted this issue. I'm not 100% certain
whether the node we replaced was fully and consistently offline from the point
we performed the replacement. I *believe* it was, especially because the
-Dreplace_token refuses to work if the node being replaced is online -- and we
took no further action to bring the replaced node back (its VM wasn't
initializing any network interfaces other than lo).
Even if the replaced node comes back, it shouldn't be allowed to re-join the
ring with a token already owned by an Up node. It should be subjected to the
same condition -Dreplace_token is, where the token being used by the new ring
member must be owned by a Down node.
David
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress
[jira] [Commented] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185388#comment-13185388
]
David Strauss commented on CASSANDRA-3736:
--
Alternatively, it would be good for Cassandra to provide a convenient
(nodetool) way to drop the Down IP when a token is simultaneously occupied by
one Up IP and at least one Down IP.
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
Removing token 122029383590318827259508597176866581733 for /50.56.58.55
{noformat}
in the above, /50.56.58.55 was the replaced IP.
tried adding the Gossiper.instance.removeEndpoint(endpoint); in the
StorageService.java where the message 'Nodes %s and %s have the same token
%s. Ignoring %s,' seems only have fixed this temporary. Here is a ring
output:
{noformat}
riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
60502102442797279294142560823234402248
50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
85070591730234615865843651857942052864
{noformat}
gossipinfo:
{noformat}
$ ./bin/nodetool -h localhost gossipinfo
/50.56.58.55
LOAD:6835.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.58.55
STATUS:NORMAL,85070591730234615865843651857942052864
RELEASE_VERSION:1.0.7-SNAPSHOT
/50.56.59.68
LOAD:6835.0
[jira] [Commented] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185389#comment-13185389
]
Brandon Williams commented on CASSANDRA-3736:
-
bq. Alternatively, it would be good for Cassandra to provide a convenient
(nodetool) way to drop the Down IP when a token is simultaneously occupied by
one Up IP and at least one Down IP.
CASSANDRA-3337 is designed to handle these kinds of situations (where gossip is
not doing the right thing naturally)
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
Removing token 122029383590318827259508597176866581733 for /50.56.58.55
{noformat}
in the above, /50.56.58.55 was the replaced IP.
tried adding the Gossiper.instance.removeEndpoint(endpoint); in the
StorageService.java where the message 'Nodes %s and %s have the same token
%s. Ignoring %s,' seems only have fixed this temporary. Here is a ring
output:
{noformat}
riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
60502102442797279294142560823234402248
50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
85070591730234615865843651857942052864
{noformat}
gossipinfo:
{noformat}
$ ./bin/nodetool -h localhost gossipinfo
/50.56.58.55
LOAD:6835.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.58.55
[jira] [Commented] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13185398#comment-13185398
]
Jackson Chung commented on CASSANDRA-3736:
--
bq. is 50.56.58.55 up and cassandra is running?
no. the Cassandra on 50.56.58.55 was not UP/had shutdown. But the IP is
available, though i don't think that matters.
so my test case was simply:
1) start 2 nodes (A , B). With A being the seed, B bootstrap into it (by
specifying a token)
2) stop B (after B had successfully joined)
3) start C with -Dcassandra.replace_token=B's token
continuing restarting C (without the replace_token param) could observe the
behavior.
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
Removing token 122029383590318827259508597176866581733 for /50.56.58.55
{noformat}
in the above, /50.56.58.55 was the replaced IP.
tried adding the Gossiper.instance.removeEndpoint(endpoint); in the
StorageService.java where the message 'Nodes %s and %s have the same token
%s. Ignoring %s,' seems only have fixed this temporary. Here is a ring
output:
{noformat}
riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
60502102442797279294142560823234402248
50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
85070591730234615865843651857942052864
{noformat}
gossipinfo:
{noformat}
[jira] [Updated] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay updated CASSANDRA-3736:
-
Attachment: 0001-CASSANDRA-3736.patch
Simple patch to remove from SYSTEM_TABLE/RING_KEY when token is replaced.
-Dreplace_token leaves old node (IP) in the gossip with the token.
--
Key: CASSANDRA-3736
URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jackson Chung
Assignee: Vijay
Fix For: 1.0.7
Attachments: 0001-CASSANDRA-3736.patch
https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
-Dreplace_token,
however, the replaced IP keeps on showing up in the Gossiper when starting
the replacement node:
{noformat}
INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
Listening for thrift clients...
INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
/50.56.59.68 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
InetAddress /50.56.59.68 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
Node /50.56.59.68 state jump to normal
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
/50.56.58.55 has restarted, now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
/50.56.58.55 is now part of the cluster
INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
InetAddress /50.56.58.55 is now UP
INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
85070591730234615865843651857942052864. Ignoring /50.56.58.55
INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
InetAddress /50.56.58.55 is now dead.
INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
Removing token 122029383590318827259508597176866581733 for /50.56.58.55
{noformat}
in the above, /50.56.58.55 was the replaced IP.
tried adding the Gossiper.instance.removeEndpoint(endpoint); in the
StorageService.java where the message 'Nodes %s and %s have the same token
%s. Ignoring %s,' seems only have fixed this temporary. Here is a ring
output:
{noformat}
riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
60502102442797279294142560823234402248
50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
85070591730234615865843651857942052864
{noformat}
gossipinfo:
{noformat}
$ ./bin/nodetool -h localhost gossipinfo
/50.56.58.55
LOAD:6835.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.58.55
STATUS:NORMAL,85070591730234615865843651857942052864
RELEASE_VERSION:1.0.7-SNAPSHOT
/50.56.59.68
LOAD:6835.0
SCHEMA:--1000--
RPC_ADDRESS:50.56.59.68
[Cassandra Wiki] Update of Committers by JonathanEllis
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Committers page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/Committers?action=diffrev1=17rev2=18 ||Jake Luciani||Jan 2011||Datastax||Also a [[http://thrift.apache.org/|Thrift]] committer|| ||Sylvain Lebresne||Mar 2011||Datastax||PMC member, Release manager|| ||Pavel Yaskevich||Aug 2011||Datastax|| || + ||Vijay Parthasarathy||Jan 2012||Netflix|| ||
git commit: Allow DynamicCompositeType to compare components of different types
Updated Branches:
refs/heads/cassandra-1.0 f2cb27279 - 6a1ed6205
Allow DynamicCompositeType to compare components of different types
patch by slebresne; reviewed by edanuff for CASSANDRA-3625
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6a1ed620
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6a1ed620
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6a1ed620
Branch: refs/heads/cassandra-1.0
Commit: 6a1ed6205cad8d019eb6eda326d7796a8a0dd67b
Parents: f2cb272
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Fri Jan 13 08:49:21 2012 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Fri Jan 13 08:49:21 2012 +0100
--
CHANGES.txt|2 +
.../cassandra/db/marshal/DynamicCompositeType.java | 54 ++-
.../db/marshal/DynamicCompositeTypeTest.java | 28
3 files changed, 81 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6a1ed620/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 39211a4..30c002d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -26,6 +26,8 @@
* Improve stream protocol mismatch errors (CASSANDRA-3652)
* Avoid multiple thread doing HH to the same target (CASSANDRA-3681)
* Add JMX property for rp_timeout_in_ms (CASSANDRA-2940)
+ * Allow DynamicCompositeType to compare component of different types
+ (CASSANDRA-3625)
Merged from 0.8:
* avoid logging (harmless) exception when GC takes 1ms (CASSANDRA-3656)
* prevent new nodes from thinking down nodes are up forever (CASSANDRA-3626)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6a1ed620/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
--
diff --git a/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
b/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
index 592f392..53e10d3 100644
--- a/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
+++ b/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
@@ -117,11 +117,25 @@ public class DynamicCompositeType extends
AbstractCompositeType
AbstractType comp1 = getComparator(bb1);
AbstractType comp2 = getComparator(bb2);
-// This rely on comparator always being singleton instances
+// Fast test if the comparator uses singleton instances
if (comp1 != comp2)
{
-logger.error(Mismatch between {} and {}, comp1, comp2);
-throw new RuntimeException(Comparator mismatch while comparing
two DynamicCompositeType colum name);
+/*
+ * We compare component of different types by comparing the
+ * comparator class names. We start with the simple classname
+ * first because that will be faster in almost all cases, but
+ * allback on the full name if necessary
+*/
+int cmp =
comp1.getClass().getSimpleName().compareTo(comp2.getClass().getSimpleName());
+if (cmp != 0)
+return cmp 0 ? FixedValueComparator.instance :
ReversedType.getInstance(FixedValueComparator.instance);
+
+cmp =
comp1.getClass().getName().compareTo(comp2.getClass().getName());
+if (cmp != 0)
+return cmp 0 ? FixedValueComparator.instance :
ReversedType.getInstance(FixedValueComparator.instance);
+
+// if cmp == 0, we're actually having the same type, but one that
+// did not have a singleton instance. It's ok (though inefficient).
}
return comp1;
}
@@ -263,4 +277,38 @@ public class DynamicCompositeType extends
AbstractCompositeType
{
return getClass().getName() +
TypeParser.stringifyAliasesParameters(aliases);
}
+
+/*
+ * A comparator that always sorts it's first argument before the second
+ * one.
+ */
+private static class FixedValueComparator extends AbstractTypeVoid
+{
+public static final FixedValueComparator instance = new
FixedValueComparator();
+
+public int compare(ByteBuffer v1, ByteBuffer v2)
+{
+return -1;
+}
+
+public Void compose(ByteBuffer bytes)
+{
+throw new UnsupportedOperationException();
+}
+
+public ByteBuffer decompose(Void value)
+{
+throw new UnsupportedOperationException();
+}
+
+public String getString(ByteBuffer bytes)
+{
+throw new UnsupportedOperationException();
+}
+
+public void validate(ByteBuffer bytes)
+{
+throw new
