cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Stupp <sn...@snazy.de>
Subject Re: EXTERNAL: Re: Running Cassandra Server in an OSGi container
Date Wed, 23 Jul 2014 07:18:31 GMT
You mean "unzip and run" of an application using C* ?

Am 23.07.2014 um 00:34 schrieb Rodgers, Hugh <hugh.rodgers@lmco.com>:

> What got our team on the path of trying to embed C* was the wiki page http://wiki.apache.org/cassandra/Embedding
which implies this can be done. Also WSO2 Carbon and Achilles have both embedded C* (not in
an OSGi container though, and Carbon is with an older C* version).
>  
> We are wanting an “unzip and run” system and do not expect the user to have to do
much, if any, C* configuration.
>  
> From: Robert Stupp [mailto:snazy@snazy.de] 
> Sent: Tuesday, July 22, 2014 1:19 PM
> To: user@cassandra.apache.org
> Subject: EXTERNAL: Re: Running Cassandra Server in an OSGi container
>  
> What's your intention to do this?
>  
> There are unit test integrations using C* daemon. A related bug that prevented proper
shutdown has been closed for C* 2.1-rc1: https://issues.apache.org/jira/browse/CASSANDRA-5635
> It's perfectly fine to embed C* for unit tests.
>  
> But I'd definitely not recommend to use C* within a container in a real production environment.
> Not just because of the few System.exit calls in CassandraDaemon but also of the other
places where System.exit is called for very good reasons. These reasons include system/node
failure scenarios (for example disk failures).
>  
> C* is designed to run in its own JVM process using dedicated hardware resources on multiple
servers using commodity hardware without any virtualization or any shared storage. And it
just works great with that.
>  
> There are good reasons to move computation near to the data - but that's always a separate
OS process on C* nodes. Examples are Hadoop and Spark.
>  
> Am 22.07.2014 um 21:45 schrieb Rodgers, Hugh <hugh.rodgers@lmco.com>:
> 
> 
> Hello –
>  
> I have a use case where I need to run the Cassandra Server as an OSGi bundle. I have
been able to embed all of the Cassandra dependencies in an OSGi bundle and run it on Karaf
container, but I am not happy with the approach I have thus far.
>  
> Since CassandraDaemon has System.exit() calls in it, if these execute it will bring down
my entire OSGi container rather than just the bundle Cassandra is running in. I hacked up
a copy of CassandraDaemon enough to get it to run in the bundle with no System.exit() calls,
but the Cassandra StorageService is not “aware” of it, i.e., I cannot call the StorageService.registerDaemon(…)
method because my copy of CassandraDaemon does not extend Apache’s. hence I am getting exceptions
when I do shutdown my container or restart the bundle because the StorageService and my CassandraDaemon
are not “linked”.
>  
> I am considering trying to extend Apache’s CassandraDaemon and override its setup()
method with a SecurityManager that disables System.exit() calls. This too sounds “hacky”.
>  
> Does anyone have any better suggestions? Or know of an existing open source project that
has successfully embedded CassandraServer in an OSGi bundle?
>  
> I am using Cassandra v2.0.7 and am currently using CQL (vs. Thrift).
>  
> Thanks –
>  
> Hugh


Mime
View raw message