[
https://issues.apache.org/jira/browse/CASSANDRA-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873368#action_12873368
]
Jeff Hodges commented on CASSANDRA-1016:
----------------------------------------
The assumption that we want to drop anything coming into a overloaded Plugin
TPE is probably sound, but I am writing this comment solely to spark discussion
about it if others think not.
I certainly think that using a caller-runs policy for it is a bad idea. I would
prefer not to slow down the write path on a Plugin overload, and drop data
instead. We're all going to have to run consistency checking programs for these
kinds of things, anyhow.
Of course, I would accept patches that make it configurable.
> Plugins
> -------
>
> Key: CASSANDRA-1016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1016
> Project: Cassandra
> Issue Type: New Feature
> Affects Versions: 0.6.1
> Reporter: Ryan King
> Assignee: Jeff Hodges
> Attachments: CASSANDRA-1016-2.patch, CASSANDRA-1016.patch
>
>
> As discussed at the Digg-hosted hackathon.
> First off, this needs a better name, the idea isn't exactly like coprocessors
> from BigTable and this entry should be considered a stub for now (Stu and
> Marius should be able to provide more details).
> The idea is that for mutation operations, we should all the user to run a
> routine that has access to the "old" version of the data and the "new"
> version, and can take action.
> At a bare minimum, this should be capable of implementing distributed
> secondary indexes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
