Re: EXTERNAL: Re: Running Cassandra Server in an OSGi container
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
RE: EXTERNAL: Re: Running Cassandra Server in an OSGi container
Yes, the application includes the C* server and client. From: Robert Stupp [mailto:sn...@snazy.de] Sent: Wednesday, July 23, 2014 12:19 AM To: user@cassandra.apache.org Subject: Re: EXTERNAL: Re: Running Cassandra Server in an OSGi container You mean unzip and run of an application using C* ? Am 23.07.2014 um 00:34 schrieb Rodgers, Hugh hugh.rodg...@lmco.commailto: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.orgmailto: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.commailto: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
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
Re: Running Cassandra Server in an OSGi container
I can give you some tips. Figure out what Cassandra does when it starts up. Best way to do that is to read the startup script. Then all you have to do is convince the OSGI container to do what ever prep is done by the script. Trick to that is usually figuring out where to do it. For example if there are environment variables set in the script for Cassandra, you should add them to the script for your OSGI container. If there are any -D options, you would have to use what ever mechanism your OSGI container uses to pass them. There might be a properties file for example or there might be actual -D settings, depending. You should probably make your best guess as to where to put the configuration files but watch the logs for errors to this effect, e.g. ERROR: Doh! Can't find the config dir / file / etc. Of course, if the Cassandra libs aren't OSGI-ified you would have to do that also. Jim C. On 07/22/2014 01:19 PM, Robert Stupp wrote: 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 mailto: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: OpenPGP digital signature
Re: Running Cassandra Server in an OSGi container
BTW, I agree with other posters that it seems like an awfully weird thing to do. Perhaps you just want to run a client in an OSGI environment? Jim C. On 07/22/2014 02:39 PM, jcllings wrote: I can give you some tips. Figure out what Cassandra does when it starts up. Best way to do that is to read the startup script. Then all you have to do is convince the OSGI container to do what ever prep is done by the script. Trick to that is usually figuring out where to do it. For example if there are environment variables set in the script for Cassandra, you should add them to the script for your OSGI container. If there are any -D options, you would have to use what ever mechanism your OSGI container uses to pass them. There might be a properties file for example or there might be actual -D settings, depending. You should probably make your best guess as to where to put the configuration files but watch the logs for errors to this effect, e.g. ERROR: Doh! Can't find the config dir / file / etc. Of course, if the Cassandra libs aren't OSGI-ified you would have to do that also. Jim C. On 07/22/2014 01:19 PM, Robert Stupp wrote: What's your intention to do this? signature.asc Description: OpenPGP digital signature
RE: EXTERNAL: Re: Running Cassandra Server in an OSGi container
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.commailto: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
