Am 14.01.2015 um 17:30 schrieb Heiko Braun
<ike.braun(a)googlemail.com>:
>>> 1b) like the above, but if people are happy to accept longer startup, it is
using an embedded C*
>>> server that follows the WildFly lifecycle
>>>
>>
>> yes, that’s what the cassandra subsystem does (talking about the subsystem,not
the rhq C* EAR deployment)
>
> After some investigation last week and some helpful explanations and demos from mazz,
I better understand that the cassandra subsystem is the best, most appropriate way to
embed Cassandra. It has not been clear whether or not embedding Cassandra would be a
viable deployment option. If it is, then I think we should get rid of the C* EAR
deployment and start focusing more on the subsystem.
The reason for the dependency on C* master (v3.0) are some patches that we did to support
the embedded execution. The version used within the EAR (v2.x) terminates the VM when
invalid configurations are detected (using System.exit())
I would recommend using C* master, unless there are good reason not to (i.e. CQL
incompatibilities, unclear roadmap, etc)
The main driver for memory backend was the (added) startup time of Cassandra vs. memory.
When Wildfly itself starts in 3-4 seconds, adding 2-3 more for C* seems pretty odd. My
understanding is/has been
that people do not want to take this hit.
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters