You mean "unzip and run" of an application using C* ? Am 23.07.2014 um 00:34 schrieb Rodgers, Hugh <hugh.rodg...@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:sn...@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.rodg...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
