cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branimir Lambov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10202) simplify CommitLogSegmentManager
Date Wed, 15 Jun 2016 09:49:09 GMT

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

Branimir Lambov commented on CASSANDRA-10202:
---------------------------------------------

It does have an elegance and is inherently simpler than the previous approach once we consider
the complexities that one hides, but I agree that it is not as easy to follow. The expected
benefit isn't that high either.

Since we have more than one vote against them, I will revert Benedict's changes and rebase.


bq. Why is the replay limit stuff necessary? Seems like it replays everything since the limit
is set to be higher then anything that is available.

Yes, but we also start the allocation thread which can create a segment and stall before listing
it among the managed, causing a replay failure which happened way to often during tests. These
changes are already committed as CASSANDRA-11743 and will not be present in the rebased version.

> simplify CommitLogSegmentManager
> --------------------------------
>
>                 Key: CASSANDRA-10202
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10202
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Local Write-Read Paths
>            Reporter: Jonathan Ellis
>            Assignee: Branimir Lambov
>            Priority: Minor
>
> Now that we only keep one active segment around we can simplify this from the old recycling
design.



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

Mime
View raw message