[jira] [Commented] (CASSANDRA-3511) Supercolumn key caches are not saved
[ https://issues.apache.org/jira/browse/CASSANDRA-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156585#comment-13156585 ] Radim Kolar commented on CASSANDRA-3511: In my case super CF not saving cache looks like this: Key cache capacity: 22825 Key cache size: 22825 Key cache hit rate: 0.1851423197945676 Row cache capacity: 480 Row cache size: 480 Row cache hit rate: 0.18145943635108028 Cache is full but it is not saved, only loaded at startup. Supercolumn key caches are not saved Key: CASSANDRA-3511 URL: https://issues.apache.org/jira/browse/CASSANDRA-3511 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.2, 1.0.3 Reporter: Radim Kolar Priority: Minor Labels: supercolumns cache saving seems to be broken in 1.0.2 and 1.0.3 i have 2 CF in keyspace with enabled cache saving and only one gets its key cache saved. It worked perfectly in 0.8, both were saved. This one works: create column family query2 with column_type = 'Standard' and comparator = 'AsciiType' and default_validation_class = 'BytesType' and key_validation_class = 'UTF8Type' and rows_cached = 500.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 14400 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 5 and max_compaction_threshold = 10 and replicate_on_write = false and row_cache_provider = 'ConcurrentLinkedHashCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' This does not create column family dkb13 with column_type = 'Super' and comparator = 'LongType' and subcomparator = 'AsciiType' and default_validation_class = 'BytesType' and key_validation_class = 'UTF8Type' and rows_cached = 600.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 14400 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 5 and max_compaction_threshold = 10 and replicate_on_write = false and row_cache_provider = 'ConcurrentLinkedHashCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' in second test system i created these 2 column families and none of them got single cache key saved. Both have save period 30 seoonds - their cache should save often. Its not that standard column family works while super does not. create column family test1 with column_type = 'Standard' and comparator = 'BytesType' and default_validation_class = 'BytesType' and key_validation_class = 'BytesType' and rows_cached = 0.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 30 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and row_cache_provider = 'SerializingCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'; create column family test2 with column_type = 'Standard' and comparator = 'BytesType' and default_validation_class = 'BytesType' and key_validation_class = 'BytesType' and rows_cached = 0.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 30 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and row_cache_provider = 'SerializingCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'; If this is done on purpose for example cassandra 1.0 is doing some heuristic decision if cache should be saved or not then it should be removed. Saving cache is fast. -- 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-3306) Error in LeveledCompactionStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156589#comment-13156589
]
Sylvain Lebresne commented on CASSANDRA-3306:
-
As I already said, if you are able to reproduce this, please try reproducing
with 1.0.3. And if you are still able to, please attach you system.log with the
exception here because it will have more info on the error that should help.
And if you're not able to reproduce with 1.0.3, then I guess it means we've
fixed it without knowing.
Error in LeveledCompactionStrategy
--
Key: CASSANDRA-3306
URL: https://issues.apache.org/jira/browse/CASSANDRA-3306
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Radim Kolar
Fix For: 1.0.4
during stress testing, i always get this error making leveledcompaction
strategy unusable. Should be easy to reproduce - just write fast.
ERROR [CompactionExecutor:6] 2011-10-04 15:48:52,179
AbstractCassandraDaemon.java (line 133) Fatal exception in thread
Thread[CompactionExecutor:6,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.DataTracker$View.newSSTables(DataTracker.java:580)
at
org.apache.cassandra.db.DataTracker$View.replace(DataTracker.java:546)
at org.apache.cassandra.db.DataTracker.replace(DataTracker.java:268)
at
org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:232)
at
org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:960)
at
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:199)
at
org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:47)
at
org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:131)
at
org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:114)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
and this is in json data for table:
{
generations : [ {
generation : 0,
members : [ 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470,
471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484 ]
}, {
generation : 1,
members : [ ]
}, {
generation : 2,
members : [ ]
}, {
generation : 3,
members : [ ]
}, {
generation : 4,
members : [ ]
}, {
generation : 5,
members : [ ]
}, {
generation : 6,
members : [ ]
}, {
generation : 7,
members : [ ]
} ]
}
--
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-2749) fine-grained control over data directories
[ https://issues.apache.org/jira/browse/CASSANDRA-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-2749: --- Attachment: 2749_proper.tar.gz updated, of course mv should be used :) rebased as well fine-grained control over data directories -- Key: CASSANDRA-2749 URL: https://issues.apache.org/jira/browse/CASSANDRA-2749 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 1.1 Attachments: 0001-Make-it-possible-to-put-column-families-in-subdirect.patch, 0001-non-backwards-compatible-patch-for-2749-putting-cfs-.patch.gz, 2749.tar.gz, 2749_backwards_compatible_v1.patch, 2749_backwards_compatible_v2.patch, 2749_backwards_compatible_v3.patch, 2749_backwards_compatible_v4.patch, 2749_backwards_compatible_v4_rebase1.patch, 2749_not_backwards.tar.gz, 2749_proper.tar.gz Currently Cassandra supports multiple data directories but no way to control what sstables are placed where. Particularly for systems with mixed SSDs and rotational disks, it would be nice to pin frequently accessed columnfamilies to the SSDs. Postgresql does this with tablespaces (http://www.postgresql.org/docs/9.0/static/manage-ag-tablespaces.html) but we should probably avoid using that name because of confusing similarity to keyspaces. -- 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-1684) Entity groups
[ https://issues.apache.org/jira/browse/CASSANDRA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156596#comment-13156596 ] Daniel Doubleday commented on CASSANDRA-1684: - Two use cases where same row does not work for us: - Read/Write intense CFs where we need row caching but cannot cache all values due to their size (CASSANDRA-1956 in its current form will not help there) - Heavy update CFs where we use changing (versioned) row keys to avoid multiple-sstable-reads Entity groups - Key: CASSANDRA-1684 URL: https://issues.apache.org/jira/browse/CASSANDRA-1684 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.1 Original Estimate: 80h Remaining Estimate: 80h Supporting entity groups similar to App Engine's (that is, allow rows to be part of a parent entity group, whose key is used for routing instead of the row itself) allows several improvements: - batches within an EG can be atomic across multiple rows - order-by-value queries within an EG only have to touch a single replica even with RandomPartitioner -- 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-1311) Triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156605#comment-13156605 ] Martin Hentschel commented on CASSANDRA-1311: - I like the idea of triggers that are based on the commit log. I haven't fully understood Jonathan's crack smoking above, but basing fault tolerance guarantees on the log certainly is a good idea. Yet, completely different to the patch we have submitted. The question is, how much help is the patch now, and what are the next steps. Triggers Key: CASSANDRA-1311 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 Project: Cassandra Issue Type: New Feature Reporter: Maxim Grinev Fix For: 1.1 Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf, ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Please find the motivation, triggers description and list of applications: http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ An example of using triggers for indexing: http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ Implementation details are attached. -- 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-3440) local writes timing out cause attempt to hint to self
[
https://issues.apache.org/jira/browse/CASSANDRA-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156610#comment-13156610
]
Sylvain Lebresne commented on CASSANDRA-3440:
-
Nit: it doesn't seem we use the row mutations saved in hintsInProgess, so maybe
we could use a simple AtomicInteger, rather than a full concurrent map.
But otherwise patch looks good, +1.
local writes timing out cause attempt to hint to self
-
Key: CASSANDRA-3440
URL: https://issues.apache.org/jira/browse/CASSANDRA-3440
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Labels: hintedhandoff
Fix For: 1.0.4
Attachments: 3440-v2.txt, 3440.txt
As reported by Ramash Natarajan on the mailing list:
{noformat}
We have a 8 node cassandra cluster running 1.0.1. After running a load
test for a day we are seeing this exception in system.log file.
ERROR [EXPIRING-MAP-TIMER-1] 2011-11-01 13:20:45,350
AbstractCassandraDaemon.java (line 133) Fatal exception in thread
Thread[EXPIRING-MAP-TIMER-1,5,main]
java.lang.AssertionError: /10.19.102.12
at
org.apache.cassandra.service.StorageProxy.scheduleLocalHint(StorageProxy.java:339)
at
org.apache.cassandra.net.MessagingService.scheduleMutationHint(MessagingService.java:201)
at
org.apache.cassandra.net.MessagingService.access$500(MessagingService.java:64)
at
org.apache.cassandra.net.MessagingService$2.apply(MessagingService.java:175)
at
org.apache.cassandra.net.MessagingService$2.apply(MessagingService.java:152)
at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:89)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
{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] [Updated] (CASSANDRA-3486) Node Tool command to stop repair
[ https://issues.apache.org/jira/browse/CASSANDRA-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-3486: Affects Version/s: (was: 1.0.4) 1.1 Fix Version/s: (was: 1.0.4) Moving to 1.1 because this will almost certainly require a wire protocol change. Also, CASSANDRA-3112 requires a very similar change (basically validation needs to be able to report an error back to the repair), so it's worth making room for both of those changes together. Node Tool command to stop repair Key: CASSANDRA-3486 URL: https://issues.apache.org/jira/browse/CASSANDRA-3486 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.1 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Labels: nodetool, repair, stop After CASSANDRA-1740, If the validation compaction is stopped then the repair will hang. This ticket will allow users to kill the original repair. -- 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-3402) Runtime exception thrown periodically under load
[ https://issues.apache.org/jira/browse/CASSANDRA-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156756#comment-13156756 ] Sylvain Lebresne commented on CASSANDRA-3402: - Hi Andy, It would be interesting to see if you can reproduce after an upgrade to 1.0.3. If so, the exception (and log) should give a bit more info hopefully (we've added details). Also, 1.0.3 now include a sha1 of each sstable, which would help ruling out an external (hardware) corruption. Runtime exception thrown periodically under load Key: CASSANDRA-3402 URL: https://issues.apache.org/jira/browse/CASSANDRA-3402 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: Cassandra 1.0 Red Hat Enterprise Linux Server 6.0 Reporter: Andy Stec Assignee: Sylvain Lebresne Fix For: 1.0.4 Attachments: system.log.gz The exception listed below is thrown periodically. We're using thrift interface for C++. Jonathan Ellis requested that we open a bug for this. ERROR [ReadStage:1761] 2011-10-25 12:17:16,088 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[ReadStage:1761,5,main] java.lang.RuntimeException: error reading 5 of 5 at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:40) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:107) at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:145) at org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:124) at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:116) at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:144) at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:225) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:61) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1297) at org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1128) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1157) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1114) at org.apache.cassandra.db.Table.getRow(Table.java:388) at org.apache.cassandra.db.SliceByNamesReadCommand.getRow(SliceByNamesReadCommand.java:58) at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:62) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid column name length 0 at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:89) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:82) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:72) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:36) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:79) ... 24 more -- 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-3422) Can create a Column Family with comparator CounterColumnType which is subsequently unusable
[ https://issues.apache.org/jira/browse/CASSANDRA-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156762#comment-13156762 ] Sylvain Lebresne commented on CASSANDRA-3422: - Any opinion related to my previous comment? Can create a Column Family with comparator CounterColumnType which is subsequently unusable --- Key: CASSANDRA-3422 URL: https://issues.apache.org/jira/browse/CASSANDRA-3422 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Kelley Reynolds Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0.4 Attachments: 3422.patch It's probably the case that this shouldn't be allowed at all but one is currently allowed to create a Column Family with comparator CounterColumnType which then appears unusable. CREATE COLUMNFAMILY comparator_cf_counter (id text PRIMARY KEY) WITH comparator=CounterColumnType # Fails UPDATE comparator_cf_counter SET 1=1 + 1 WHERE id='test_key' Error = invalid operation for non commutative columnfamily comparator_cf_counter -- 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-3498) Add same-row contention mode to stress tool
[ https://issues.apache.org/jira/browse/CASSANDRA-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156783#comment-13156783 ] Eric Evans commented on CASSANDRA-3498: --- I used -L in https://issues.apache.org/jira/browse/CASSANDRA-2268 (patches will be along shortly) for --enable-cql. Are there any other short options we could use for this? Add same-row contention mode to stress tool --- Key: CASSANDRA-3498 URL: https://issues.apache.org/jira/browse/CASSANDRA-3498 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1 Attachments: CASSANDRA-3498.patch For CASSANDRA-2893 and other scenarios we'd like to generate non-unique rows to insert. (Maybe we can re-use the same pseudorandom distribution code we already have for reads.) -- 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-3498) Add same-row contention mode to stress tool
[ https://issues.apache.org/jira/browse/CASSANDRA-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156801#comment-13156801 ] Sylvain Lebresne commented on CASSANDRA-3498: - I understand I'm coming a little late, but I actually remembered that for counters we've introduced the -F option, that allows to specify how many different keys to use. In other word, stress -n 1 -F 1 will do 1 insertion on the same row. Maybe that could actually be enough for generating artificial contention ? Add same-row contention mode to stress tool --- Key: CASSANDRA-3498 URL: https://issues.apache.org/jira/browse/CASSANDRA-3498 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1 Attachments: CASSANDRA-3498.patch For CASSANDRA-2893 and other scenarios we'd like to generate non-unique rows to insert. (Maybe we can re-use the same pseudorandom distribution code we already have for reads.) -- 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-1740) Nodetool commands to query and stop compaction, repair, cleanup and scrub
[ https://issues.apache.org/jira/browse/CASSANDRA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156810#comment-13156810 ] Vijay commented on CASSANDRA-1740: -- Yeah I did try it and saw the exception, I was not sure who is wrapping it again with rte. Sent from my iPhone Nodetool commands to query and stop compaction, repair, cleanup and scrub - Key: CASSANDRA-1740 URL: https://issues.apache.org/jira/browse/CASSANDRA-1740 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Chip Salzenberg Assignee: Vijay Priority: Minor Labels: compaction Fix For: 1.0.4 Attachments: 0001-Patch-to-Stop-compactions-v2.patch, 0001-Patch-to-Stop-compactions-v3.patch, 0001-Patch-to-Stop-compactions-v4.patch, 0001-Patch-to-Stop-compactions-v5.patch, 0001-Patch-to-Stop-compactions.patch, CASSANDRA-1740.patch Original Estimate: 24h Remaining Estimate: 24h The only way to stop compaction, repair, cleanup, or scrub in progress is to stop and restart the entire Cassandra server. Please provide nodetool commands to query whether such things are running, and stop them if they are. -- 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-3498) Add same-row contention mode to stress tool
[ https://issues.apache.org/jira/browse/CASSANDRA-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156811#comment-13156811 ] Jonathan Ellis commented on CASSANDRA-3498: --- how does it distribute updates across rows if n F? Add same-row contention mode to stress tool --- Key: CASSANDRA-3498 URL: https://issues.apache.org/jira/browse/CASSANDRA-3498 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1 Attachments: CASSANDRA-3498.patch For CASSANDRA-2893 and other scenarios we'd like to generate non-unique rows to insert. (Maybe we can re-use the same pseudorandom distribution code we already have for reads.) -- 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-3498) Add same-row contention mode to stress tool
[ https://issues.apache.org/jira/browse/CASSANDRA-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156835#comment-13156835 ] Sylvain Lebresne commented on CASSANDRA-3498: - It uses a modulo on the 'operation number', so with say -F 3, the producer will generate inserts for keys 0, 1, 2, 0, 1, 2, etc... So it's a bit dumb, but by varying the number of threads, I believe you can control a bit the level of contention (typically, -F 1 means every writes are contending, but say -F 5 with 10 threads means less contention, and then -F 8 with 10 threads even less). Add same-row contention mode to stress tool --- Key: CASSANDRA-3498 URL: https://issues.apache.org/jira/browse/CASSANDRA-3498 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1 Attachments: CASSANDRA-3498.patch For CASSANDRA-2893 and other scenarios we'd like to generate non-unique rows to insert. (Maybe we can re-use the same pseudorandom distribution code we already have for reads.) -- 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-1740) Nodetool commands to query and stop compaction, repair, cleanup and scrub
[ https://issues.apache.org/jira/browse/CASSANDRA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156810#comment-13156810 ] Vijay edited comment on CASSANDRA-1740 at 11/24/11 5:27 PM: Yeah I did try it and saw the exception, I was not sure who is wrapping it again with RTE. To be more clear: The RTE additional wrap is because WrappableRunnable which catches all Exceptions just to wrap it to a RTE (plz check http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/RuntimeException.java). Hope this helps :) was (Author: vijay2...@yahoo.com): Yeah I did try it and saw the exception, I was not sure who is wrapping it again with rte. Sent from my iPhone Nodetool commands to query and stop compaction, repair, cleanup and scrub - Key: CASSANDRA-1740 URL: https://issues.apache.org/jira/browse/CASSANDRA-1740 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Chip Salzenberg Assignee: Vijay Priority: Minor Labels: compaction Fix For: 1.0.4 Attachments: 0001-Patch-to-Stop-compactions-v2.patch, 0001-Patch-to-Stop-compactions-v3.patch, 0001-Patch-to-Stop-compactions-v4.patch, 0001-Patch-to-Stop-compactions-v5.patch, 0001-Patch-to-Stop-compactions.patch, CASSANDRA-1740.patch Original Estimate: 24h Remaining Estimate: 24h The only way to stop compaction, repair, cleanup, or scrub in progress is to stop and restart the entire Cassandra server. Please provide nodetool commands to query whether such things are running, and stop them if they are. -- 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-1311) Triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156841#comment-13156841 ] Edward Capriolo commented on CASSANDRA-1311: I think 'crack triggers' sounds great for street cred. I like the approach of writing the trigger to disk. This would allow us to separate the logging of the action with the trigger action which I am guessing would be its stage. This seems like a good tradeoff, space to store the events, and a background thread to replay the events. I am thinking this trigger CF would be ordered so we can replay triggers by time and page through them without too much disk cost. Triggers Key: CASSANDRA-1311 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 Project: Cassandra Issue Type: New Feature Reporter: Maxim Grinev Fix For: 1.1 Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf, ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Please find the motivation, triggers description and list of applications: http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ An example of using triggers for indexing: http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ Implementation details are attached. -- 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-3498) Add same-row contention mode to stress tool
[ https://issues.apache.org/jira/browse/CASSANDRA-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156859#comment-13156859 ] Pavel Yaskevich commented on CASSANDRA-3498: I overlooked -F option and it seems that -F 1 is the behavior we want in this case. Add same-row contention mode to stress tool --- Key: CASSANDRA-3498 URL: https://issues.apache.org/jira/browse/CASSANDRA-3498 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1 Attachments: CASSANDRA-3498.patch For CASSANDRA-2893 and other scenarios we'd like to generate non-unique rows to insert. (Maybe we can re-use the same pseudorandom distribution code we already have for reads.) -- 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
svn commit: r1205969 - in /cassandra/branches/cassandra-1.0: ./ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/net/ src/java/org/apache/cassandra/service/
Author: jbellis
Date: Thu Nov 24 20:05:37 2011
New Revision: 1205969
URL: http://svn.apache.org/viewvc?rev=1205969view=rev
Log:
fix self-hinting of timed out read repair updates and make hinted handoff less
prone to OOMing a coordinator
patch by jbellis; reviewed by slebresne for CASSANDRA-3440
Modified:
cassandra/branches/cassandra-1.0/CHANGES.txt
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/RowMutation.java
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/service/RowRepairResolver.java
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/service/StorageProxy.java
Modified: cassandra/branches/cassandra-1.0/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1205969r1=1205968r2=1205969view=diff
==
--- cassandra/branches/cassandra-1.0/CHANGES.txt (original)
+++ cassandra/branches/cassandra-1.0/CHANGES.txt Thu Nov 24 20:05:37 2011
@@ -1,4 +1,6 @@
1.0.4
+ * fix self-hinting of timed out read repair updates and make hinted handoff
+ less prone to OOMing a coordinator (CASSANDRA-3440)
* expose bloom filter sizes via JMX (CASSANDRA-3495)
* enforce RP tokens 0..2**127 (CASSANDRA-3501)
* canonicalize paths exposed through JMX (CASSANDRA-3504)
Modified:
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/RowMutation.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/RowMutation.java?rev=1205969r1=1205968r2=1205969view=diff
==
---
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/RowMutation.java
(original)
+++
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/RowMutation.java
Thu Nov 24 20:05:37 2011
@@ -263,10 +263,10 @@ public class RowMutation implements IMut
public Message getMessage(Integer version) throws IOException
{
-return makeRowMutationMessage(StorageService.Verb.MUTATION, version);
+return getMessage(StorageService.Verb.MUTATION, version);
}
-public Message makeRowMutationMessage(StorageService.Verb verb, int
version) throws IOException
+public Message getMessage(StorageService.Verb verb, int version) throws
IOException
{
return new Message(FBUtilities.getBroadcastAddress(), verb,
getSerializedBuffer(version), version);
}
Modified:
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java?rev=1205969r1=1205968r2=1205969view=diff
==
---
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java
(original)
+++
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java
Thu Nov 24 20:05:37 2011
@@ -27,7 +27,6 @@ import java.nio.channels.AsynchronousClo
import java.nio.channels.ServerSocketChannel;
import java.util.*;
import java.util.concurrent.ExecutorService;
-import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLong;
@@ -36,7 +35,6 @@ import javax.management.ObjectName;
import com.google.common.base.Function;
import com.google.common.collect.Lists;
-
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -170,9 +168,16 @@ public final class MessagingService impl
if (expiredCallbackInfo.shouldHint())
{
-// Trigger hints for expired mutation message.
assert expiredCallbackInfo.message != null;
-scheduleMutationHint(expiredCallbackInfo.message,
expiredCallbackInfo.target);
+try
+{
+RowMutation rm =
RowMutation.fromBytes(expiredCallbackInfo.message.getMessageBody(),
expiredCallbackInfo.message.getVersion());
+return StorageProxy.scheduleLocalHint(rm,
expiredCallbackInfo.target, null, null);
+}
+catch (IOException e)
+{
+logger_.error(Unable to deserialize mutation when
writting hint for: + expiredCallbackInfo.target);
+}
}
return null;
@@ -192,21 +197,6 @@ public final class MessagingService impl
}
}
-
-private Future? scheduleMutationHint(Message mutationMessage,
InetAddress mutationTarget)
-{
-try
-{
-RowMutation rm =
RowMutation.fromBytes(mutationMessage.getMessageBody(),
[jira] [Resolved] (CASSANDRA-3440) local writes timing out cause attempt to hint to self
[
https://issues.apache.org/jira/browse/CASSANDRA-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3440.
---
Resolution: Fixed
Updated to use this instead and committed:
{code}
. private static final MapInetAddress, AtomicInteger hintsInProgress = new
MapMaker().concurrencyLevel(1).makeComputingMap(new FunctionInetAddress,
AtomicInteger()
{
public AtomicInteger apply(InetAddress inetAddress)
{
return new AtomicInteger(0);
}
});
{code}
local writes timing out cause attempt to hint to self
-
Key: CASSANDRA-3440
URL: https://issues.apache.org/jira/browse/CASSANDRA-3440
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Labels: hintedhandoff
Fix For: 1.0.4
Attachments: 3440-v2.txt, 3440.txt
As reported by Ramash Natarajan on the mailing list:
{noformat}
We have a 8 node cassandra cluster running 1.0.1. After running a load
test for a day we are seeing this exception in system.log file.
ERROR [EXPIRING-MAP-TIMER-1] 2011-11-01 13:20:45,350
AbstractCassandraDaemon.java (line 133) Fatal exception in thread
Thread[EXPIRING-MAP-TIMER-1,5,main]
java.lang.AssertionError: /10.19.102.12
at
org.apache.cassandra.service.StorageProxy.scheduleLocalHint(StorageProxy.java:339)
at
org.apache.cassandra.net.MessagingService.scheduleMutationHint(MessagingService.java:201)
at
org.apache.cassandra.net.MessagingService.access$500(MessagingService.java:64)
at
org.apache.cassandra.net.MessagingService$2.apply(MessagingService.java:175)
at
org.apache.cassandra.net.MessagingService$2.apply(MessagingService.java:152)
at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:89)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
{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
svn commit: r1205971 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/io/sstable/ src/java/org/
Author: jbellis Date: Thu Nov 24 20:21:04 2011 New Revision: 1205971 URL: http://svn.apache.org/viewvc?rev=1205971view=rev Log: merge #3440 from 1.0 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java cassandra/trunk/src/java/org/apache/cassandra/db/RowMutation.java cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableReader.java cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java cassandra/trunk/src/java/org/apache/cassandra/service/RowRepairResolver.java cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java cassandra/trunk/src/java/org/apache/cassandra/tools/NodeCmd.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Nov 24 20:21:04 2011 @@ -4,7 +4,7 @@ /cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1198724,1198726-1205453 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 -/cassandra/branches/cassandra-1.0:1167085-1205476 +/cassandra/branches/cassandra-1.0:1167085-1205970 /cassandra/branches/cassandra-1.0.0:1167104-1167229,1167232-1181093,1181741,1181816,1181820,1182951,1183243 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /cassandra/tags/cassandra-0.8.0-rc1:1102511-1125020 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1205971r1=1205970r2=1205971view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Nov 24 20:21:04 2011 @@ -12,6 +12,9 @@ 1.0.4 + * fix self-hinting of timed out read repair updates and make hinted handoff + less prone to OOMing a coordinator (CASSANDRA-3440) + * expose bloom filter sizes via JMX (CASSANDRA-3495) * enforce RP tokens 0..2**127 (CASSANDRA-3501) * canonicalize paths exposed through JMX (CASSANDRA-3504) * fix liveSize stat when sstables are removed (CASSANDRA-3496) @@ -23,7 +26,6 @@ Merged from 0.8: * fix concurrence issue in the FailureDetector (CASSANDRA-3519) * fix array out of bounds error in counter shard removal (CASSANDRA-3514) -Merged from 0.8: * avoid dropping tombstones when they might still be needed to shadow data in a different sstable (CASSANDRA-2786) Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Nov 24 20:21:04 2011 @@ -4,7 +4,7 @@ /cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1198724,1198726-1205453 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 -/cassandra/branches/cassandra-1.0/contrib:1167085-1205476 +/cassandra/branches/cassandra-1.0/contrib:1167085-1205970 /cassandra/branches/cassandra-1.0.0/contrib:1167104-1167229,1167232-1181093,1181741,1181816,1181820,1182951,1183243 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /cassandra/tags/cassandra-0.8.0-rc1/contrib:1102511-1125020 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Nov 24 20:21:04 2011 @@ -4,7 +4,7 @@ /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1198724,1198726-1205453 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 -/cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1167085-1205476 +/cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1167085-1205970
[jira] [Created] (CASSANDRA-3529) ConcurrentModificationException in Table.all()
ConcurrentModificationException in Table.all()
--
Key: CASSANDRA-3529
URL: https://issues.apache.org/jira/browse/CASSANDRA-3529
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Trivial
Fix For: 1.0.4
{noformat}
[junit] java.util.ConcurrentModificationException
[junit] at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
[junit] at java.util.HashMap$KeyIterator.next(HashMap.java:828)
[junit] at
com.google.common.collect.Iterators$8.next(Iterators.java:750)
[junit] at
org.apache.cassandra.db.ColumnFamilyStore.all(ColumnFamilyStore.java:1509)
[junit] at
org.apache.cassandra.db.MeteredFlusher.countFlushingBytes(MeteredFlusher.java:118)
[junit] at
org.apache.cassandra.db.MeteredFlusher.run(MeteredFlusher.java:45)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
[junit] at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
[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)
{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] [Updated] (CASSANDRA-3529) ConcurrentModificationException in Table.all()
[
https://issues.apache.org/jira/browse/CASSANDRA-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3529:
--
Attachment: 3529.txt
Patch to make Schema.tables a concurrent map
ConcurrentModificationException in Table.all()
--
Key: CASSANDRA-3529
URL: https://issues.apache.org/jira/browse/CASSANDRA-3529
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Trivial
Fix For: 1.0.4
Attachments: 3529.txt
{noformat}
[junit] java.util.ConcurrentModificationException
[junit] at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
[junit] at java.util.HashMap$KeyIterator.next(HashMap.java:828)
[junit] at
com.google.common.collect.Iterators$8.next(Iterators.java:750)
[junit] at
org.apache.cassandra.db.ColumnFamilyStore.all(ColumnFamilyStore.java:1509)
[junit] at
org.apache.cassandra.db.MeteredFlusher.countFlushingBytes(MeteredFlusher.java:118)
[junit] at
org.apache.cassandra.db.MeteredFlusher.run(MeteredFlusher.java:45)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
[junit] at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
[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)
{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
svn commit: r1205977 - in /cassandra/branches/cassandra-1.0: CHANGES.txt src/java/org/apache/cassandra/config/Schema.java
Author: xedin
Date: Thu Nov 24 20:54:10 2011
New Revision: 1205977
URL: http://svn.apache.org/viewvc?rev=1205977view=rev
Log:
fix ConcurrentModificationException in Table.all()
patch by Jonathan Ellis; reviewed by Pavel Yaskevich for CASSANDRA-3529
Modified:
cassandra/branches/cassandra-1.0/CHANGES.txt
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/config/Schema.java
Modified: cassandra/branches/cassandra-1.0/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1205977r1=1205976r2=1205977view=diff
==
--- cassandra/branches/cassandra-1.0/CHANGES.txt (original)
+++ cassandra/branches/cassandra-1.0/CHANGES.txt Thu Nov 24 20:54:10 2011
@@ -15,7 +15,7 @@ Merged from 0.8:
* fix array out of bounds error in counter shard removal (CASSANDRA-3514)
* avoid dropping tombstones when they might still be needed to shadow
data in a different sstable (CASSANDRA-2786)
-
+ * fix ConcurrentModificationException in Table.all() (CASSANDRA-3529)
1.0.3
* revert name-based query defragmentation aka CASSANDRA-2503 (CASSANDRA-3491)
Modified:
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/config/Schema.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/config/Schema.java?rev=1205977r1=1205976r2=1205977view=diff
==
---
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/config/Schema.java
(original)
+++
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/config/Schema.java
Thu Nov 24 20:54:10 2011
@@ -49,13 +49,13 @@ public class Schema
private final AtomicInteger cfIdGen = new AtomicInteger(MIN_CF_ID);
/* metadata map for faster table lookup */
-private final MapString, KSMetaData tables;
+private final MapString, KSMetaData tables = new
NonBlockingHashMapString, KSMetaData();
/* Table objects, one per keyspace. Only one instance should ever exist
for any given keyspace. */
-private final MapString, Table tableInstances;
+private final MapString, Table tableInstances = new
NonBlockingHashMapString, Table();
/* metadata map for faster ColumnFamily lookup */
-private final BiMapPairString, String, Integer cfIdMap;
+private final BiMapPairString, String, Integer cfIdMap =
HashBiMap.create();
private volatile UUID version;
@@ -65,9 +65,6 @@ public class Schema
*/
public Schema(UUID initialVersion)
{
-tables = new HashMapString, KSMetaData();
-tableInstances = new NonBlockingHashMapString, Table();
-cfIdMap = HashBiMap.create();
version = initialVersion;
}
svn commit: r1205980 - /cassandra/branches/cassandra-1.0/CHANGES.txt
Author: jbellis Date: Thu Nov 24 21:10:35 2011 New Revision: 1205980 URL: http://svn.apache.org/viewvc?rev=1205980view=rev Log: update CHANGES Modified: cassandra/branches/cassandra-1.0/CHANGES.txt Modified: cassandra/branches/cassandra-1.0/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1205980r1=1205979r2=1205980view=diff == --- cassandra/branches/cassandra-1.0/CHANGES.txt (original) +++ cassandra/branches/cassandra-1.0/CHANGES.txt Thu Nov 24 21:10:35 2011 @@ -10,12 +10,13 @@ * add new upgradesstables nodetool command (CASSANDRA-3406) * skip --debug requirement to see common exceptions in CLI (CASSANDRA-3508) * fix incorrect query results due to invalid max timestamp (CASSANDRA-3510) + * fix ConcurrentModificationException in Table.all() (CASSANDRA-3529) Merged from 0.8: * fix concurrence issue in the FailureDetector (CASSANDRA-3519) * fix array out of bounds error in counter shard removal (CASSANDRA-3514) * avoid dropping tombstones when they might still be needed to shadow data in a different sstable (CASSANDRA-2786) - * fix ConcurrentModificationException in Table.all() (CASSANDRA-3529) + 1.0.3 * revert name-based query defragmentation aka CASSANDRA-2503 (CASSANDRA-3491)
[jira] [Updated] (CASSANDRA-3530) Header class not thread safe, but mutated by multiple threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Bridges updated CASSANDRA-3530: Attachment: CASSANDRA-3530.patch Patch makes Header nearly immutable. setDetails and removeDetails now return a copy of the Header with the modifications, rather than modifying the original. Header class not thread safe, but mutated by multiple threads - Key: CASSANDRA-3530 URL: https://issues.apache.org/jira/browse/CASSANDRA-3530 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.3 Reporter: Sean Bridges Attachments: CASSANDRA-3530.patch With Cassandra 1.0.3 we are getting exceptions like, Fatal exception in thread Thread[WRITE-/xx.xx.xx.xx,5,main]java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Unknown Source) at org.apache.cassandra.net.Header.serializedSize(Header.java:97) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) and, ERROR [WRITE-/xx.xx.xx.xx] 2011-11-24 22:08:28,981 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/10.30.12.79,5,main]java.lang.NullPointerException at org.apache.cassandra.net.Header.serializedSize(Header.java:101) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) It looks like Header is not thread safe, but the same header instance is modified concurrently while being sent to several threads in StorageProxy.sendMessages. This bug eventually causes the node to OOM, as it kills the OutboundTcpConnection thread, which means nothing is dequeing from queue. -- 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-3045) Update ColumnFamilyOutputFormat to use new bulkload API
[ https://issues.apache.org/jira/browse/CASSANDRA-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156971#comment-13156971 ] Jonathan Ellis commented on CASSANDRA-3045: --- I was going to test on Windows but it looks like 01 needs rebase for IncomingStreamReader. Update ColumnFamilyOutputFormat to use new bulkload API --- Key: CASSANDRA-3045 URL: https://issues.apache.org/jira/browse/CASSANDRA-3045 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: 0001-Remove-gossip-SS-requirement-from-BulkLoader.txt, 0002-Allow-DD-loading-without-yaml.txt, 0003-hadoop-output-support-for-bulk-loading.txt The bulk loading interface added in CASSANDRA-1278 is a great fit for Hadoop jobs. -- 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-3530) Header class not thread safe, but mutated by multiple threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156972#comment-13156972 ] Jonathan Ellis commented on CASSANDRA-3530: --- Are you running in a multi-DC environment? Header class not thread safe, but mutated by multiple threads - Key: CASSANDRA-3530 URL: https://issues.apache.org/jira/browse/CASSANDRA-3530 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.3 Reporter: Sean Bridges Attachments: CASSANDRA-3530.patch With Cassandra 1.0.3 we are getting exceptions like, Fatal exception in thread Thread[WRITE-/xx.xx.xx.xx,5,main]java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Unknown Source) at org.apache.cassandra.net.Header.serializedSize(Header.java:97) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) and, ERROR [WRITE-/xx.xx.xx.xx] 2011-11-24 22:08:28,981 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/10.30.12.79,5,main]java.lang.NullPointerException at org.apache.cassandra.net.Header.serializedSize(Header.java:101) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) It looks like Header is not thread safe, but the same header instance is modified concurrently while being sent to several threads in StorageProxy.sendMessages. This bug eventually causes the node to OOM, as it kills the OutboundTcpConnection thread, which means nothing is dequeing from queue. -- 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-3530) Header class not thread safe, but mutated by multiple threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156973#comment-13156973 ] Jonathan Ellis commented on CASSANDRA-3530: --- bq. Patch makes Header nearly immutable What are the changes in OutboundTcpConnection trying to do? Header class not thread safe, but mutated by multiple threads - Key: CASSANDRA-3530 URL: https://issues.apache.org/jira/browse/CASSANDRA-3530 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.3 Reporter: Sean Bridges Attachments: CASSANDRA-3530.patch With Cassandra 1.0.3 we are getting exceptions like, Fatal exception in thread Thread[WRITE-/xx.xx.xx.xx,5,main]java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Unknown Source) at org.apache.cassandra.net.Header.serializedSize(Header.java:97) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) and, ERROR [WRITE-/xx.xx.xx.xx] 2011-11-24 22:08:28,981 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/10.30.12.79,5,main]java.lang.NullPointerException at org.apache.cassandra.net.Header.serializedSize(Header.java:101) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) It looks like Header is not thread safe, but the same header instance is modified concurrently while being sent to several threads in StorageProxy.sendMessages. This bug eventually causes the node to OOM, as it kills the OutboundTcpConnection thread, which means nothing is dequeing from queue. -- 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-3511) Supercolumn key caches are not saved
[ https://issues.apache.org/jira/browse/CASSANDRA-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156976#comment-13156976 ] Radim Kolar commented on CASSANDRA-3511: I removed saved cache for this CF and restarted node. After restart it seems to work fine now. Supercolumn key caches are not saved Key: CASSANDRA-3511 URL: https://issues.apache.org/jira/browse/CASSANDRA-3511 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.2, 1.0.3 Reporter: Radim Kolar Priority: Minor Labels: supercolumns cache saving seems to be broken in 1.0.2 and 1.0.3 i have 2 CF in keyspace with enabled cache saving and only one gets its key cache saved. It worked perfectly in 0.8, both were saved. This one works: create column family query2 with column_type = 'Standard' and comparator = 'AsciiType' and default_validation_class = 'BytesType' and key_validation_class = 'UTF8Type' and rows_cached = 500.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 14400 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 5 and max_compaction_threshold = 10 and replicate_on_write = false and row_cache_provider = 'ConcurrentLinkedHashCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' This does not create column family dkb13 with column_type = 'Super' and comparator = 'LongType' and subcomparator = 'AsciiType' and default_validation_class = 'BytesType' and key_validation_class = 'UTF8Type' and rows_cached = 600.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 14400 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 5 and max_compaction_threshold = 10 and replicate_on_write = false and row_cache_provider = 'ConcurrentLinkedHashCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' in second test system i created these 2 column families and none of them got single cache key saved. Both have save period 30 seoonds - their cache should save often. Its not that standard column family works while super does not. create column family test1 with column_type = 'Standard' and comparator = 'BytesType' and default_validation_class = 'BytesType' and key_validation_class = 'BytesType' and rows_cached = 0.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 30 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and row_cache_provider = 'SerializingCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'; create column family test2 with column_type = 'Standard' and comparator = 'BytesType' and default_validation_class = 'BytesType' and key_validation_class = 'BytesType' and rows_cached = 0.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 30 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and row_cache_provider = 'SerializingCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'; If this is done on purpose for example cassandra 1.0 is doing some heuristic decision if cache should be saved or not then it should be removed. Saving cache is fast. -- 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-3530) Header class not thread safe, but mutated by multiple threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156980#comment-13156980 ] Sean Bridges commented on CASSANDRA-3530: - We are running in a multi dc environment. The changes in OutboundTcpConnection prevent the thread from dieing in case of a RuntimeException. When the thread dies the node eventually runs out of memory as the queue never gets emptied. Header class not thread safe, but mutated by multiple threads - Key: CASSANDRA-3530 URL: https://issues.apache.org/jira/browse/CASSANDRA-3530 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.3 Reporter: Sean Bridges Attachments: CASSANDRA-3530.patch With Cassandra 1.0.3 we are getting exceptions like, Fatal exception in thread Thread[WRITE-/xx.xx.xx.xx,5,main]java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Unknown Source) at org.apache.cassandra.net.Header.serializedSize(Header.java:97) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) and, ERROR [WRITE-/xx.xx.xx.xx] 2011-11-24 22:08:28,981 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/10.30.12.79,5,main]java.lang.NullPointerException at org.apache.cassandra.net.Header.serializedSize(Header.java:101) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) It looks like Header is not thread safe, but the same header instance is modified concurrently while being sent to several threads in StorageProxy.sendMessages. This bug eventually causes the node to OOM, as it kills the OutboundTcpConnection thread, which means nothing is dequeing from queue. -- 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-3521) sstableloader throwing exceptions when loading snapshot data from compressed CFs
[
https://issues.apache.org/jira/browse/CASSANDRA-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-3521:
--
Attachment: 3521.txt
Thanks for the detail, Peter.
Current version of sstableloader seems it does not pick up sstable's
compression info before start streaming, and that causes receiver node handle
streaming data incorrectly.
Attached patch let sstableloader to pick up compression information if
available.
sstableloader throwing exceptions when loading snapshot data from compressed
CFs
Key: CASSANDRA-3521
URL: https://issues.apache.org/jira/browse/CASSANDRA-3521
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: One node cluster (same problem with 4 nodes ) and
dedicated machine for sstable loader.
node and loader running jdk1.6.0_29 and cassandra-1.0.3
Reporter: Peter Velas
Assignee: Yuki Morishita
Labels: compression
Fix For: 1.0.4
Attachments: 3521.txt
Loaded data from snapshot then enabled `sstable_compression:
org.apache.cassandra.io.compress.SnappyCompressor`
Then flush, scrub and compact. I can see actual CompressionRatio in JMX
Console and access my data without problems..
Now I snapshot compressed keyspace and when trying to load snapshot to
another single node or different Keyspace (the same super CF structure with
compression options enabled, even try to truncate snapshoted CFs.) I cant
retrieve any records .
sstableloader command with debug mode dont throw any errors and shows its
streaming
{quote}
sstableloader-cassandra_2/bin/sstableloader --debug Impressions_compressed/
{quote}
Node logs contains repeating the errors bellow.
{quote}
ERROR [Thread-319] 2011-11-22 09:56:01,931 AbstractCassandraDaemon.java (line
133) Fatal exception in thread Thread[Thread-319,5,main]
java.lang.AssertionError: attempted to delete non-existing file
HidSaid-tmp-hb-260-Data.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:49)
at
org.apache.cassandra.streaming.IncomingStreamReader.retry(IncomingStreamReader.java:170)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:92)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:184)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:81)
INFO [Thread-320] 2011-11-22 09:56:02,492 StreamInSession.java (line 120)
Streaming of file Impressions_compressed/HidSaid-hb-9-Data.db sections=1
progress=0/5616749 - 0% from
org.apache.cassandra.streaming.StreamInSession@3cc62c07 failed: requesting a
retry.
ERROR [Thread-320] 2011-11-22 09:56:02,493 AbstractCassandraDaemon.java (line
133) Fatal exception in thread Thread[Thread-320,5,main]
java.lang.AssertionError: attempted to delete non-existing file
HidSaid-tmp-hb-261-Data.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:49)
at
org.apache.cassandra.streaming.IncomingStreamReader.retry(IncomingStreamReader.java:170)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:92)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:184)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:81)
{quote}
Hope its enough if you need more info just tell me what you need to reproduce
this bug.
--
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-3521) sstableloader throwing exceptions when loading snapshot data from compressed CFs
[
https://issues.apache.org/jira/browse/CASSANDRA-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3521:
--
Reviewer: slebresne
sstableloader throwing exceptions when loading snapshot data from compressed
CFs
Key: CASSANDRA-3521
URL: https://issues.apache.org/jira/browse/CASSANDRA-3521
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: One node cluster (same problem with 4 nodes ) and
dedicated machine for sstable loader.
node and loader running jdk1.6.0_29 and cassandra-1.0.3
Reporter: Peter Velas
Assignee: Yuki Morishita
Labels: compression
Fix For: 1.0.4
Attachments: 3521.txt
Loaded data from snapshot then enabled `sstable_compression:
org.apache.cassandra.io.compress.SnappyCompressor`
Then flush, scrub and compact. I can see actual CompressionRatio in JMX
Console and access my data without problems..
Now I snapshot compressed keyspace and when trying to load snapshot to
another single node or different Keyspace (the same super CF structure with
compression options enabled, even try to truncate snapshoted CFs.) I cant
retrieve any records .
sstableloader command with debug mode dont throw any errors and shows its
streaming
{quote}
sstableloader-cassandra_2/bin/sstableloader --debug Impressions_compressed/
{quote}
Node logs contains repeating the errors bellow.
{quote}
ERROR [Thread-319] 2011-11-22 09:56:01,931 AbstractCassandraDaemon.java (line
133) Fatal exception in thread Thread[Thread-319,5,main]
java.lang.AssertionError: attempted to delete non-existing file
HidSaid-tmp-hb-260-Data.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:49)
at
org.apache.cassandra.streaming.IncomingStreamReader.retry(IncomingStreamReader.java:170)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:92)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:184)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:81)
INFO [Thread-320] 2011-11-22 09:56:02,492 StreamInSession.java (line 120)
Streaming of file Impressions_compressed/HidSaid-hb-9-Data.db sections=1
progress=0/5616749 - 0% from
org.apache.cassandra.streaming.StreamInSession@3cc62c07 failed: requesting a
retry.
ERROR [Thread-320] 2011-11-22 09:56:02,493 AbstractCassandraDaemon.java (line
133) Fatal exception in thread Thread[Thread-320,5,main]
java.lang.AssertionError: attempted to delete non-existing file
HidSaid-tmp-hb-261-Data.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:49)
at
org.apache.cassandra.streaming.IncomingStreamReader.retry(IncomingStreamReader.java:170)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:92)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:184)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:81)
{quote}
Hope its enough if you need more info just tell me what you need to reproduce
this bug.
--
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-3530) Header class not thread safe, but mutated by multiple threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3530: -- Attachment: 3530-v2.txt v2 attached (against 1.0 branch): - simplifies OTC change to just catch Exception in existing try/catch in writeConnected - some style updates to Header/Message changes, but functionality is unchanged - updated StorageProxy to only need one header copy instead of the horribly inefficient process used previously Header class not thread safe, but mutated by multiple threads - Key: CASSANDRA-3530 URL: https://issues.apache.org/jira/browse/CASSANDRA-3530 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.3 Reporter: Sean Bridges Attachments: 3530-v2.txt, CASSANDRA-3530.patch With Cassandra 1.0.3 we are getting exceptions like, Fatal exception in thread Thread[WRITE-/xx.xx.xx.xx,5,main]java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Unknown Source) at org.apache.cassandra.net.Header.serializedSize(Header.java:97) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) and, ERROR [WRITE-/xx.xx.xx.xx] 2011-11-24 22:08:28,981 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/10.30.12.79,5,main]java.lang.NullPointerException at org.apache.cassandra.net.Header.serializedSize(Header.java:101) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) It looks like Header is not thread safe, but the same header instance is modified concurrently while being sent to several threads in StorageProxy.sendMessages. This bug eventually causes the node to OOM, as it kills the OutboundTcpConnection thread, which means nothing is dequeing from queue. -- 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-3530) Header class not thread safe, but mutated by multiple threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3530: -- Affects Version/s: (was: 1.0.3) 0.8.0 Fix Version/s: 1.0.4 0.8.8 This affects 0.8 as well (and would have affected 0.7 if not for CASSANDRA-3472). Header class not thread safe, but mutated by multiple threads - Key: CASSANDRA-3530 URL: https://issues.apache.org/jira/browse/CASSANDRA-3530 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Sean Bridges Fix For: 0.8.8, 1.0.4 Attachments: 3530-v2.txt, CASSANDRA-3530.patch With Cassandra 1.0.3 we are getting exceptions like, Fatal exception in thread Thread[WRITE-/xx.xx.xx.xx,5,main]java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Unknown Source) at org.apache.cassandra.net.Header.serializedSize(Header.java:97) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) and, ERROR [WRITE-/xx.xx.xx.xx] 2011-11-24 22:08:28,981 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/10.30.12.79,5,main]java.lang.NullPointerException at org.apache.cassandra.net.Header.serializedSize(Header.java:101) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) It looks like Header is not thread safe, but the same header instance is modified concurrently while being sent to several threads in StorageProxy.sendMessages. This bug eventually causes the node to OOM, as it kills the OutboundTcpConnection thread, which means nothing is dequeing from queue. -- 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-3530) Header class not thread safe, but mutated by multiple threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3530: -- Attachment: 3530-0.8.txt version of v2 for 0.8. Omitted the OTC change since in 0.8 it's just shoving a bytebuffer over the wire, there's not really any non-IOExceptions to worry about. Header class not thread safe, but mutated by multiple threads - Key: CASSANDRA-3530 URL: https://issues.apache.org/jira/browse/CASSANDRA-3530 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Sean Bridges Fix For: 0.8.8, 1.0.4 Attachments: 3530-0.8.txt, 3530-v2.txt, CASSANDRA-3530.patch With Cassandra 1.0.3 we are getting exceptions like, Fatal exception in thread Thread[WRITE-/xx.xx.xx.xx,5,main]java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Unknown Source) at org.apache.cassandra.net.Header.serializedSize(Header.java:97) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) and, ERROR [WRITE-/xx.xx.xx.xx] 2011-11-24 22:08:28,981 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/10.30.12.79,5,main]java.lang.NullPointerException at org.apache.cassandra.net.Header.serializedSize(Header.java:101) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) It looks like Header is not thread safe, but the same header instance is modified concurrently while being sent to several threads in StorageProxy.sendMessages. This bug eventually causes the node to OOM, as it kills the OutboundTcpConnection thread, which means nothing is dequeing from queue. -- 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
