[
https://issues.apache.org/jira/browse/CASSANDRA-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860656#action_12860656
]
Jeff Hodges edited comment on CASSANDRA-1016 at 4/25/10 1:38 AM:
-----------------------------------------------------------------
Named them Callbacks. WriteCallbacks, specifically.
This is a 0.01 implementation of them. The ArrayList of WriteCallbacks is
called before writing is done (and WriteCallback#beforeWrite(RowMutation,
Table) is called on it) and after (where WriteCallback#afterWrite(RowMutation,
Table) is called).
This does no filtering so even system table writes will be caught by it.
A singleton DatabaseDescriptor.callbackRunner is created and used.
No effort into making an easy API for new Message creation has been made (i.e.
make it easy to send out writes to the cluster).
No effort has been made to avoid slowdowns in the write path.
ThreadPoolExecutors would probably be a good idea. The CallbackRunner is a good
place to put such work.
It would probably be preferable that the WriteCallback and CallbackRunner were
in a package other than org.apache.cassandra.db. This will have to be evaluated
as we add features and other classes.
The WriteCallback class is just a simple class. It probably should be an
interface. I have concern about that because we assume that the default no-args
constructor works correctly when we load them from the config file.
was (Author: jmhodges):
Named them Callbacks. WriteCallbacks, specifically.
This is a 0.01 implementation of them. The ArrayList of WriteCallbacks is
called before writing is done (and WriteCallback#beforeWrite(RowMutation,
Table) is called on it) and after (where WriteCallback#afterWrite(RowMutation,
Table) is called).
This does no filtering so even system table writes will be caught by it.
A singleton DatabaseDescriptor.callbackRunner is created and used.
No effort into making an easy API for new Message creation has been made (i.e.
make it easy to send out writes to the cluster).
No effort has been made to avoid slowdowns in the write path.
ThreadExecutorPools would probably be a good idea. The CallbackRunner is a good
place to put such work.
It would probably be preferable that the WriteCallback and CallbackRunner were
in a package other than org.apache.cassandra.db. This will have to be evaluated
as we add features and other classes.
The WriteCallback class is just a simple class. It probably should be an
interface. I have concern about that because we assume that the default no-args
constructor works correctly when we load them from the config file.
> Coprocessors
> ------------
>
> Key: CASSANDRA-1016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1016
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Ryan King
> Attachments: 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.
