Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 130E211C8E for ; Tue, 22 Jul 2014 22:35:30 +0000 (UTC) Received: (qmail 81609 invoked by uid 500); 22 Jul 2014 22:35:26 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 81563 invoked by uid 500); 22 Jul 2014 22:35:26 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 81553 invoked by uid 99); 22 Jul 2014 22:35:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jul 2014 22:35:26 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hugh.rodgers@lmco.com designates 192.31.106.12 as permitted sender) Received: from [192.31.106.12] (HELO mailfo01.lmco.com) (192.31.106.12) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jul 2014 22:35:20 +0000 Received: from HDXHTPN10.us.lmco.com (hdxhtpn10.ems.lmco.com [158.188.83.20]) by mailfo01.lmco.com (8.14.5/8.14.5) with ESMTP id s6MMXt6f028928 for ; Tue, 22 Jul 2014 23:34:57 +0100 Received: from HDXDSP34.us.lmco.com ([fe80::7c63:1fe2:cc00:2c11]) by HDXHTPN10.us.lmco.com ([fe80::cc18:d817:48d2:b2b0%15]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 16:34:14 -0600 From: "Rodgers, Hugh" To: "user@cassandra.apache.org" Subject: RE: EXTERNAL: Re: Running Cassandra Server in an OSGi container Thread-Topic: EXTERNAL: Re: Running Cassandra Server in an OSGi container Thread-Index: Ac+l5IzHNoBSeHJPQj+HSBJ/iWvjqwAN+vWAAAfzFtA= Date: Tue, 22 Jul 2014 22:34:14 +0000 Message-ID: References: <62EF6B87-6A9E-4BC5-BF93-0B73391E5A0C@snazy.de> In-Reply-To: <62EF6B87-6A9E-4BC5-BF93-0B73391E5A0C@snazy.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.188.95.3] Content-Type: multipart/alternative; boundary="_000_ED2B0001624B384CA15B8BECC6885788380B92A5HDXDSP34uslmcoc_" MIME-Version: 1.0 X-LM-Outbound: External 158.188.83.20 cntry=us g=f7c1d23af1cf624fed2d03c3d074d112 q=s6MMXt6f028928 m=12 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-07-22_07:2014-07-22,2014-07-22,1970-01-01 signatures=0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_ED2B0001624B384CA15B8BECC6885788380B92A5HDXDSP34uslmcoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 th= ough, 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 preven= ted proper shutdown has been closed for C* 2.1-rc1: https://issues.apache.o= rg/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 pro= duction environment. Not just because of the few System.exit calls in CassandraDaemon but also o= f 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 resou= rces on multiple servers using commodity hardware without any virtualizatio= n 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 al= ways a separate OS process on C* nodes. Examples are Hadoop and Spark. Am 22.07.2014 um 21:45 schrieb Rodgers, Hugh >: Hello - I have a use case where I need to run the Cassandra Server as an OSGi bundl= e. I have been able to embed all of the Cassandra dependencies in an OSGi b= undle 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 wi= ll bring down my entire OSGi container rather than just the bundle Cassandr= a 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 StorageSer= vice is not "aware" of it, i.e., I cannot call the StorageService.registerD= aemon(...) method because my copy of CassandraDaemon does not extend Apache= 's. hence I am getting exceptions when I do shutdown my container or restar= t the bundle because the StorageService and my CassandraDaemon are not "lin= ked". I am considering trying to extend Apache's CassandraDaemon and override its= setup() method with a SecurityManager that disables System.exit() calls. T= his 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 --_000_ED2B0001624B384CA15B8BECC6885788380B92A5HDXDSP34uslmcoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What got our team on the = path of trying to embed C* was the wiki page http://wiki.apache.o= rg/cassandra/Embedding which implies this can be done. Also WSO2 Carbon= and Achilles have both embedded C* (not in an OSGi container though, and C= arbon is with an older C* version).

 <= /p>

We are wanting an “= unzip and run” system and do not expect the user to have to do much, = if any, C* configuration.

 <= /p>

From: Robert S= tupp [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:&= nbsp;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 Cas= sandraDaemon but also of the other places where System.exit is called for v= ery good reasons. These reasons include system/node failure scenarios (for = example disk failures).

 

C* is designed to run in its own JVM process using d= edicated hardware resources on multiple servers using commodity hardware wi= thout any virtualization or any shared storage. And it just works great wit= h that.

 

There are good reasons to move computation near to t= he 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 t= he 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&= #8221; 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 Cassandr= aDaemon are not “linked”.

 

I am considering trying to extend Apach= e’s CassandraDaemon and override its setup() method with a SecurityMa= nager 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 curr= ently using CQL (vs. Thrift).

 

Thanks –

 

Hugh

 

--_000_ED2B0001624B384CA15B8BECC6885788380B92A5HDXDSP34uslmcoc_--