Re: Back to the futex()? :(

[Nate McCall]

I noticed you have authentication enabled. Make sure you set the following:

- the replication factor for the system_auth keyspace should equal the
number of nodes
- permissions_validity_in_ms is a permission cache timeout. If you are not
doing dynamic permissions or creating/revoking frequently, turn this WAY up

May not be the immediate reason, but the above are definitely not helping
if set at defaults.

On Sat, Feb 6, 2016 at 6:49 PM, Will Hayworth 
wrote:

> Additionally: this isn't the futex_wait bug (or at least it shouldn't
> be?). Amazon says
>  that was
> fixed several kernel versions before mine, which
> is 4.1.10-17.31.amzn1.x86_64. And the reason my heap is so large is
> because, per CASSANDRA-9472, we can't use offheap until 3.4 is released.
>
> Will
>
> ___
> Will Hayworth
> Developer, Engagement Engine
> Atlassian
>
> My pronoun is "they". 
>
>
>
> On Sat, Feb 6, 2016 at 3:28 PM, Will Hayworth 
> wrote:
>
>> *tl;dr: other than CAS operations, what are the potential sources of lock
>> contention in C*?*
>>
>> Hi all! :) I'm a novice Cassandra and Linux admin who's been preparing a
>> small cluster for production, and I've been seeing something weird. For
>> background: I'm running 3.2.1 on a cluster of 12 EC2 m4.2xlarges (32 GB
>> RAM, 8 HT cores) backed by 3.5 TB GP2 EBS volumes. Until late yesterday,
>> that was a cluster of 12 m4.xlarges with 3 TB volumes. I bumped it because
>> while backloading historical data I had been seeing awful throughput (20K
>> op/s at CL.ONE). I'd read through Al Tobey's *amazing* C* tuning guide
>>  once
>> or twice before but this time I was careful and fixed a bunch of defaults
>> that just weren't right, in cassandra.yaml/JVM options/block device
>> parameters. Folks on IRC were super helpful as always (hat tip to Jeff
>> Jirsa in particular) and pointed out, for example, that I shouldn't be
>> using DTCS for loading historical data--heh. After changing to LTCS,
>> unbatching my writes* and reserving a CPU core for interrupts and fixing
>> the clocksource to TSC, I finally hit 80K early this morning. Hooray! :)
>>
>> Now, my question: I'm still seeing a *ton* of blocked processes in the
>> vmstats, anything from 2 to 9 per 10 second sample period--and this is
>> before EBS is even being hit! I've been trying in vain to figure out what
>> this could be--GC seems very quiet, after all. On Al's page's advice, I've
>> been running strace and, indeed, I've been seeing *tens of thousands of
>> futex() calls* in periods of 10 or 20 seconds. What eludes me is *where* this
>> lock contention is coming from. I'm not using LWTs or performing CAS
>> operations of which I'm aware. Assuming this isn't a red herring, what
>> gives?
>>
>> Sorry for the essay--I just wanted to err on the side of more
>> context--and *thank you* for any advice you'd like to offer,
>> Will
>>
>> P.S. More background if you'd like--I'm running on Amazon Linux 2015.09,
>> using jemalloc 3.6, JDK 1.8.0_65-b17. Here  is
>> my cassandra.yaml and here  are my JVM
>> args. I realized I neglected to adjust memtable_flush_writers as I was
>> writing this--so I'll get on that. Aside from that, I'm not sure what to
>> do. (Thanks, again, for reading.)
>>
>> * They were batched for consistency--I'm hoping to return to using them
>> when I'm back at normal load, which is tiny compared to backloading, but
>> the impact on performance was eye-opening.
>> ___
>> Will Hayworth
>> Developer, Engagement Engine
>> Atlassian
>>
>> My pronoun is "they". 
>>
>>
>>
>


-- 
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: [RELEASE] Apache Cassandra 3.3 released

[Jake Luciani]

No problem. Run it after you upgrade.

On Tue, Feb 9, 2016 at 2:01 PM, Will Hayworth 
wrote:

> Pardon my ignorance, Jake--should we run upgradesstables -a after or
> before we install 3.3?
>
> Thanks! :)
>
> ___
> Will Hayworth
> Developer, Engagement Engine
> Atlassian
>
> My pronoun is "they". 
>
>
>
> On Tue, Feb 9, 2016 at 10:50 AM, Jake Luciani  wrote:
>
>> The Cassandra team is pleased to announce the release of Apache Cassandra
>> version 3.3.
>>
>> *This release contains a critical bug in 3.0 series[4].* If you have
>> installed version >= 3.0
>> you will need to run 'nodetool upgradesstables -a' on all nodes to
>> receive the fix.
>>
>> Apache Cassandra is a fully distributed database. It is the right choice
>> when you need scalability and high availability without compromising
>> performance.
>>
>>  http://cassandra.apache.org/
>>
>> Downloads of source and binary distributions are listed in our download
>> section:
>>
>>  http://cassandra.apache.org/download/
>>
>> This version is a bug fix release[1] on the 3.3 series. As always, please
>> pay
>> attention to the release notes[2] and Let us know[3] if you were to
>> encounter
>> any problem.
>>
>> Enjoy!
>>
>> [1]: http://goo.gl/V2lsST (CHANGES.txt)
>> [2]: http://goo.gl/5UBlNl (NEWS.txt)
>> [3]: https://issues.apache.org/jira/browse/CASSANDRA
>> [4]: https://issues.apache.org/jira/browse/CASSANDRA-11102
>>
>>
>


-- 
http://twitter.com/tjake

Re: Back to the futex()? :(

[Ben Bromhead]

I'm not surprised that when you profile cassandra you are seeing some lock
contention, particularly given its SEDA architecture, as there is a lot of
waiting that threads end up doing while requests make their way through the
various stages.

See
https://wiki.apache.org/cassandra/ArchitectureInternals
https://issues.apache.org/jira/browse/CASSANDRA-10989
https://blogs.oracle.com/roland/entry/real_time_java_and_futexes


So I would say the thread_wait issue is a red herring in this case given it
will be inherent for most Cassandra deployments... the caveat is that you
are running 3.2.1 which is a thoroughly new version of Cassandra that may
have a new bug and I'm not sure how many people here have experience with
it. Especially given that the new tick-tock approach makes it hard to judge
when a release is ready for prime time.

Otherwise follow the good folk at crowdstrike for getting good performance
out of EBS (
http://www.slideshare.net/jimplush/1-million-writes-per-second-on-60-nodes-with-cassandra-and-ebs).
They have done all the hard work for the rest of us.

Reduce your JVM heap size to something closer to 8GB, given that your
cluster hasn't seen a production workload I wouldn't worry about tuning
heap etc unless you see GC pressure in the logs. You don't want to spend a
lot of time tuning for backloading when the actual traffic will be / could
be different.

The performance you are getting is roughly on par to what we have seen with
some early benchmarking of EBS volumes (
https://www.instaclustr.com/2015/10/28/cassandra-on-aws-ebs-infrastructure/),
but with machines half the size. We decided to go a slightly different path
and use m4.xlarges we are always playing with different configurations to
see what works best.


On Sat, 6 Feb 2016 at 16:50 Will Hayworth  wrote:

> Additionally: this isn't the futex_wait bug (or at least it shouldn't
> be?). Amazon says
>  that was
> fixed several kernel versions before mine, which
> is 4.1.10-17.31.amzn1.x86_64. And the reason my heap is so large is
> because, per CASSANDRA-9472, we can't use offheap until 3.4 is released.
>
> Will
>
> ___
> Will Hayworth
> Developer, Engagement Engine
> Atlassian
>
> My pronoun is "they". 
>
>
>
> On Sat, Feb 6, 2016 at 3:28 PM, Will Hayworth 
> wrote:
>
>> *tl;dr: other than CAS operations, what are the potential sources of lock
>> contention in C*?*
>>
>> Hi all! :) I'm a novice Cassandra and Linux admin who's been preparing a
>> small cluster for production, and I've been seeing something weird. For
>> background: I'm running 3.2.1 on a cluster of 12 EC2 m4.2xlarges (32 GB
>> RAM, 8 HT cores) backed by 3.5 TB GP2 EBS volumes. Until late yesterday,
>> that was a cluster of 12 m4.xlarges with 3 TB volumes. I bumped it because
>> while backloading historical data I had been seeing awful throughput (20K
>> op/s at CL.ONE). I'd read through Al Tobey's *amazing* C* tuning guide
>>  once
>> or twice before but this time I was careful and fixed a bunch of defaults
>> that just weren't right, in cassandra.yaml/JVM options/block device
>> parameters. Folks on IRC were super helpful as always (hat tip to Jeff
>> Jirsa in particular) and pointed out, for example, that I shouldn't be
>> using DTCS for loading historical data--heh. After changing to LTCS,
>> unbatching my writes* and reserving a CPU core for interrupts and fixing
>> the clocksource to TSC, I finally hit 80K early this morning. Hooray! :)
>>
>> Now, my question: I'm still seeing a *ton* of blocked processes in the
>> vmstats, anything from 2 to 9 per 10 second sample period--and this is
>> before EBS is even being hit! I've been trying in vain to figure out what
>> this could be--GC seems very quiet, after all. On Al's page's advice, I've
>> been running strace and, indeed, I've been seeing *tens of thousands of
>> futex() calls* in periods of 10 or 20 seconds. What eludes me is *where* this
>> lock contention is coming from. I'm not using LWTs or performing CAS
>> operations of which I'm aware. Assuming this isn't a red herring, what
>> gives?
>>
>> Sorry for the essay--I just wanted to err on the side of more
>> context--and *thank you* for any advice you'd like to offer,
>> Will
>>
>> P.S. More background if you'd like--I'm running on Amazon Linux 2015.09,
>> using jemalloc 3.6, JDK 1.8.0_65-b17. Here  is
>> my cassandra.yaml and here  are my JVM
>> args. I realized I neglected to adjust memtable_flush_writers as I was
>> writing this--so I'll get on that. Aside from that, I'm not sure what to
>> do. (Thanks, again, for reading.)
>>
>> * They were batched for consistency--I'm hoping to return to using them
>> when I'm back at normal load, which is tiny 

Re: [RELEASE] Apache Cassandra 3.3 released

[Jack Krupansky]

Technically this is actually "a bug fix release[1] on the 3.x series" -
"3.x" rather than "3.3", I think.

-- Jack Krupansky

On Tue, Feb 9, 2016 at 1:50 PM, Jake Luciani  wrote:

> The Cassandra team is pleased to announce the release of Apache Cassandra
> version 3.3.
>
> *This release contains a critical bug in 3.0 series[4].* If you have
> installed version >= 3.0
> you will need to run 'nodetool upgradesstables -a' on all nodes to receive
> the fix.
>
> Apache Cassandra is a fully distributed database. It is the right choice
> when you need scalability and high availability without compromising
> performance.
>
>  http://cassandra.apache.org/
>
> Downloads of source and binary distributions are listed in our download
> section:
>
>  http://cassandra.apache.org/download/
>
> This version is a bug fix release[1] on the 3.3 series. As always, please
> pay
> attention to the release notes[2] and Let us know[3] if you were to
> encounter
> any problem.
>
> Enjoy!
>
> [1]: http://goo.gl/V2lsST (CHANGES.txt)
> [2]: http://goo.gl/5UBlNl (NEWS.txt)
> [3]: https://issues.apache.org/jira/browse/CASSANDRA
> [4]: https://issues.apache.org/jira/browse/CASSANDRA-11102
>
>

Re: Back to the futex()? :(

[Will Hayworth]

Thanks for the links, Ben--I'll be sure to give those a read. And yeah,
followed the Crowdstrike presentation in detail (including the stuff they
called out on Al Tobey's page). Again, the reason for the huge heap is that
otherwise my memtable can't actually fit in memory (no off-heap until 3.4),
but your point about tuning before true prod is well taken. :) (And I read
your post, too--the reason we started with m4.xlarges is in large part
because you all made it work.)

Nate--the RF is taken care of, thanks (otherwise I've seen issues where my
code can't log in to a given node, which makes sense) and, furthermore, I
ran a repair after doing all the initial loading. I'm not doing dynamic
permissions (though I'm hoping to use Vault  to
generate short-lived user/password combinations soon), so I'll be sure to
adjust permissions_validity_in_ms.

Thank you both so much for your help!

___
Will Hayworth
Developer, Engagement Engine
Atlassian

My pronoun is "they". 



On Tue, Feb 9, 2016 at 11:25 AM, Nate McCall  wrote:

> I noticed you have authentication enabled. Make sure you set the following:
>
> - the replication factor for the system_auth keyspace should equal the
> number of nodes
> - permissions_validity_in_ms is a permission cache timeout. If you are not
> doing dynamic permissions or creating/revoking frequently, turn this WAY up
>
> May not be the immediate reason, but the above are definitely not helping
> if set at defaults.
>
> On Sat, Feb 6, 2016 at 6:49 PM, Will Hayworth 
> wrote:
>
>> Additionally: this isn't the futex_wait bug (or at least it shouldn't
>> be?). Amazon says
>>  that was
>> fixed several kernel versions before mine, which
>> is 4.1.10-17.31.amzn1.x86_64. And the reason my heap is so large is
>> because, per CASSANDRA-9472, we can't use offheap until 3.4 is released.
>>
>> Will
>>
>> ___
>> Will Hayworth
>> Developer, Engagement Engine
>> Atlassian
>>
>> My pronoun is "they". 
>>
>>
>>
>> On Sat, Feb 6, 2016 at 3:28 PM, Will Hayworth 
>> wrote:
>>
>>> *tl;dr: other than CAS operations, what are the potential sources of
>>> lock contention in C*?*
>>>
>>> Hi all! :) I'm a novice Cassandra and Linux admin who's been preparing a
>>> small cluster for production, and I've been seeing something weird. For
>>> background: I'm running 3.2.1 on a cluster of 12 EC2 m4.2xlarges (32 GB
>>> RAM, 8 HT cores) backed by 3.5 TB GP2 EBS volumes. Until late yesterday,
>>> that was a cluster of 12 m4.xlarges with 3 TB volumes. I bumped it because
>>> while backloading historical data I had been seeing awful throughput (20K
>>> op/s at CL.ONE). I'd read through Al Tobey's *amazing* C* tuning guide
>>>  once
>>> or twice before but this time I was careful and fixed a bunch of defaults
>>> that just weren't right, in cassandra.yaml/JVM options/block device
>>> parameters. Folks on IRC were super helpful as always (hat tip to Jeff
>>> Jirsa in particular) and pointed out, for example, that I shouldn't be
>>> using DTCS for loading historical data--heh. After changing to LTCS,
>>> unbatching my writes* and reserving a CPU core for interrupts and fixing
>>> the clocksource to TSC, I finally hit 80K early this morning. Hooray! :)
>>>
>>> Now, my question: I'm still seeing a *ton* of blocked processes in the
>>> vmstats, anything from 2 to 9 per 10 second sample period--and this is
>>> before EBS is even being hit! I've been trying in vain to figure out what
>>> this could be--GC seems very quiet, after all. On Al's page's advice, I've
>>> been running strace and, indeed, I've been seeing *tens of thousands of
>>> futex() calls* in periods of 10 or 20 seconds. What eludes me is *where* 
>>> this
>>> lock contention is coming from. I'm not using LWTs or performing CAS
>>> operations of which I'm aware. Assuming this isn't a red herring, what
>>> gives?
>>>
>>> Sorry for the essay--I just wanted to err on the side of more
>>> context--and *thank you* for any advice you'd like to offer,
>>> Will
>>>
>>> P.S. More background if you'd like--I'm running on Amazon Linux 2015.09,
>>> using jemalloc 3.6, JDK 1.8.0_65-b17. Here
>>>  is my cassandra.yaml and here
>>>  are my JVM args. I realized I neglected
>>> to adjust memtable_flush_writers as I was writing this--so I'll get on
>>> that. Aside from that, I'm not sure what to do. (Thanks, again, for
>>> reading.)
>>>
>>> * They were batched for consistency--I'm hoping to return to using them
>>> when I'm back at normal load, which is tiny compared to backloading, but
>>> the impact on performance was eye-opening.
>>> 

Re: Scenarios which need Repair

[Anuj Wadehra]

Hi,
Can someone take this?

ThanksAnuj


 
 
  On Mon, 8 Feb, 2016 at 11:44 pm, Anuj Wadehra wrote:  
 Hi,

Setup:

We are on 2.0.14. We have some deployments with just one DC(RF:3) while others 
with two DCs (RF:3,RF:3).
We ALWAYS use LOCAL_QUORUM for both Reads and Writes. 

Scenario:
-
We used to run nodetool repair on all tables every gc_grace_seconds. Recently, 
we decided to identify tables which really need repair and only run repair on 
those tables.

We have identified basically two kinds of tables which don't need repair:
TYPE-1 Tables which have only inserts, no upserts and delete by TTL.
TYPE-2 Tables with a counter column. I don't have much experience with counters 
but I can explain the use case.
We use a counter column to keep check on our traffic rate.Values are usually 
updated numerous times in a minute and we need not be ACCURATE with the 
value-few values here and there are OK.

Questions:
--
Can we COMPLETELY avoid maintenance repair on TYPE-1 and TYPE-2 tables? If yes, 
will there be any side effect of not repairing such data often in case of 
dropped mutations, failure scenarios etc.?
What will be the scenarios when repair would be needed on such tables?
   
  
Thanks
Anuj   
   
    
  

RE: Restart Cassandra automatically

[SEAN_R_DURITY]

Call me naïve, but we do use an in-house built program for keeping nodes 
started (based on a flag-check). The program is something that was written for 
all kinds of daemon processes here, not Cassandra specifically. The basic idea 
is that is runs a status check. If that fails, and the flag is set, start 
Cassandra. In my opinion, it has helped more than hurt us – especially with the 
very fragile 1.1 releases that were prone to heap problems.

Sean Durity

From: Robert Coli [mailto:rc...@eventbrite.com]
Sent: Friday, February 05, 2016 1:28 PM
To: user@cassandra.apache.org
Subject: Re: Restart Cassandra automatically

On Thu, Feb 4, 2016 at 8:26 PM, Debraj Manna 
> wrote:

What is the best way to keep cassandra running? My requirement is if for some 
reason cassandra stops then it should get started automatically.
I recommend against this mode of operation. When automatically restarting, you 
have no idea how long Cassandra has been stopped and for what reason. In some 
cases, you really do not want it to start up and attempt to participate in 
whatever cluster it was formerly participating in.

I understand this creates a support overhead, especially with very large 
clusters, but it's difficult for me to accept the premise that net operational 
safety will be improved by naively restarting nodes.

=Rob




The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in connection with this e-mail 
message or its attachment.

Re: ORM layer for cassandra-java?

[DuyHai Doan]

Look at Achilles and how it models Partition key & clustering columns:

https://github.com/doanduyhai/Achilles/wiki/5-minutes-Tutorial#clustered-entities



On Tue, Feb 9, 2016 at 12:48 PM, Atul Saroha 
wrote:

> I know the most popular ORM api
>
>1. Kundera :
>
> https://github.com/impetus-opensource/Kundera/wiki/Using-Compound-keys-with-Kundera
>2. Hector (outdated- no longer in development)
>
> I am bit confuse to model this table into java domain entity structure
>
> CREATE TABLE IF NOT EXISTS  ks.PrimeUser(
>   id int,
>   c1 text STATIC,
>   c2 boolean STATIC,
>   c3 text,
>   c4 text,
>   PRIMARY KEY (id, c3)
> );
>
>
> One way is to create compound key based on id and c3 column as shown
> below.
>
>> @Entity
>> @Table(name="PrimeUser", schema="ks")
>> public class PrimeUser
>> {
>>
>> @EmbeddedId
>> private CompoundKey key;
>>
>>@Column
>>private String c1;
>>@Column
>>private String c2;
>>@Column
>>private String c4;
>> }
>>
>> Here key has to be an Embeddable entity:
>>
>> @Embeddable
>> public class CompoundKey
>> {
>> @Column private int id;
>> @Column private String c1;
>> }
>>
>> Then again when we fetch the data based on id only then c1 and c2 will be
> duplicated multiple times object, even though they are stored per "id"
> basis. c3 column is cluster key and its corresponding value is mapped to
> column c4. We avoid using map here as it will cause performance hit.
> Also he have use cases to fetch the data based on (b1,c3) both also.
>
> Is there any other ORM API which handle such scenario.
>
>
>
>
> -
> Atul Saroha
> *Sr. Software Engineer*
> *M*: +91 8447784271 *T*: +91 124-415-6069 *EXT*: 12369
> Plot # 362, ASF Centre - Tower A, Udyog Vihar,
>  Phase -4, Sector 18, Gurgaon, Haryana 122016, INDIA
>

Re: Scenarios which need Repair

[Carlos Alonso]

Hi Anuj.

I don't think this decision depends on you scenario, but on your write
consistency level instead.

Maintenance repair is an anti-entropy operation intended to make all nodes
consistent.

Think of the situation where, with one DC, one of your nodes is down (or
being replaced) for a while (longer than hints timeout), as you're using
LOCAL_QUORUM, writes will succeed and when that node is back it'll NEVER
get that record.

Increasing that consistency level to ALL would change the scenario a little
bit, as your write will actually fail, as will all writes to any token
replicated in the down node (probably not what you want).

Let's now think of the multi DC deployment. If connection between DCs is
lost, reads and writes will succeed, but data won't be replicated across
them and you won't even notice.

I think maintenance repair is something required wherever there are
writes/updates.

Regards

Carlos Alonso | Software Engineer | @calonso 

On 9 February 2016 at 11:10, Anuj Wadehra  wrote:

> Hi,
>
> Can someone take this?
>
>
> Thanks
> Anuj
>
>
>
> On Mon, 8 Feb, 2016 at 11:44 pm, Anuj Wadehra
>  wrote:
> Hi,
>
> Setup:
> 
> We are on 2.0.14. We have some deployments with just one DC(RF:3) while
> others with two DCs (RF:3,RF:3).
> We ALWAYS use LOCAL_QUORUM for both Reads and Writes.
>
> Scenario:
> -
> We used to run nodetool repair on all tables every gc_grace_seconds.
> Recently, we decided to identify tables which really need repair and only
> run repair on those tables.
>
> We have identified basically two kinds of tables which don't need repair:
> TYPE-1 Tables which have only inserts, no upserts and delete by TTL.
> TYPE-2 Tables with a counter column. I don't have much experience with
> counters but I can explain the use case.
> We use a counter column to keep check on our traffic rate.Values are
> usually updated numerous times in a minute and we need not be ACCURATE with
> the value-few values here and there are OK.
>
> Questions:
> --
> Can we COMPLETELY avoid maintenance repair on TYPE-1 and TYPE-2 tables? If
> yes, will there be any side effect of not repairing such data often in case
> of dropped mutations, failure scenarios etc.?
> What will be the scenarios when repair would be needed on such tables?
>
>
> Thanks
> Anuj
>
>
>
>

ORM layer for cassandra-java?

[Atul Saroha]

I know the most popular ORM api

   1. Kundera :
   
https://github.com/impetus-opensource/Kundera/wiki/Using-Compound-keys-with-Kundera
   2. Hector (outdated- no longer in development)

I am bit confuse to model this table into java domain entity structure

CREATE TABLE IF NOT EXISTS  ks.PrimeUser(
  id int,
  c1 text STATIC,
  c2 boolean STATIC,
  c3 text,
  c4 text,
  PRIMARY KEY (id, c3)
);


One way is to create compound key based on id and c3 column as shown below.

> @Entity
> @Table(name="PrimeUser", schema="ks")
> public class PrimeUser
> {
>
> @EmbeddedId
> private CompoundKey key;
>
>@Column
>private String c1;
>@Column
>private String c2;
>@Column
>private String c4;
> }
>
> Here key has to be an Embeddable entity:
>
> @Embeddable
> public class CompoundKey
> {
> @Column private int id;
> @Column private String c1;
> }
>
> Then again when we fetch the data based on id only then c1 and c2 will be
duplicated multiple times object, even though they are stored per "id"
basis. c3 column is cluster key and its corresponding value is mapped to
column c4. We avoid using map here as it will cause performance hit.
Also he have use cases to fetch the data based on (b1,c3) both also.

Is there any other ORM API which handle such scenario.



-
Atul Saroha
*Sr. Software Engineer*
*M*: +91 8447784271 *T*: +91 124-415-6069 *EXT*: 12369
Plot # 362, ASF Centre - Tower A, Udyog Vihar,
 Phase -4, Sector 18, Gurgaon, Haryana 122016, INDIA

Re: Cassandra Collections performance issue

[daemeon reiydelle]

I think the key to your problem might be around "we overwrite every value".
You are creating a large number of tombstones, forcing many reads to pull
current results. You would do well to rethink why you are having to to
overwrite values all the time under the same key. You would be better to
figure out haw to add values under a key then age off the old values. I
would say that (at least at scale) you have a classic anti-pattern in play.


*...*



*Daemeon C.M. ReiydelleUSA (+1) 415.501.0198London (+44) (0) 20 8144 9872*

On Mon, Feb 8, 2016 at 5:23 PM, Robert Coli  wrote:

> On Mon, Feb 8, 2016 at 2:10 PM, Agrawal, Pratik 
> wrote:
>
>> Recently we added one of the table fields from as Map in 
>> *Cassandra
>> 2.1.11*. Currently we read every field from Map and overwrite map
>> values. Map is of size 3. We saw that writes are 30-40% slower while reads
>> are 70-80% slower. Please find below some metrics that can help.
>>
>> My question is, Are there any known issues in Cassandra map performance?
>> As I understand it each of the CQL3 Map entry, maps to a column in
>> cassandra, with that assumption we are just creating 3 columns right? Any
>> insight on this issue would be helpful.
>>
>
> I have previously heard reports along similar lines, but in the other
> direction.
>
> eg - "I moved from a collection to a TEXT column with JSON in it, and my
> reads and writes both became much faster!"
>
> I'm not sure if the issue has been raised as an Apache Cassandra Jira, iow
> if it is a known and expected limitation as opposed to just a performance
> issue.
>
> If I were you, I would consider filing a repro case as a Jira ticket, and
> responding to this thread with its URL. :D
>
> =Rob
>
>

cassandra client testing

[Abdul Jabbar Azam]

Hello,

What do people do to test their cassandra client code? Do you

a) mock out the cassandra code
b) use a framework which simulates cassandra
c) actually use cassandra, perhaps inside docker


-- 
Regards

Abdul Jabbar Azam
twitter: @ajazam

Re: cassandra client testing

[Will Hayworth]

I've never seen Scassandra before--neat!

For what it's worth, we just use a test keyspace with a lower RF (that is
to say, 1). The tables are identical to our prod keyspace, but the
permissions are different for the user on our Bamboo instances so that we
can test things like table creation etc.

___
Will Hayworth
Developer, Engagement Engine
Atlassian

My pronoun is "they". 



On Tue, Feb 9, 2016 at 2:47 PM, Jeff Jirsa 
wrote:

> http://www.scassandra.org/
>
> From: Abdul Jabbar Azam
> Reply-To: "user@cassandra.apache.org"
> Date: Tuesday, February 9, 2016 at 2:23 PM
> To: "user@cassandra.apache.org"
> Subject: cassandra client testing
>
> Hello,
>
> What do people do to test their cassandra client code? Do you
>
> a) mock out the cassandra code
> b) use a framework which simulates cassandra
> c) actually use cassandra, perhaps inside docker
>
>
> --
> Regards
>
> Abdul Jabbar Azam
> twitter: @ajazam
>

Re: cassandra client testing

[Jeff Jirsa]

http://www.scassandra.org/

From:  Abdul Jabbar Azam
Reply-To:  "user@cassandra.apache.org"
Date:  Tuesday, February 9, 2016 at 2:23 PM
To:  "user@cassandra.apache.org"
Subject:  cassandra client testing

Hello, 

What do people do to test their cassandra client code? Do you 

a) mock out the cassandra code 
b) use a framework which simulates cassandra
c) actually use cassandra, perhaps inside docker


-- 
Regards

Abdul Jabbar Azam 
twitter: @ajazam



smime.p7s
Description: S/MIME cryptographic signature

[RELEASE] Apache Cassandra 3.3 released

[Jake Luciani]

The Cassandra team is pleased to announce the release of Apache Cassandra
version 3.3.

*This release contains a critical bug in 3.0 series[4].* If you have
installed version >= 3.0
you will need to run 'nodetool upgradesstables -a' on all nodes to receive
the fix.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.3 series. As always, please
pay
attention to the release notes[2] and Let us know[3] if you were to
encounter
any problem.

Enjoy!

[1]: http://goo.gl/V2lsST (CHANGES.txt)
[2]: http://goo.gl/5UBlNl (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA
[4]: https://issues.apache.org/jira/browse/CASSANDRA-11102

[RELEASE] Apache Cassandra 3.0.3 released

[Jake Luciani]

The Cassandra team is pleased to announce the release of Apache Cassandra
version 3.0.3.

*This release contains a critical bug in 3.0 series[4].* If you have
installed version >= 3.0
you will need to run 'nodetool upgradesstables -a' on all nodes to receive
the fix.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.0 series. As always, please
pay
attention to the release notes[2] and Let us know[3] if you were to
encounter
any problem.

Enjoy!

[1]: http://goo.gl/UtWBp4 (CHANGES.txt)
[2]: http://goo.gl/QGrGiy (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA
[4]: https://issues.apache.org/jira/browse/CASSANDRA-11102

Re: [RELEASE] Apache Cassandra 3.3 released

[Will Hayworth]

Pardon my ignorance, Jake--should we run upgradesstables -a after or before
we install 3.3?

Thanks! :)

___
Will Hayworth
Developer, Engagement Engine
Atlassian

My pronoun is "they". 



On Tue, Feb 9, 2016 at 10:50 AM, Jake Luciani  wrote:

> The Cassandra team is pleased to announce the release of Apache Cassandra
> version 3.3.
>
> *This release contains a critical bug in 3.0 series[4].* If you have
> installed version >= 3.0
> you will need to run 'nodetool upgradesstables -a' on all nodes to receive
> the fix.
>
> Apache Cassandra is a fully distributed database. It is the right choice
> when you need scalability and high availability without compromising
> performance.
>
>  http://cassandra.apache.org/
>
> Downloads of source and binary distributions are listed in our download
> section:
>
>  http://cassandra.apache.org/download/
>
> This version is a bug fix release[1] on the 3.3 series. As always, please
> pay
> attention to the release notes[2] and Let us know[3] if you were to
> encounter
> any problem.
>
> Enjoy!
>
> [1]: http://goo.gl/V2lsST (CHANGES.txt)
> [2]: http://goo.gl/5UBlNl (NEWS.txt)
> [3]: https://issues.apache.org/jira/browse/CASSANDRA
> [4]: https://issues.apache.org/jira/browse/CASSANDRA-11102
>
>

Re: CASSANDRA-8072

[Ted Yu]

On XX.YY :

#  service iptables status
iptables: Firewall is not running.

I put public IP address for listen address on a non-seed node. I still got:

INFO  18:14:17  OutboundTcpConnection using coalescing strategy DISABLED
ERROR 18:14:48  Exception encountered during startup
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]

Cheers

On Mon, Feb 8, 2016 at 5:36 PM, Stefania Alborghetti <
stefania.alborghe...@datastax.com> wrote:

> Have you checked that you can telnet from one node to the other using the
> same ip and the internode port?
>
> I would put the public IP addresses of the seeds in the seed list and set
> the listen address to the public IP address for each node.
>
> There was a similar discussion
> 
> recently that might help.
>
> On Tue, Feb 9, 2016 at 8:48 AM, Ted Yu  wrote:
>
>> Thanks for the help, Stefania.
>> By using "127.0.0.1" , I was able to start Cassandra on that seed node
>> (XX.YY).
>> However, on other nodes, I pointed seed to XX.YY and observed the
>> following ?
>> What did I miss ?
>>
>>
>> INFO  [main] 2016-02-08 16:44:56,607  OutboundTcpConnection.java:97 -
>> OutboundTcpConnection using coalescing strategy DISABLED
>> ERROR [main] 2016-02-08 16:45:27,626  CassandraDaemon.java:581 -
>> Exception encountered during startup
>> java.lang.RuntimeException: Unable to gossip with any seeds
>> at
>> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.StorageService.initServer(StorageService.java:721)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.StorageService.initServer(StorageService.java:612)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:389)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:335)
>> ~[dse-core-4.8.4.jar:4.8.4]
>> at
>> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at com.datastax.bdp.DseModule.main(DseModule.java:74)
>> [dse-core-4.8.4.jar:4.8.4]
>> INFO  [Thread-2] 2016-02-08 16:45:27,629  DseDaemon.java:418 - DSE
>> shutting down...
>>
>> On Mon, Feb 8, 2016 at 4:25 PM, Stefania Alborghetti <
>> stefania.alborghe...@datastax.com> wrote:
>>
>>> CASSANDRA-8072 is not going to help you because the code that fails
>>> (checkForEndpointCollision()) should not execute for seeds.
>>>
>>> I think the problem is that there are no seeds in cassandra.yaml:
>>>
>>> - seeds: "XX.YY"
>>>
>>> If listen_address is localhost then try:
>>>
>>> - seeds: "127.0.0.1"
>>>
>>>
>>> On Tue, Feb 9, 2016 at 5:58 AM, Ted Yu  wrote:
>>>
 If I apply the fix from CASSANDRA-8072 onto a 2.1.12 cluster, which
 files should I replace ?

 Thanks

 On Mon, Feb 8, 2016 at 1:07 PM, Bhuvan Rawal 
 wrote:

> Your config looks fine to me,  i tried reproducing the scenario by
> setting localhost in listen_address,rpc_address and seed list, and it
> worked fine, I had earlier the node local ip in the 3 fields and it was
> working fine.
>
> Looks like there is some other issue here.
>
> On Tue, Feb 9, 2016 at 12:49 AM, Ted Yu  wrote:
>
>> Here it is:
>> http://pastebin.com/QEdjtAj6
>>
>> XX.YY is localhost in this case.
>>
>> On Mon, Feb 8, 2016 at 11:03 AM, Bhuvan Rawal 
>> wrote:
>>
>>> could you paste your cassandra.yaml here, except for commented out
>>> lines?
>>>
>>> On Tue, Feb 9, 2016 at 12:30 AM, Ted Yu  wrote:
>>>
 The issue I described was observed on the seed node.

 Both rpc_address and listen_address point to localhost.

 bq. What addresses are there in the seed list?

 The IP of the seed node.

 I haven't come to starting 

stefania.alborghe...@datastax.com

[Ted Yu]

Hi,
I am using DSE 4.8.4
Here are the ports Cassandra daemon listens on:

tcp0  0 xx.yy:9042  0.0.0.0:*   LISTEN
 30773/java
tcp0  0 127.0.0.1:56498 0.0.0.0:*
LISTEN  30773/java
tcp0  0 xx.yy:7000  0.0.0.0:*   LISTEN
 30773/java
tcp0  0 127.0.0.1:7199  0.0.0.0:*
LISTEN  30773/java
tcp0  0 xx.yy:9160  0.0.0.0:*   LISTEN
 30773/java

Can you tell me how I can get to the DSE monitoring UI ?

Thanks

Re: cassandra client testing

[Abdul Jabbar Azam]

This looks really good. I can see in master that java driver 3.0 support
has been added.

I can't see out how to generate exceptions. I'd like to test my akka
supervisor hierarchy as well.

On Tue, 9 Feb 2016 at 22:48 Jeff Jirsa  wrote:

> http://www.scassandra.org/
>
> From: Abdul Jabbar Azam
> Reply-To: "user@cassandra.apache.org"
> Date: Tuesday, February 9, 2016 at 2:23 PM
> To: "user@cassandra.apache.org"
> Subject: cassandra client testing
>
> Hello,
>
> What do people do to test their cassandra client code? Do you
>
> a) mock out the cassandra code
> b) use a framework which simulates cassandra
> c) actually use cassandra, perhaps inside docker
>
>
> --
> Regards
>
> Abdul Jabbar Azam
> twitter: @ajazam
>
-- 
Regards

Abdul Jabbar Azam
twitter: @ajazam

Re: [RELEASE] Apache Cassandra 3.3 released

[Will Zhang]

Nice work guys. 

Just to confirm, if you upgrade from, 2.2.x say, directly to 3.3, you will 
*not* need to run upgradesstables, right? It seems pretty clear that the answer 
is no but I just wanted to make sure. Only needed if you got from a 3.x version?

Thank you. 

Sent from my iPhone

> On 9 Feb 2016, at 19:06, Jake Luciani  wrote:
> 
> No problem. Run it after you upgrade.
> 
>> On Tue, Feb 9, 2016 at 2:01 PM, Will Hayworth  
>> wrote:
>> Pardon my ignorance, Jake--should we run upgradesstables -a after or before 
>> we install 3.3?
>> 
>> Thanks! :)
>> 
>> ___
>> Will Hayworth
>> Developer, Engagement Engine
>> Atlassian
>> 
>> My pronoun is "they".
>> 
>> 
>> 
>>> On Tue, Feb 9, 2016 at 10:50 AM, Jake Luciani  wrote:
>>> The Cassandra team is pleased to announce the release of Apache Cassandra
>>> version 3.3.
>>> 
>>> This release contains a critical bug in 3.0 series[4]. If you have 
>>> installed version >= 3.0
>>> you will need to run 'nodetool upgradesstables -a' on all nodes to receive 
>>> the fix.
>>> 
>>> Apache Cassandra is a fully distributed database. It is the right choice
>>> when you need scalability and high availability without compromising
>>> performance.
>>> 
>>>  http://cassandra.apache.org/
>>> 
>>> Downloads of source and binary distributions are listed in our download
>>> section:
>>> 
>>>  http://cassandra.apache.org/download/
>>> 
>>> This version is a bug fix release[1] on the 3.3 series. As always, please 
>>> pay
>>> attention to the release notes[2] and Let us know[3] if you were to 
>>> encounter
>>> any problem.
>>> 
>>> Enjoy!
>>> 
>>> [1]: http://goo.gl/V2lsST (CHANGES.txt)
>>> [2]: http://goo.gl/5UBlNl (NEWS.txt)
>>> [3]: https://issues.apache.org/jira/browse/CASSANDRA
>>> [4]: https://issues.apache.org/jira/browse/CASSANDRA-11102
> 
> 
> 
> -- 
> http://twitter.com/tjake

Re: CASSANDRA-8072

[Stefania Alborghetti]

Can you make sure you changed the listen address on both hosts, using their
respective public IP address and that the seeds and cluster name are the
same on both hosts. The seeds should contain the public IP of the seed node.

Then verify you can telnet from one host to the other and vice-versa using
the internode port. This is normally 7000, the storage port in the yaml
file.

If you are still having problems,  you can log at TRACE level in
conf/logback.xml, this should log connection errors and gossip exchanges.




On Wed, Feb 10, 2016 at 2:28 AM, Ted Yu  wrote:

> On XX.YY :
>
> #  service iptables status
> iptables: Firewall is not running.
>
> I put public IP address for listen address on a non-seed node. I still
> got:
>
> INFO  18:14:17  OutboundTcpConnection using coalescing strategy DISABLED
> ERROR 18:14:48  Exception encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>
> Cheers
>
> On Mon, Feb 8, 2016 at 5:36 PM, Stefania Alborghetti <
> stefania.alborghe...@datastax.com> wrote:
>
>> Have you checked that you can telnet from one node to the other using the
>> same ip and the internode port?
>>
>> I would put the public IP addresses of the seeds in the seed list and set
>> the listen address to the public IP address for each node.
>>
>> There was a similar discussion
>> 
>> recently that might help.
>>
>> On Tue, Feb 9, 2016 at 8:48 AM, Ted Yu  wrote:
>>
>>> Thanks for the help, Stefania.
>>> By using "127.0.0.1" , I was able to start Cassandra on that seed node
>>> (XX.YY).
>>> However, on other nodes, I pointed seed to XX.YY and observed the
>>> following ?
>>> What did I miss ?
>>>
>>>
>>> INFO  [main] 2016-02-08 16:44:56,607  OutboundTcpConnection.java:97 -
>>> OutboundTcpConnection using coalescing strategy DISABLED
>>> ERROR [main] 2016-02-08 16:45:27,626  CassandraDaemon.java:581 -
>>> Exception encountered during startup
>>> java.lang.RuntimeException: Unable to gossip with any seeds
>>> at
>>> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337)
>>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>> at
>>> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
>>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>> at
>>> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
>>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>> at
>>> org.apache.cassandra.service.StorageService.initServer(StorageService.java:721)
>>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>> at
>>> org.apache.cassandra.service.StorageService.initServer(StorageService.java:612)
>>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>> at
>>> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:389)
>>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>> at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:335)
>>> ~[dse-core-4.8.4.jar:4.8.4]
>>> at
>>> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
>>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>> at com.datastax.bdp.DseModule.main(DseModule.java:74)
>>> [dse-core-4.8.4.jar:4.8.4]
>>> INFO  [Thread-2] 2016-02-08 16:45:27,629  DseDaemon.java:418 - DSE
>>> shutting down...
>>>
>>> On Mon, Feb 8, 2016 at 4:25 PM, Stefania Alborghetti <
>>> stefania.alborghe...@datastax.com> wrote:
>>>
 CASSANDRA-8072 is not going to help you because the code that fails
 (checkForEndpointCollision()) should not execute for seeds.

 I think the problem is that there are no seeds in cassandra.yaml:

 - seeds: "XX.YY"

 If listen_address is localhost then try:

 - seeds: "127.0.0.1"


 On Tue, Feb 9, 2016 at 5:58 AM, Ted Yu  wrote:

> If I apply the fix from CASSANDRA-8072 onto a 2.1.12 cluster, which
> files should I replace ?
>
> Thanks
>
> On Mon, Feb 8, 2016 at 1:07 PM, Bhuvan Rawal 
> wrote:
>
>> Your config looks fine to me,  i tried reproducing the scenario by
>> setting localhost in listen_address,rpc_address and seed list, and it
>> worked fine, I had earlier the node local ip in the 3 fields and it was
>> working fine.
>>
>> Looks like there is some other issue here.
>>
>> On Tue, Feb 9, 2016 at 12:49 

Re: cassandra client testing

[Abdul Jabbar Azam]

Hello Will,

I'll give scassandra a try first, otherwise use a test keyspace.

On Tue, 9 Feb 2016 at 22:52 Will Hayworth  wrote:

> I've never seen Scassandra before--neat!
>
> For what it's worth, we just use a test keyspace with a lower RF (that is
> to say, 1). The tables are identical to our prod keyspace, but the
> permissions are different for the user on our Bamboo instances so that we
> can test things like table creation etc.
>
> ___
> Will Hayworth
> Developer, Engagement Engine
> Atlassian
>
> My pronoun is "they". 
>
>
>
> On Tue, Feb 9, 2016 at 2:47 PM, Jeff Jirsa 
> wrote:
>
>> http://www.scassandra.org/
>>
>> From: Abdul Jabbar Azam
>> Reply-To: "user@cassandra.apache.org"
>> Date: Tuesday, February 9, 2016 at 2:23 PM
>> To: "user@cassandra.apache.org"
>> Subject: cassandra client testing
>>
>> Hello,
>>
>> What do people do to test their cassandra client code? Do you
>>
>> a) mock out the cassandra code
>> b) use a framework which simulates cassandra
>> c) actually use cassandra, perhaps inside docker
>>
>>
>> --
>> Regards
>>
>> Abdul Jabbar Azam
>> twitter: @ajazam
>>
>
> --
Regards

Abdul Jabbar Azam
twitter: @ajazam

Re: CASSANDRA-8072

[Ted Yu]

Forgot to update this thread.

Early afternoon I was able to get 5 node cluster up and running by
following the guideline below.

Thanks for the help.

On Tue, Feb 9, 2016 at 5:09 PM, Stefania Alborghetti <
stefania.alborghe...@datastax.com> wrote:

> Can you make sure you changed the listen address on both hosts, using
> their respective public IP address and that the seeds and cluster name are
> the same on both hosts. The seeds should contain the public IP of the seed
> node.
>
> Then verify you can telnet from one host to the other and vice-versa using
> the internode port. This is normally 7000, the storage port in the yaml
> file.
>
> If you are still having problems,  you can log at TRACE level in
> conf/logback.xml, this should log connection errors and gossip exchanges.
>
>
>
>
> On Wed, Feb 10, 2016 at 2:28 AM, Ted Yu  wrote:
>
>> On XX.YY :
>>
>> #  service iptables status
>> iptables: Firewall is not running.
>>
>> I put public IP address for listen address on a non-seed node. I still
>> got:
>>
>> INFO  18:14:17  OutboundTcpConnection using coalescing strategy DISABLED
>> ERROR 18:14:48  Exception encountered during startup
>> java.lang.RuntimeException: Unable to gossip with any seeds
>> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>
>> Cheers
>>
>> On Mon, Feb 8, 2016 at 5:36 PM, Stefania Alborghetti <
>> stefania.alborghe...@datastax.com> wrote:
>>
>>> Have you checked that you can telnet from one node to the other using
>>> the same ip and the internode port?
>>>
>>> I would put the public IP addresses of the seeds in the seed list and
>>> set the listen address to the public IP address for each node.
>>>
>>> There was a similar discussion
>>> 
>>> recently that might help.
>>>
>>> On Tue, Feb 9, 2016 at 8:48 AM, Ted Yu  wrote:
>>>
 Thanks for the help, Stefania.
 By using "127.0.0.1" , I was able to start Cassandra on that seed node
 (XX.YY).
 However, on other nodes, I pointed seed to XX.YY and observed the
 following ?
 What did I miss ?


 INFO  [main] 2016-02-08 16:44:56,607  OutboundTcpConnection.java:97 -
 OutboundTcpConnection using coalescing strategy DISABLED
 ERROR [main] 2016-02-08 16:45:27,626  CassandraDaemon.java:581 -
 Exception encountered during startup
 java.lang.RuntimeException: Unable to gossip with any seeds
 at
 org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.StorageService.initServer(StorageService.java:721)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.StorageService.initServer(StorageService.java:612)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:389)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:335)
 ~[dse-core-4.8.4.jar:4.8.4]
 at
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at com.datastax.bdp.DseModule.main(DseModule.java:74)
 [dse-core-4.8.4.jar:4.8.4]
 INFO  [Thread-2] 2016-02-08 16:45:27,629  DseDaemon.java:418 - DSE
 shutting down...

 On Mon, Feb 8, 2016 at 4:25 PM, Stefania Alborghetti <
 stefania.alborghe...@datastax.com> wrote:

> CASSANDRA-8072 is not going to help you because the code that fails
> (checkForEndpointCollision()) should not execute for seeds.
>
> I think the problem is that there are no seeds in cassandra.yaml:
>
> - seeds: "XX.YY"
>
> If listen_address is localhost then try:
>
> - seeds: "127.0.0.1"
>
>
> On Tue, Feb 9, 2016 at 5:58 AM, Ted Yu  wrote:
>
>> If I apply the fix from CASSANDRA-8072 onto a 2.1.12 cluster, which
>> files should I replace ?
>>
>> Thanks
>>
>> On Mon, Feb 8, 2016 at 1:07 PM, Bhuvan Rawal 

Re: [RELEASE] Apache Cassandra 3.3 released

[Jake Luciani]

Well typically you should run upgradesstables when you upgrade major
versions as well

https://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgradeCassandraDetails.html

On Tue, Feb 9, 2016 at 6:11 PM, Will Zhang  wrote:

> Nice work guys.
>
> Just to confirm, if you upgrade from, 2.2.x say, directly to 3.3, you will
> *not* need to run upgradesstables, right? It seems pretty clear that the
> answer is no but I just wanted to make sure. Only needed if you got from a
> 3.x version?
>
> Thank you.
>
> Sent from my iPhone
>
> On 9 Feb 2016, at 19:06, Jake Luciani  wrote:
>
> No problem. Run it after you upgrade.
>
> On Tue, Feb 9, 2016 at 2:01 PM, Will Hayworth 
> wrote:
>
>> Pardon my ignorance, Jake--should we run upgradesstables -a after or
>> before we install 3.3?
>>
>> Thanks! :)
>>
>> ___
>> Will Hayworth
>> Developer, Engagement Engine
>> Atlassian
>>
>> My pronoun is "they". 
>>
>>
>>
>> On Tue, Feb 9, 2016 at 10:50 AM, Jake Luciani  wrote:
>>
>>> The Cassandra team is pleased to announce the release of Apache Cassandra
>>> version 3.3.
>>>
>>> *This release contains a critical bug in 3.0 series[4].* If you have
>>> installed version >= 3.0
>>> you will need to run 'nodetool upgradesstables -a' on all nodes to
>>> receive the fix.
>>>
>>> Apache Cassandra is a fully distributed database. It is the right choice
>>> when you need scalability and high availability without compromising
>>> performance.
>>>
>>>  http://cassandra.apache.org/
>>>
>>> Downloads of source and binary distributions are listed in our download
>>> section:
>>>
>>>  http://cassandra.apache.org/download/
>>>
>>> This version is a bug fix release[1] on the 3.3 series. As always,
>>> please pay
>>> attention to the release notes[2] and Let us know[3] if you were to
>>> encounter
>>> any problem.
>>>
>>> Enjoy!
>>>
>>> [1]: http://goo.gl/V2lsST (CHANGES.txt)
>>> [2]: http://goo.gl/5UBlNl (NEWS.txt)
>>> [3]: https://issues.apache.org/jira/browse/CASSANDRA
>>> [4]: https://issues.apache.org/jira/browse/CASSANDRA-11102
>>>
>>>
>>
>
>
> --
> http://twitter.com/tjake
>
>


-- 
http://twitter.com/tjake

Re: CASSANDRA-8072

[Ted Yu]

One suggestion I have, after recent experience setting up a cluster, is
that Cassandra can provide better troubleshooting information to novice
such as I.

e.g. listen address for seed node (node whose public IP is the same as the
address given in seeds) shouldn't be set to localhost.

Thanks

On Tue, Feb 9, 2016 at 5:09 PM, Stefania Alborghetti <
stefania.alborghe...@datastax.com> wrote:

> Can you make sure you changed the listen address on both hosts, using
> their respective public IP address and that the seeds and cluster name are
> the same on both hosts. The seeds should contain the public IP of the seed
> node.
>
> Then verify you can telnet from one host to the other and vice-versa using
> the internode port. This is normally 7000, the storage port in the yaml
> file.
>
> If you are still having problems,  you can log at TRACE level in
> conf/logback.xml, this should log connection errors and gossip exchanges.
>
>
>
>
> On Wed, Feb 10, 2016 at 2:28 AM, Ted Yu  wrote:
>
>> On XX.YY :
>>
>> #  service iptables status
>> iptables: Firewall is not running.
>>
>> I put public IP address for listen address on a non-seed node. I still
>> got:
>>
>> INFO  18:14:17  OutboundTcpConnection using coalescing strategy DISABLED
>> ERROR 18:14:48  Exception encountered during startup
>> java.lang.RuntimeException: Unable to gossip with any seeds
>> at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>> at
>> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
>> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
>>
>> Cheers
>>
>> On Mon, Feb 8, 2016 at 5:36 PM, Stefania Alborghetti <
>> stefania.alborghe...@datastax.com> wrote:
>>
>>> Have you checked that you can telnet from one node to the other using
>>> the same ip and the internode port?
>>>
>>> I would put the public IP addresses of the seeds in the seed list and
>>> set the listen address to the public IP address for each node.
>>>
>>> There was a similar discussion
>>> 
>>> recently that might help.
>>>
>>> On Tue, Feb 9, 2016 at 8:48 AM, Ted Yu  wrote:
>>>
 Thanks for the help, Stefania.
 By using "127.0.0.1" , I was able to start Cassandra on that seed node
 (XX.YY).
 However, on other nodes, I pointed seed to XX.YY and observed the
 following ?
 What did I miss ?


 INFO  [main] 2016-02-08 16:44:56,607  OutboundTcpConnection.java:97 -
 OutboundTcpConnection using coalescing strategy DISABLED
 ERROR [main] 2016-02-08 16:45:27,626  CassandraDaemon.java:581 -
 Exception encountered during startup
 java.lang.RuntimeException: Unable to gossip with any seeds
 at
 org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1337)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:541)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:789)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.StorageService.initServer(StorageService.java:721)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.StorageService.initServer(StorageService.java:612)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:389)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at com.datastax.bdp.server.DseDaemon.setup(DseDaemon.java:335)
 ~[dse-core-4.8.4.jar:4.8.4]
 at
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:564)
 ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
 at com.datastax.bdp.DseModule.main(DseModule.java:74)
 [dse-core-4.8.4.jar:4.8.4]
 INFO  [Thread-2] 2016-02-08 16:45:27,629  DseDaemon.java:418 - DSE
 shutting down...

 On Mon, Feb 8, 2016 at 4:25 PM, Stefania Alborghetti <
 stefania.alborghe...@datastax.com> wrote:

> CASSANDRA-8072 is not going to help you because the code that fails
> (checkForEndpointCollision()) should not execute for seeds.
>
> I think the problem is that there are no seeds in cassandra.yaml:
>
> - seeds: "XX.YY"
>
> If listen_address is localhost then try:
>
> - seeds: "127.0.0.1"
>
>
> On Tue, Feb 9, 2016 at 5:58 AM, Ted Yu  wrote:
>
>> If I apply the fix from CASSANDRA-8072 onto a 

Re: [RELEASE] Apache Cassandra 3.3 released

[Jonathan Haddad]

Adding to Jake's point - it's a noop if you run upgrade sstables and it
doesn't need to be upgraded.  So just do it and save yourself a headache.

On Tue, Feb 9, 2016 at 7:10 PM Jake Luciani  wrote:

> Well typically you should run upgradesstables when you upgrade major
> versions as well
>
>
> https://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgradeCassandraDetails.html
>
> On Tue, Feb 9, 2016 at 6:11 PM, Will Zhang 
> wrote:
>
>> Nice work guys.
>>
>> Just to confirm, if you upgrade from, 2.2.x say, directly to 3.3, you
>> will *not* need to run upgradesstables, right? It seems pretty clear that
>> the answer is no but I just wanted to make sure. Only needed if you got
>> from a 3.x version?
>>
>> Thank you.
>>
>> Sent from my iPhone
>>
>> On 9 Feb 2016, at 19:06, Jake Luciani  wrote:
>>
>> No problem. Run it after you upgrade.
>>
>> On Tue, Feb 9, 2016 at 2:01 PM, Will Hayworth 
>> wrote:
>>
>>> Pardon my ignorance, Jake--should we run upgradesstables -a after or
>>> before we install 3.3?
>>>
>>> Thanks! :)
>>>
>>> ___
>>> Will Hayworth
>>> Developer, Engagement Engine
>>> Atlassian
>>>
>>> My pronoun is "they". 
>>>
>>>
>>>
>>> On Tue, Feb 9, 2016 at 10:50 AM, Jake Luciani  wrote:
>>>
 The Cassandra team is pleased to announce the release of Apache
 Cassandra
 version 3.3.

 *This release contains a critical bug in 3.0 series[4].* If you have
 installed version >= 3.0
 you will need to run 'nodetool upgradesstables -a' on all nodes to
 receive the fix.

 Apache Cassandra is a fully distributed database. It is the right choice
 when you need scalability and high availability without compromising
 performance.

  http://cassandra.apache.org/

 Downloads of source and binary distributions are listed in our download
 section:

  http://cassandra.apache.org/download/

 This version is a bug fix release[1] on the 3.3 series. As always,
 please pay
 attention to the release notes[2] and Let us know[3] if you were to
 encounter
 any problem.

 Enjoy!

 [1]: http://goo.gl/V2lsST (CHANGES.txt)
 [2]: http://goo.gl/5UBlNl (NEWS.txt)
 [3]: https://issues.apache.org/jira/browse/CASSANDRA
 [4]: https://issues.apache.org/jira/browse/CASSANDRA-11102


>>>
>>
>>
>> --
>> http://twitter.com/tjake
>>
>>
>
>
> --
> http://twitter.com/tjake
>

Re: best ORM for cassandra

[Nirmallya Mukherjee]

You are probably better off using the driver as you do not need an ORM. 
Cassandra is not a relational DB. You can find the documentation here 
http://docs.datastax.com/en/developer/driver-matrix/doc/common/driverMatrix.html.
 Pick the version that is applicable to your project.
Thanks,Nirmallya 

On Wednesday, 10 February 2016 12:31 PM, Raman Gugnani 
 wrote:
 

 Hi 
I am new to cassandra.
I am developing an application with cassandra.Which is the best ORM for 
cassandra?
-- 
Thanks & Regards

|  | 
| Raman Gugnani
Senior Software Engineer | CaMS |
| M: +91 8588892293 | T: 0124-660 | EXT: 14255
ASF Centre A | 2nd Floor | CA-2130 | Udyog Vihar Phase IV | 
Gurgaon | Haryana | India |

 |  |


|   |
| Disclaimer: This communication is for the sole use of the addressee and is 
confidential and privileged information. If you are not the intended recipient 
of this communication, you are prohibited from disclosing it and are required 
to delete it forthwith. Please note that the contents of this communication do 
not necessarily represent the views of Jasper Infotech Private Limited 
("Company"). E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses. The Company, therefore, does not 
accept liability for any loss caused due to this communication. Jasper Infotech 
Private Limited, Registered Office: 1st Floor, Plot 238, Okhla Industrial 
Estate, New Delhi - 110020 INDIA CIN: U72300DL2007PTC168097 |



  

best ORM for cassandra

[Raman Gugnani]

Hi

I am new to cassandra.

I am developing an application with cassandra.
Which is the best ORM for cassandra?

-- 
Thanks & Regards

Raman Gugnani
*Senior Software Engineer | CaMS*
M: +91 8588892293 | T: 0124-660 | EXT: 14255
ASF Centre A | 2nd Floor | CA-2130 | Udyog Vihar Phase IV |
Gurgaon | Haryana | India

*Disclaimer:* This communication is for the sole use of the addressee and
is confidential and privileged information. If you are not the intended
recipient of this communication, you are prohibited from disclosing it and
are required to delete it forthwith. Please note that the contents of this
communication do not necessarily represent the views of Jasper Infotech
Private Limited ("Company"). E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The Company,
therefore, does not accept liability for any loss caused due to this
communication. *Jasper Infotech Private Limited, Registered Office: 1st
Floor, Plot 238, Okhla Industrial Estate, New Delhi - 110020 INDIA CIN:
U72300DL2007PTC168097*