Re: Exclude a host from the repair process

[Stone Fang]

dont think it is necessary to remove the down node.
the repair will continue comparing with other up node.ignore the down node.

On Wed, Jul 13, 2016 at 9:44 PM, Jean Carlo 
wrote:

> If a node is down in my cluster.
>
> Is it possible to exclude him from the repair process in order to continue
> with the repair?
> If not
> Is the repair continue reparing the other replicas even if one is down?
>
> Best regards
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>

Questions about anti-entropy repair

[Satoshi Hikida]

Hi,

I have two questions about anti-entropy repair.

Q1:
According to the DataStax document, it's recommended to run full repair
weekly or monthly. Is it needed even if repair with partitioner range
option ("nodetool repair -pr", in C* v2.2+) is set to run periodically for
every node in the cluster?

References:
- DataStax, "When to run anti-entropy repair",
http://docs.datastax.com/en/cassandra/2.2/cassandra/operations/opsRepairNodesWhen.html


Q2:
Is it a good practice to repair a node without using non-repaired snapshots
when I want to restore a node because repair process is too slow?

I've done some simple verifications for anti-entropy repair and found out
that the repair process spends too much time than simply transferring the
replica data from existing nodes to restoring node.

My verification settings are as following:

- 3 node cluster (N1, N2, N3)
- 2 CPUs, 8GB memory, 500GB HDD for each node
- Replication Factor is 3
- C* version is 2.2.6
- CS is LCS

And I prepared test data as following:

- a snapshot (10GB, full repaired) for N1, N2, N3.
- 1GB SSTables (by using incremental backup) for N1, N2, N3.
- another 1GB SSTables for N1, N2

I've measured repair time for two cases.

- Case 1: repair N3 with the snapshot and 1GB SStables
- Case 2: repair N3 with the snapshot only

In case 1, N3 is needed to repair 12GB (actually 1GB data is updated
because the snapshot is already repaired) and received 1GB data from N1 or
N2. Whereas in case 2, N3 is needed to repair 12GB (actually just compare
merkle tree for 10GB) and received 2GB data from N1 or N2.

The result showed that case 2 was faster than case 1 (case 1: 6889sec, case
2: 4535sec). I guess the repair process is very slow and it would be better
to repair a node without (non repaired) backed up (snapshot or incremental
backup) files if the other replica nodes exists.

So... I guess if I just have non-repaired backups, what's the point of
using them? Looks like there's no merit... Am I missing something?

Regards,
Satoshi

Re: Open source equivalents of OpsCenter

[Romain Hardouin]

