[
https://issues.apache.org/jira/browse/CASSANDRA-18840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811196#comment-17811196
]
Jacek Lewandowski commented on CASSANDRA-18840:
-----------------------------------------------
The issue is the assertion - it is unnecessary, actually - it is too early.
The aborted streams are closed in the later step in the streaming session, so
the fix is just to remove the assertion + provide a test case that verifies all
references are eventually released.
*Explanation*
We open {{{}SSTableReader{}}}, and we get additional references to it for each
{{{}CassandraOutgoingFile{}}}. In that method with assertion, we close only the
primary {{SSTableReader}} reference, assuming all the remaining
{{CassandraOutgoingFile}} were already closed. This is the case when everything
is completed correctly.
However, when it doesn't, the remaining {{CassandraOugoingFile}} objects are
closed around [this
place|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/streaming/StreamSession.java#L557]:
{code:java}
StreamSession.java
logger.debug("[Stream #{}] Will close attached inbound
{} and outbound {} channels", planId(), inbound, outbound);
{code}
While the method with the assertion is called earlier, concretely
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/streaming/StreamSession.java#L545]:
{code:java}
StreamSession.java
streamResult.handleSessionComplete(this);
{code}
That's why the references are released regardless of that assertion anyway.
> Leakage of references to SSTable on unsuccessful operations
> -----------------------------------------------------------
>
> Key: CASSANDRA-18840
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18840
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
> Reporter: Stefan Miklosovic
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 5.0, 5.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is a little bit tricky to describe correctly as I can talk about the
> symptoms only. I hit this issue when testing CASSANDRA-18781.
> In a nutshell, when we go to bulkload an SSTable, it opens it in
> SSTableLoader. If bulkloading fails on server side and exception is
> propagated to the client, on releasing of references, it fails on this assert
> (1). This practically means that we are leaking resources as something still
> references that SSTable but it was not tidied up (on failure). On a happy
> path, it is all de-referenced correctly.
> I think that this might have implications beyond SSTable loading, e.g. this
> could happen upon streaming too.
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java#L245
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
