cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-10688) Stack overflow from SSTableReader$InstanceTidier.runOnClose in Leak Detector
Date Tue, 05 Jan 2016 16:53:40 GMT

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

Benedict edited comment on CASSANDRA-10688 at 1/5/16 4:53 PM:
--------------------------------------------------------------

I'm not at all opposed to making the search iterative, but I think a simpler/complementary
solution (that also improves the running time) is to detect collections/maps and to iterate
over them instead of walk the linked-list.  This also prevents pollution of the visited set.

I'm not sure I would constrain the visited set to as few as 100K items, though, or even 1M.
 This is a debug feature to ensure we haven't introduced dangerous bugs, and it will simply
stop exploring silently and deterministically on certain criteria that might mask those bugs.
 If we're bounding the visited set we should probably constrain it only to those items in
our path, so we no longer save time but still detect loops.


was (Author: benedict):
I'm not at all opposed to making the search iterative, but I think a simpler solution (that
also improves the running time) is to detect collections/maps and to iterate over them instead
of walk the linked-list.  This also prevents pollution of the visited set.

I'm not sure I would constrain the visited set to as few as 100K items, though, or even 1M.
 This is a debug feature to ensure we haven't introduced dangerous bugs, and it will simply
stop exploring silently and deterministically on certain criteria that might mask those bugs.
 If we're bounding the visited set we should probably constrain it only to those items in
our path, so we no longer save time but still detect loops.

> Stack overflow from SSTableReader$InstanceTidier.runOnClose in Leak Detector
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-10688
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10688
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local Write-Read Paths, Testing
>            Reporter: Jeremiah Jordan
>            Assignee: Ariel Weisberg
>             Fix For: 3.0.x
>
>
> Running some tests against cassandra-3.0 9fc957cf3097e54ccd72e51b2d0650dc3e83eae0
> The tests are just running cassandra-stress write and read while adding and removing
nodes from the cluster.  After the test runs when I go back through logs I find the following
Stackoverflow fairly often:
> ERROR [Strong-Reference-Leak-Detector:1] 2015-11-11 00:04:10,638  Ref.java:413 - Stackoverflow
[private java.lang.Runnable org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier.runOnClose,
final java.lang.Runnable org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache.andThen,
final org.apache.cassandra.cache.InstrumentingCache org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys.cache,
private final org.apache.cassandra.cache.ICache org.apache.cassandra.cache.InstrumentingCache.map,
private final com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap org.apache.cassandra.cache.ConcurrentLinkedHashCache.map,
final com.googlecode.concurrentlinkedhashmap.LinkedDeque com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap.evictionDeque,
com.googlecode.concurrentlinkedhashmap.Linked com.googlecode.concurrentlinkedhashmap.LinkedDeque.first,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node 
> ....... (repeated a whole bunch more) .... 
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.next,
final java.lang.Object com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$Node.key,
public final byte[] org.apache.cassandra.cache.KeyCacheKey.key



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

Mime
View raw message