Hi Alive,
I think your observation is aligned to what I saw earlier during my
debugging session.
What you have is the compression in the wire between Java Driver and the C*
Server.
C* storage has a different flag and mechanism to compress its stored data
in the SSTable files
and as you can see,
The question related to C* driver and C* server itself. I'll ask it here
and at C* driver developers group too. Hope somebody can give me an answer
or maybe give an explanation why it happens as it happens.
This is the story about cassandra 2.2.7(I've checked it with the C* 3.* and
result is the
The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.2.9.
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 an
The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.1.17.
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 a
The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.0.11.
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 a
Aren't you using mesos Cassandra framework to manage your multiple clusters
? (Seen a presentation in cass summit)
What's wrong with your current mesos approach ?
I am also thinking it's better to split a large cluster into smallers
except if you also manage client layer that query cass and you can
Vote result:
8 +1 binding votes
1 +1 non-binding votes
0 +0 or -1 votes
This release vote passed, so I'll get the artifacts published.
--
Kind regards,
Michael
On 02/15/2017 07:15 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.0.11.
>
> sha1: 338226e042a22242645
Vote result:
8 +1 binding votes
2 +1 non-binding votes
0 +0 or -1 votes
This release vote passed, so I'll get the artifacts published.
--
Kind regards,
Michael
On 02/15/2017 07:16 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 2.2.9.
>
> sha1: 70a08f1c35091a36f7d9
Vote result:
8 +1 binding votes
1 +1 non-binding votes
0 +0 or -1 votes
This release vote passed, so I'll get the artifacts published.
--
Kind regards,
Michael
On 02/15/2017 07:16 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 2.1.17.
>
> sha1: 943db2488c8b62e1fbe
Agreed that async performs better than sync in general but the catch here
to me is the "order".
The whole point of async is to do out of order processing by which I mean
say if a request 1 comes in at time t1 and a request 2 comes in at time t2
where t1 < t2 and say now that t1 is taking longer to
10 matches
Mail list logo
