Support for forking the Cassandra application into a separate VM
----------------------------------------------------------------
Key: AMDATUCASSANDRA-117
URL: http://jira.amdatu.org/jira/browse/AMDATUCASSANDRA-117
Project: Amdatu Cassandra
Issue Type: New Feature
Components: Cassandra daemon
Reporter: Bram de Kruijff
Cassandra by design does not behave well in an OSGi environment. As discussed
in the mailing list (see [0]) we should look into spawning it in a seperate VM.
{quote}
Pros:
1) Amdatu Cassandra can not handle the service lifecycle or
configuration updates properly (and thus is not provisionable).
Forking a private VM and controlling that from the service lifecycle
solves this.
2) Amdatu Cassandra needs an agent which appears not desirable in an
AMA. Forking a private VM and controlling that from the service
lifecycle solves this.
3) Amdatu Cassandra has specific memory and gc requirements for
optimal performance. Forking a private VM means decouple memory and GC
that you can optimize.
4) Amdatu Cassandra currenlty system exits the entire AMA in case of
for example a configuration problem. Forking a private VM and
controlling that from the service lifecycle solves this.
Cons:
1) Forking a private VM means 2 Xms/Xmx heaps possibly causing higher
ram requirements for small systems.
2) Forking a private VM means you need to monitor it and account for
ghosts after an ama crash.
3) Forking a VM means you need a known VM on the AMA node or
provisision it yourself.
{quote}
[0] http://www.mail-archive.com/[email protected]/msg05288.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://jira.amdatu.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
