----- Original Message -----
I have previously mentioned that I am not inclined to pursue embedding cassandra in large part because I have read that it is discourage for production environments. Cassandra like other server applications uses a lot of resources, e.g., threads, memory, etc. cassandra would be competing for those resources with the RHQ server. Either or both cassandra and the RHQ server would likely suffer in performance. cassandra uses default garbage collector settings that are tuned for its caching, and those settings may not be optimal for RHQ, and settings we use for RHQ might not optimal for cassandra.
The other issue with embedding is that we do want to support stand alone, non-embedded nodes. For users that need the scalability and are collecting a high volume of metrics, they are going to want stand alone nodes that are not competing for resources with another application in the same JVM. So if we have both embedded and stand alone, we have two deployment models to support. I prefer to stick with one, at least for now.
+1 For example this embedded+standalone model has not worked out well for us with the agent
I have briefly talked about adding hooks. CassandraDaemon is the entry point for cassandra. It defines the main method that is invoked when you start a node. It is designed to be extensible. I have already mentioned that I think we will want to extend CassandraDaemon for a few reasons. I suppose this might be considered an embedded solution.
On Sep 26, 2012, at 10:26 AM, Lukas Krejci lkrejci@redhat.com wrote:
On Wednesday, September 26, 2012 10:15:12 Simeon Pinder wrote: <... snip ... >
Any reason why we can't do both? For production installations, we add an optional installation step that provisions a Cassandra node on a remote box.
I think this is exactly the problem that John describes. It's a chicken-and- egg problem (if you want to have Cassandra provisioned by our provisioning subsystem).
If we have to implement a way of provisioning cassandra at installation time (i.e. WITHOUT an actual RHQ server running and offering its services) then we might just use that always and not bother with bundles for cassandra provisioning.
For dev mode and non-production installs we prepare to embed a Cassandra server but have the startup code check for an existing Cassandra node indicated by some server property, before defaulting to the embedded Cassandra node. Probably want to disable the startup check after you've chosen local or remote so you don't have the primary metric store node flip-flopping locations after install. Either way before startup you have your Cassandra node.
<... snip ...>
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel