cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8399) Reference Counter exception when dropping user type
Date Tue, 30 Dec 2014 12:00:27 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14261044#comment-14261044
] 

Benedict commented on CASSANDRA-8399:
-------------------------------------

Ah. I now see that CASSANDRA-8019 was the source of these woes, which was itself triggered
by CASSANDRA-7932. I didn't have the context. It looks to me like the underlying problem is
that the set of "iscompacting" can be disjoint from the set of "isreferenced", and we should
ensure it is always a subset. What I mean by this is that if an sstable is marked compacting,
it should not be possible for it to be considered unreferenced. So I propose always acquiring
a reference prior to successfully marking compacting, and releasing on unmarking. 

To relate to what you were saying about multiple concepts: we actually have three right now,
not two, and two of these are extremely similar. By making one of the two similar concepts
a subset of the other, we reduce the potential for mistakes. I have no doubt the 7932 mistake
was down to my belief that a reference was maintained by AbstractCompactionTask, when in fact
it is only the iscompacting state.

> Reference Counter exception when dropping user type
> ---------------------------------------------------
>
>                 Key: CASSANDRA-8399
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8399
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Philip Thompson
>            Assignee: Joshua McKenzie
>             Fix For: 2.1.3
>
>         Attachments: 8399_fix_empty_results.txt, 8399_v2.txt, node2.log, ubuntu-8399.log
>
>
> When running the dtest {{user_types_test.py:TestUserTypes.test_type_keyspace_permission_isolation}}
with the current 2.1-HEAD code, very frequently, but not always, when dropping a type, the
following exception is seen:{code}
> ERROR [MigrationStage:1] 2014-12-01 13:54:54,824 CassandraDaemon.java:170 - Exception
in thread Thread[MigrationStage:1,5,main]
> java.lang.AssertionError: Reference counter -1 for /var/folders/v3/z4wf_34n1q506_xjdy49gb780000gn/T/dtest-eW2RXj/test/node2/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-sche
> ma_keyspaces-ka-14-Data.db
>         at org.apache.cassandra.io.sstable.SSTableReader.releaseReference(SSTableReader.java:1662)
~[main/:na]
>         at org.apache.cassandra.io.sstable.SSTableScanner.close(SSTableScanner.java:164)
~[main/:na]
>         at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:62) ~[main/:na]
>         at org.apache.cassandra.db.ColumnFamilyStore$8.close(ColumnFamilyStore.java:1943)
~[main/:na]
>         at org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:2116)
~[main/:na]
>         at org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:2029)
~[main/:na]
>         at org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1963)
~[main/:na]
>         at org.apache.cassandra.db.SystemKeyspace.serializedSchema(SystemKeyspace.java:744)
~[main/:na]
>         at org.apache.cassandra.db.SystemKeyspace.serializedSchema(SystemKeyspace.java:731)
~[main/:na]
>         at org.apache.cassandra.config.Schema.updateVersion(Schema.java:374) ~[main/:na]
>         at org.apache.cassandra.config.Schema.updateVersionAndAnnounce(Schema.java:399)
~[main/:na]
>         at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:167) ~[main/:na]
>         at org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:49)
~[main/:na]
>         at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) ~[main/:na]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_67]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_67]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_67]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_67]
>         at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]{code}
> Log of the node with the error is attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message