cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Hodges (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-1016) Coprocessors
Date Sun, 25 Apr 2010 05:38:50 GMT

    [ 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.


Mime
View raw message