Do you run C* on physical machine or in the cloud? If the topology doesn't 
change too often you can have a look a Zabbix. The downside is that you have to 
set up all the JMX metrics yourself... but that's also a good point because you 
can have custom metrics. If you want nice graphs/dashboards you can use Grafana 
to plot Zabbix data. (We're also using SaaS but that's not open source).For the 
rolling restart and other admin stuff we're using Rundeck. It's a great tool 
when working in a team.
(I think it's time to implement an open source alternative to OpsCenter. If 
some guys are interested I'm in.)
Best,
Romain

 

Le Jeudi 14 juillet 2016 0h01, Ranjib Dey  a écrit :
 

 we use datadog (metrics emitted as raw statsd) for the dashboard. All repair & 
compaction is done via blender & 
serf[1].[1]https://github.com/pagerduty/blender 

On Wed, Jul 13, 2016 at 2:42 PM, Kevin O'Connor  wrote:

Now that OpsCenter doesn't work with open source installs, are there any runs 
at an open source equivalent? I'd be more interested in looking at metrics of a 
running cluster and doing other tasks like managing repairs/rolling restarts 
more so than historical data.



  

Re: Open source equivalents of OpsCenter

[Juho Mäkinen]

I'm doing some work on replacing OpsCenter in out setup. I ended creating a
Docker container which contains the following features:

 - Cassandra 2.2.7
 - MX4J (a JMX to REST bridge) as a java-agent
 - metrics-graphite-3.1.0.jar (export some but not all JMX to graphite)
 - a custom ruby which uses MX4J to export some JMX metrics to graphite
which we don't otherwise get.

With this I will get all our cassandra instances and their JMX exposed data
to graphite, which allows us to use Grafana and Graphite to draw pretty
dashboards.

In addition I started writing some code which currently provides the
following features:
 - A dashboard which provides a similar ring view what OpsCenter does, with
onMouseOver features to display more info on each node.
 - Simple HTTP GET/POST based api to do
- Setup a new non-vnode based cluster
- Get a JSON blob on cluster information, all its tokens, machines and
so on
- Api for new cluster instances so that they can get a token slot from
the ring when they boot.
- Option to kill a dead node and mark its slot for replace, so the new
booting node can use cassandra.replace_address option.

The node is not yet packaged in any way for distribution and some parts
depend on our Chef installation, but if there's interest I can publish at
least some parts from it.

 - Garo

On Thu, Jul 14, 2016 at 10:54 AM, Romain Hardouin 
wrote:

> Do you run C* on physical machine or in the cloud? If the topology doesn't
> change too often you can have a look a Zabbix. The downside is that you
> have to set up all the JMX metrics yourself... but that's also a good point
> because you can have custom metrics. If you want nice graphs/dashboards you
> can use Grafana to plot Zabbix data. (We're also using SaaS but that's not
> open source).
> For the rolling restart and other admin stuff we're using Rundeck. It's a
> great tool when working in a team.
>
> (I think it's time to implement an open source alternative to OpsCenter.
> If some guys are interested I'm in.)
>
> Best,
>
> Romain
>
>
>
>
> Le Jeudi 14 juillet 2016 0h01, Ranjib Dey  a écrit :
>
>
> we use datadog (metrics emitted as raw statsd) for the dashboard. All
> repair & compaction is done via blender & serf[1].
> [1]https://github.com/pagerduty/blender
>
>
> On Wed, Jul 13, 2016 at 2:42 PM, Kevin O'Connor  wrote:
>
> Now that OpsCenter doesn't work with open source installs, are there any
> runs at an open source equivalent? I'd be more interested in looking at
> metrics of a running cluster and doing other tasks like managing
> repairs/rolling restarts more so than historical data.
>
>
>
>
>

Re: Open source equivalents of OpsCenter

[Romain Hardouin]

Hi Juho,
Out of curiosity, which stack did you use to make your dashboard?  
Romain
Le Jeudi 14 juillet 2016 10h43, Juho Mäkinen  a 
écrit :
 

 I'm doing some work on replacing OpsCenter in out setup. I ended creating a 
Docker container which contains the following features:
 - Cassandra 2.2.7 - MX4J (a JMX to REST bridge) as a java-agent - 
metrics-graphite-3.1.0.jar (export some but not all JMX to graphite) - a custom 
ruby which uses MX4J to export some JMX metrics to graphite which we don't 
otherwise get.
With this I will get all our cassandra instances and their JMX exposed data to 
graphite, which allows us to use Grafana and Graphite to draw pretty dashboards.
In addition I started writing some code which currently provides the following 
features: - A dashboard which provides a similar ring view what OpsCenter does, 
with onMouseOver features to display more info on each node. - Simple HTTP 
GET/POST based api to do    - Setup a new non-vnode based cluster    - Get a 
JSON blob on cluster information, all its tokens, machines and so on    - Api 
for new cluster instances so that they can get a token slot from the ring when 
they boot.    - Option to kill a dead node and mark its slot for replace, so 
the new booting node can use cassandra.replace_address option.
The node is not yet packaged in any way for distribution and some parts depend 
on our Chef installation, but if there's interest I can publish at least some 
parts from it.
 - Garo
On Thu, Jul 14, 2016 at 10:54 AM, Romain Hardouin  wrote:

Do you run C* on physical machine or in the cloud? If the topology doesn't 
change too often you can have a look a Zabbix. The downside is that you have to 
set up all the JMX metrics yourself... but that's also a good point because you 
can have custom metrics. If you want nice graphs/dashboards you can use Grafana 
to plot Zabbix data. (We're also using SaaS but that's not open source).For the 
rolling restart and other admin stuff we're using Rundeck. It's a great tool 
when working in a team.
(I think it's time to implement an open source alternative to OpsCenter. If 
some guys are interested I'm in.)
Best,
Romain

 

Le Jeudi 14 juillet 2016 0h01, Ranjib Dey  a écrit :
 

 we use datadog (metrics emitted as raw statsd) for the dashboard. All repair & 
compaction is done via blender & 
serf[1].[1]https://github.com/pagerduty/blender 

On Wed, Jul 13, 2016 at 2:42 PM, Kevin O'Connor  wrote:

Now that OpsCenter doesn't work with open source installs, are there any runs 
at an open source equivalent? I'd be more interested in looking at metrics of a 
running cluster and doing other tasks like managing repairs/rolling restarts 
more so than historical data.



   



  

Re: Open source equivalents of OpsCenter

[Stefano Ortolani]

Replaced OpsCenter with a mix of:

* metrics-graphite-3.1.0.jar installed in the same classpath of C*
* Custom script to push system metrics (cpu/mem/io)
* Grafana to create the dashboard
* Custom repairs script

Still not optimal but getting there...

Stefano

On Thu, Jul 14, 2016 at 10:18 AM, Romain Hardouin 
wrote:

> Hi Juho,
>
> Out of curiosity, which stack did you use to make your dashboard?
>
> Romain
>
> Le Jeudi 14 juillet 2016 10h43, Juho Mäkinen  a
> écrit :
>
>
> I'm doing some work on replacing OpsCenter in out setup. I ended creating
> a Docker container which contains the following features:
>
>  - Cassandra 2.2.7
>  - MX4J (a JMX to REST bridge) as a java-agent
>  - metrics-graphite-3.1.0.jar (export some but not all JMX to graphite)
>  - a custom ruby which uses MX4J to export some JMX metrics to graphite
> which we don't otherwise get.
>
> With this I will get all our cassandra instances and their JMX exposed
> data to graphite, which allows us to use Grafana and Graphite to draw
> pretty dashboards.
>
> In addition I started writing some code which currently provides the
> following features:
>  - A dashboard which provides a similar ring view what OpsCenter does,
> with onMouseOver features to display more info on each node.
>  - Simple HTTP GET/POST based api to do
> - Setup a new non-vnode based cluster
> - Get a JSON blob on cluster information, all its tokens, machines and
> so on
> - Api for new cluster instances so that they can get a token slot from
> the ring when they boot.
> - Option to kill a dead node and mark its slot for replace, so the new
> booting node can use cassandra.replace_address option.
>
> The node is not yet packaged in any way for distribution and some parts
> depend on our Chef installation, but if there's interest I can publish at
> least some parts from it.
>
>  - Garo
>
> On Thu, Jul 14, 2016 at 10:54 AM, Romain Hardouin 
> wrote:
>
> Do you run C* on physical machine or in the cloud? If the topology doesn't
> change too often you can have a look a Zabbix. The downside is that you
> have to set up all the JMX metrics yourself... but that's also a good point
> because you can have custom metrics. If you want nice graphs/dashboards you
> can use Grafana to plot Zabbix data. (We're also using SaaS but that's not
> open source).
> For the rolling restart and other admin stuff we're using Rundeck. It's a
> great tool when working in a team.
>
> (I think it's time to implement an open source alternative to OpsCenter.
> If some guys are interested I'm in.)
>
> Best,
>
> Romain
>
>
>
>
> Le Jeudi 14 juillet 2016 0h01, Ranjib Dey  a écrit :
>
>
> we use datadog (metrics emitted as raw statsd) for the dashboard. All
> repair & compaction is done via blender & serf[1].
> [1]https://github.com/pagerduty/blender
>
>
> On Wed, Jul 13, 2016 at 2:42 PM, Kevin O'Connor  wrote:
>
> Now that OpsCenter doesn't work with open source installs, are there any
> runs at an open source equivalent? I'd be more interested in looking at
> metrics of a running cluster and doing other tasks like managing
> repairs/rolling restarts more so than historical data.
>
>
>
>
>
>
>
>

Re: (C)* stable version after 3.5

[Stefano Ortolani]

FWIW, I've recently upgraded from 2.1 to 3.0 without issues of any sort,
but admittedly I haven't been using anything too fancy.

Cheers,
Stefano

On Wed, Jul 13, 2016 at 10:28 PM, Alain RODRIGUEZ 
wrote:

> Hi Anuj
>
> From
> https://docs.datastax.com/en/latest-upgrade/upgrade/cassandra/upgrdBestPractCassandra.html
> :
>
>
>>- Employ a continual upgrade strategy for each year. Upgrades are
>>impacted by the version you are upgrading from and the version you are
>>upgrading to. The greater the gap between the current version and the
>>target version, the more complex the upgrade.
>>
>>
> And I could not find it but historically I am quite sure it was explicitly
> recommended not to skip a major update (for a rolling upgrade), even if I
> could not find it. Anyway it is clear that the bigger the gap is, the more
> careful we need to be.
>
> On the other hand, I see 2.2 as a 2.1 + some feature but no real breaking
> changes (as 3.0 was already on the pipe) and doing a 2.2 was decided
> because 3.0 was taking a long time to be released and some feature were
> ready for a while.
>
> I might be wrong on some stuff above, but one can only speak with his
> knowledge and from his point of view. So I ended up saying:
>
> Also I am not sure if the 2.2 major version is something you can skip
>> while upgrading through a rolling restart. I believe you can, but it is not
>> what is recommended.
>>
>
> Note that "I am not sure", "I believe you can"... So it was more a
> thought, something to explore for Varun :-).
>
> And I actually encouraged him to move forward. Now that Tyler Hobbs
> confirmed it works, you can put a lot more trust on the fact that this
> upgrade will work :-). I would still encourage people to test it (for
> client compatibility, corner cases due to models, ...).
>
> I hope I am more clear now,
>
> C*heers,
> ---
> Alain Rodriguez - al...@thelastpickle.com
> France
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> 2016-07-13 18:39 GMT+02:00 Tyler Hobbs :
>
>>
>> On Wed, Jul 13, 2016 at 11:32 AM, Anuj Wadehra 
>> wrote:
>>
>>> Why do you think that skipping 2.2 is not recommended when NEWS.txt
>>> suggests otherwise? Can you elaborate?
>>
>>
>> We test upgrading from 2.1 -> 3.x and upgrading from 2.2 -> 3.x
>> equivalently.  There should not be a difference in terms of how well the
>> upgrade is supported.
>>
>>
>> --
>> Tyler Hobbs
>> DataStax 
>>
>
>

Re: Open source equivalents of OpsCenter

[Michał Łowicki]

My experience while looking for a replacement on
https://medium.com/@mlowicki/alternatives-to-datastax-opscenter-8ad893efe063


On Thursday, 14 July 2016, Stefano Ortolani  wrote:

> Replaced OpsCenter with a mix of:
>
> * metrics-graphite-3.1.0.jar installed in the same classpath of C*
> * Custom script to push system metrics (cpu/mem/io)
> * Grafana to create the dashboard
> * Custom repairs script
>
> Still not optimal but getting there...
>
> Stefano
>
> On Thu, Jul 14, 2016 at 10:18 AM, Romain Hardouin  > wrote:
>
>> Hi Juho,
>>
>> Out of curiosity, which stack did you use to make your dashboard?
>>
>> Romain
>>
>> Le Jeudi 14 juillet 2016 10h43, Juho Mäkinen > > a écrit :
>>
>>
>> I'm doing some work on replacing OpsCenter in out setup. I ended creating
>> a Docker container which contains the following features:
>>
>>  - Cassandra 2.2.7
>>  - MX4J (a JMX to REST bridge) as a java-agent
>>  - metrics-graphite-3.1.0.jar (export some but not all JMX to graphite)
>>  - a custom ruby which uses MX4J to export some JMX metrics to graphite
>> which we don't otherwise get.
>>
>> With this I will get all our cassandra instances and their JMX exposed
>> data to graphite, which allows us to use Grafana and Graphite to draw
>> pretty dashboards.
>>
>> In addition I started writing some code which currently provides the
>> following features:
>>  - A dashboard which provides a similar ring view what OpsCenter does,
>> with onMouseOver features to display more info on each node.
>>  - Simple HTTP GET/POST based api to do
>> - Setup a new non-vnode based cluster
>> - Get a JSON blob on cluster information, all its tokens, machines
>> and so on
>> - Api for new cluster instances so that they can get a token slot
>> from the ring when they boot.
>> - Option to kill a dead node and mark its slot for replace, so the
>> new booting node can use cassandra.replace_address option.
>>
>> The node is not yet packaged in any way for distribution and some parts
>> depend on our Chef installation, but if there's interest I can publish at
>> least some parts from it.
>>
>>  - Garo
>>
>> On Thu, Jul 14, 2016 at 10:54 AM, Romain Hardouin > > wrote:
>>
>> Do you run C* on physical machine or in the cloud? If the topology
>> doesn't change too often you can have a look a Zabbix. The downside is that
>> you have to set up all the JMX metrics yourself... but that's also a good
>> point because you can have custom metrics. If you want nice
>> graphs/dashboards you can use Grafana to plot Zabbix data. (We're also
>> using SaaS but that's not open source).
>> For the rolling restart and other admin stuff we're using Rundeck. It's a
>> great tool when working in a team.
>>
>> (I think it's time to implement an open source alternative to OpsCenter.
>> If some guys are interested I'm in.)
>>
>> Best,
>>
>> Romain
>>
>>
>>
>>
>> Le Jeudi 14 juillet 2016 0h01, Ranjib Dey > > a écrit :
>>
>>
>> we use datadog (metrics emitted as raw statsd) for the dashboard. All
>> repair & compaction is done via blender & serf[1].
>> [1]https://github.com/pagerduty/blender
>>
>>
>> On Wed, Jul 13, 2016 at 2:42 PM, Kevin O'Connor > > wrote:
>>
>> Now that OpsCenter doesn't work with open source installs, are there any
>> runs at an open source equivalent? I'd be more interested in looking at
>> metrics of a running cluster and doing other tasks like managing
>> repairs/rolling restarts more so than historical data.
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 
BR,
Michał Łowicki

Re: (C)* stable version after 3.5

[Romain Hardouin]

DSE 4.8 uses C* 2.1 and DSE 5.0 uses C* 3.0. So I would say that 2.1->3.0 is 
more tested by DataStax than 2.2->3.0. 

Le Jeudi 14 juillet 2016 11h37, Stefano Ortolani  a 
écrit :
 

 FWIW, I've recently upgraded from 2.1 to 3.0 without issues of any sort, but 
admittedly I haven't been using anything too fancy.
Cheers,Stefano
On Wed, Jul 13, 2016 at 10:28 PM, Alain RODRIGUEZ  wrote:

Hi Anuj
>From 
>https://docs.datastax.com/en/latest-upgrade/upgrade/cassandra/upgrdBestPractCassandra.html:

   
   - Employ a continual upgrade strategy for each year. Upgrades are impacted 
by the version you are upgrading from and the version you are upgrading to. The 
greater the gap between the current version and the target version, the more 
complex the upgrade.


And I could not find it but historically I am quite sure it was explicitly 
recommended not to skip a major update (for a rolling upgrade), even if I could 
not find it. Anyway it is clear that the bigger the gap is, the more careful we 
need to be.
On the other hand, I see 2.2 as a 2.1 + some feature but no real breaking 
changes (as 3.0 was already on the pipe) and doing a 2.2 was decided because 
3.0 was taking a long time to be released and some feature were ready for a 
while.
I might be wrong on some stuff above, but one can only speak with his knowledge 
and from his point of view. So I ended up saying:

Also I am not sure if the 2.2 major version is something you can skip while 
upgrading through a rolling restart. I believe you can, but it is not what is 
recommended.


Note that "I am not sure", "I believe you can"... So it was more a thought, 
something to explore for Varun :-).

And I actually encouraged him to move forward. Now that Tyler Hobbs confirmed 
it works, you can put a lot more trust on the fact that this upgrade will work 
:-). I would still encourage people to test it (for client compatibility, 
corner cases due to models, ...).
I hope I am more clear now,
C*heers,---Alain Rodriguez - alain@thelastpickle.comFrance
The Last Pickle - Apache Cassandra Consultinghttp://www.thelastpickle.com
2016-07-13 18:39 GMT+02:00 Tyler Hobbs :


On Wed, Jul 13, 2016 at 11:32 AM, Anuj Wadehra  wrote:

Why do you think that skipping 2.2 is not recommended when NEWS.txt suggests 
otherwise? Can you elaborate?

We test upgrading from 2.1 -> 3.x and upgrading from 2.2 -> 3.x equivalently.  
There should not be a difference in terms of how well the upgrade is supported.


-- 
Tyler Hobbs
DataStax






  

use private ip for internode and public IP for seeds

[Spiros Ioannou]

Hello,

Let's say we have a 3-node (linux) cassandra 3.7 cluster on GCE (same
probably for EC2). VMs know their private IPs, and also have a public IP.

Nodes were configured according to doc: multiple network interfaces which
in short says to use private IPs for listen_address, public IP for
broadcast_address, and public ip for seeds.

According to the doc above, "Cassandra switches to the private IP after
establishing a connection." but this does not happen, tcpdump shows one end
of traffic to port 7000 is always a public IP.

Using "prefer_local=true" on cassandra-rackdc.properties just makes the
clients try to connect to the private IPs which fails.

All this works, clients connect and nodes see each other, but communication
between nodes happen through their pubic IPs. We want clients to connect to
the public IP, get a list of public IPs as contact points (endpoints) from
the coordinator, but coordinator to forward requests through the private
IPs. Can this be done?










*Spiros Ioannou Infrastructure Lead EngineerinAccesswww.inaccess.com
M: +30 6973-903808W: +30 210-6802-358*

Re: What is the merit of incremental backup

[Prasenjit Sarkar]

Hi Satoshi

You are correct that incremental backups offer you the opportunity to
reduce the amount of data you need to transfer offsite. On the recovery
path, you need to piece together the full backup and subsequent incremental
backups.

However, where incremental backups help is with respect to the RTO due to
the data reduction effect you mentioned. The RPO can be reduced only if you
take more frequent incremental backups than full backups.

Hope this helps,
Prasenjit

On Wed, Jul 13, 2016 at 11:54 PM, Satoshi Hikida  wrote:

> Hi,
>
> I want to know the actual advantage of using incremental backup.
>
> I've read through the DataStax document and it says the merit of using
> incremental backup is as follows:
>
> - It allows storing backups offsite without transferring entire snapshots
> - With incremental backups and snapshots, it can provide more recent RPO
> (Recovery Point Objective)
>
> Is my understanding correct? I would appreciate if someone gives me some
> advice or correct me.
>
> References:
> - DataStax, "Enabling incremental backups",
> http://docs.datastax.com/en/cassandra/2.2/cassandra/operations/opsBackupIncremental.html
>
> Regards,
> Satoshi
>

Re: how to start a embed cassandra instance?

[Stone Fang]

Achilles is a good project.but it is heavy.actually i just need to
1.start/stop a embed  standalone cassandra
2.start/stop a embed cassandra cluster.

seems CassandraDaemon can just start a standalone,not cluster.


On Wed, Jul 13, 2016 at 8:31 PM, DuyHai Doan  wrote:

> As for Achilles, no I start Cassandra in the same JVM. It is meant to be
> used for testing purpose only. I also faced dependency issue with different
> version of Guava so I excluded the Guava pulled by the Datastax Java driver
> to use the one pulled by C* itself:
> https://github.com/doanduyhai/Achilles/blob/master/achilles-embedded/pom.xml#L52-L55
>
>
>
> On Wed, Jul 13, 2016 at 2:28 PM, Ken Hancock 
> wrote:
>
>> Do either cassandra-unit or Achilles fork Cassandra to a separate JVM?
>> Guava libraries create a dependency hell with our current use of Hector's
>> embedded server.  We're starting to migrate to the Datastax Java driver
>> with yet another guava version.  I know Farsandra supports forking, so that
>> was where I was thinking of going first.
>>
>>
>>
>>
>> On Tue, Jul 12, 2016 at 9:37 AM, DuyHai Doan 
>> wrote:
>>
>>> If you're looking something similar to cassandra-unit with Apache 2
>>> licence, there is a module in Achilles project that provides the same
>>> thing:
>>> https://github.com/doanduyhai/Achilles/wiki/CQL-embedded-cassandra-server
>>>
>>> On Tue, Jul 12, 2016 at 12:56 PM, Peddi, Praveen 
>>> wrote:
>>>
 We do something similar by starting CassandraDaemon class directly (you
 would need to provide a yaml file though). You can start and stop
 CassandraDaemon class from your unit test (typically @BeforeClass).

 Praveen

 On Jul 12, 2016, at 3:30 AM, Stone Fang  wrote:

 Hi,
 how to start a embed cassandra instance?so we can do a unit test on
 local,dont need to start a
 cassandra server.

 https://github.com/jsevellec/cassandra-unit this project is good,but
 the license is not suitable.
 how do you achieve this?

 thanks in advance

 stone


>>>
>>
>>
>> --
>> *Ken Hancock *| System Architect, Advanced Advertising
>> SeaChange International
>> 50 Nagog Park
>> Acton, Massachusetts 01720
>> ken.hanc...@schange.com | www.schange.com | NASDAQ:SEAC
>> 
>> Office: +1 (978) 889-3329 | [image: Google Talk:] ken.hanc...@schange.com
>>  | [image: Skype:]hancockks | [image: Yahoo IM:]hancockks [image:
>> LinkedIn] 
>>
>> [image: SeaChange International]
>> 
>> This e-mail and any attachments may contain information which is
>> SeaChange International confidential. The information enclosed is intended
>> only for the addressees herein and may not be copied or forwarded without
>> permission from SeaChange International.
>>
>
>