[
https://issues.apache.org/jira/browse/CASSANDRA-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046199#comment-13046199
]
Alan Liang edited comment on CASSANDRA-1610 at 6/8/11 9:10 PM:
---------------------------------------------------------------
bq. I think Ben's selection of methods for the CompactionStrategy is an
improvement, but I do like having an abstract class so it's obvious what the
contract is for us vs having to inject parameters post-construction.
I agree, I'll go back to the Abstract class approach.
bq. I'd like to move away from minor/major terms as too tied to the old
compaction internals. Perhaps background/maximal instead?
Sounds good to me.
bq. We should also make user defined compactions part of ACS – for some
strategies (e.g. leveldb) we want to be able to reject user requests that would
break strategy invariants. Note that this should probably return a single Task,
rather than a list. ("Maximal" will also usually return a single task, but it's
cleaner to represent "nothing to do" as an empty list, than as null.)
Sounds good to me.
bq. handleInsufficientSpaceForCompaction is a bad encapsulation; it means both
it and its caller have to deal with "find a place for an sstable." suggest
leaving it up to CT.execute to deal with.
Sounds good to me. So if a strategy wants to customize the behavior of handling
insufficient space, they'd have to implement their own CompactionTask (or
override the existing one). What do you think about that? Another thing is...
since space is always a race condition, I could leave it up to the strategy to
ensure the sstable it has selected has a reasonable amount of space for
compaction.
I'll resubmit a patch with all these suggestions. Thanks!
was (Author: alanliang):
bq. I think Ben's selection of methods for the CompactionStrategy is an
improvement, but I do like having an abstract class so it's obvious what the
contract is for us vs having to inject parameters post-construction.
I agree, I'll go back to the Abstract class approach.
bq. I'd like to move away from minor/major terms as too tied to the old
compaction internals. Perhaps background/maximal instead?
Sounds good to me.
bq. We should also make user defined compactions part of ACS – for some
strategies (e.g. leveldb) we want to be able to reject user requests that would
break strategy invariants. Note that this should probably return a single Task,
rather than a list. ("Maximal" will also usually return a single task, but it's
cleaner to represent "nothing to do" as an empty list, than as null.)
Sounds good to me.
bq. handleInsufficientSpaceForCompaction is a bad encapsulation; it means both
it and its caller have to deal with "find a place for an sstable." suggest
leaving it up to CT.execute to deal with.
Sounds good to me.
I'll resubmit a patch with all these suggestions. Thanks!
> Pluggable Compaction
> --------------------
>
> Key: CASSANDRA-1610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1610
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Assignee: Alan Liang
> Priority: Minor
> Labels: compaction
> Fix For: 1.0
>
> Attachments: 0001-move-compaction-code-into-own-package.patch,
> 0001-move-compaction-code-into-own-package.patch,
> 0001-move-compaction-code-into-own-package.patch,
> 0001-move-compaction-code-into-own-package.patch,
> 0001-move-compaction-code-into-own-package.patch,
> 0001-move-compaction-code-into-own-package.patch,
> 0001-pluggable-compaction.patch,
> 0002-Pluggable-Compaction-and-Expiration.patch,
> 0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch,
> 0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch,
> 0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch,
> 0002-pluggable-compaction.patch
>
>
> In CASSANDRA-1608, I proposed some changes on how compaction works. I think
> it also makes sense to allow the ability to have pluggable compaction per CF.
> There could be many types of workloads where this makes sense. One example we
> had at Digg was to completely throw away certain SSTables after N days.
> This ticket addresses making compaction pluggable only.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
