cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-1311) Triggers
Date Mon, 12 Nov 2012 10:33:21 GMT

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

Vijay edited comment on CASSANDRA-1311 at 11/12/12 10:31 AM:
-------------------------------------------------------------

I pushed the initial version of triggers to https://github.com/Vijay2win/cassandra/tree/1311
for a review...

* User can implement Itriggers and drop the jar into $CASSANDRA_HOME/triggers
* Patch implements a custom Class loader, which will load the classes in an order, it first
looks for the trigger classes in triggers Directory and if it cannot find the required classes
needed to complete the the operation (iTrigger.agument) it looks for the class in the parent
Class loader.
** This buys us 2 things, user can drop all his dependencies in the directory (kind of sandboxed).
** Every time we want to load a new jar, a new CustomCL will be loaded and the old one is
left for GC (So classes associated with the old CL can be freed up).
** This should help a bit in avoiding OOM in the perm gen.
* Batches with both RowMutations and Counters will throw an exception, because the MutateAtomic
is not allowed on counters anyways...
* Currently there is a JMX to load the new jars and we also watch triggers directory every
minute to looking for new JAR's, I am inclined to removing the watch part for safety and let
the user call the JMX to reload the jar's.

TODO: Need to write more test cases.... Working on it.
                
      was (Author: vijay2win@yahoo.com):
    I pushed the initial version of triggers to https://github.com/Vijay2win/cassandra/tree/1311
for a review...

* User can implement Itriggers and drop the jar into $CASSANDRA_HOME/triggers
* Patch implements a custom Class loader, which will load the classes in an order, it first
looks for the trigger classes in triggers Directory and if it cannot find the required classes
needed to complete the the operation (iTrigger.agument) it looks for the class in the parent
Class loader.
** This buys us 2 things, user can drop all his dependencies in the directory (kind of sandboxed).
** Every time we want to load a new jar, a new CustomCL will be loaded and the old one is
left for GC (So classes associated with the old CL can be freed up).
** This should help a bit in avoiding OOM in the perm gen.
* Batches with contains both batches and Counters will throw an exception, because the MutateAtomic
is not allowed on counters anyways...
* Currently there is a JMX to load the new jars and we also watch triggers directory every
minute to looking for new JAR's, I am inclined to removing the watch part for safety and let
the user call the JMX.

TODO: Need to write more test cases.... Working on it.
                  
> Triggers
> --------
>
>                 Key: CASSANDRA-1311
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Maxim Grinev
>            Assignee: Vijay
>             Fix For: 1.3
>
>         Attachments: HOWTO-PatchAndRunTriggerExample.txt, HOWTO-PatchAndRunTriggerExample-update1.txt,
ImplementationDetails.pdf, ImplementationDetails-update1.pdf, trunk-967053.txt, trunk-984391-update1.txt,
trunk-984391-update2.txt
>
>
> Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous
execution of application code at database side. For example to support indexes and materialized
views, online analytics, push-based data propagation.
> Please find the motivation, triggers description and list of applications:
> http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
> An example of using triggers for indexing:
> http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/
> Implementation details are attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message