Re: Data repairing on one node questionably affects data on others

2016-04-26 Thread ssiv...@gmail.com
No, I didn't. I just want to understand how C* handle such case and what 
is a predictable behavior.


On 04/26/2016 02:51 PM, Jean Carlo wrote:

Did you use a backup of the keyspace system?

If not, you might do removenode of that node and re added to the 
cluster to re generate new tokens.



Saludos

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay

On Tue, Apr 26, 2016 at 12:06 AM, ssiv...@gmail.com 
<mailto:ssiv...@gmail.com> <ssiv...@gmail.com 
<mailto:ssiv...@gmail.com>> wrote:


Hi All,

I have cluster of 7 nodes completely balanced (each node owns
~500GB of data).
And I have one keyspace and one table and three replicas. Than, I
just failed one node's disk, replace it with a new one and started
repairing.
During that process I noticed that additional two nodes have
started getting data, and at the end of the repairing three nodes
have twice more data than at the beginning.
I'm curious, is it a normal behavior for Cassandra? Why not only
one node, but three, have gotten data during repairing? May be
it's because of clocks skew?

Thanks!

-- 
best regards,

Sergey




--
Thanks,
Serj



Data repairing on one node questionably affects data on others

2016-04-25 Thread ssiv...@gmail.com

Hi All,

I have cluster of 7 nodes completely balanced (each node owns ~500GB of 
data).
And I have one keyspace and one table and three replicas. Than, I just 
failed one node's disk, replace it with a new one and started repairing.
During that process I noticed that additional two nodes have started 
getting data, and at the end of the repairing three nodes have twice 
more data than at the beginning.
I'm curious, is it a normal behavior for Cassandra? Why not only one 
node, but three, have gotten data during repairing? May be it's because 
of clocks skew?


Thanks!

--
best regards,
Sergey



Re: Cassandra Upgrade 3.0.x vs 3.x (Tick-Tock Release)

2016-03-15 Thread ssiv...@gmail.com

Note, that DataStax Enterprise still uses C* v2.1..

On 03/15/2016 08:25 PM, Kathiresan S wrote:

Thank you all !

Thanks,
Kathir


On Tue, Mar 15, 2016 at 5:50 AM, ssiv...@gmail.com 
<mailto:ssiv...@gmail.com> <ssiv...@gmail.com 
<mailto:ssiv...@gmail.com>> wrote:


I think that it's not ready, since it has critical bugs. See
emails about C* memory leaks


On 03/15/2016 01:15 AM, Robert Coli wrote:

On Mon, Mar 14, 2016 at 12:40 PM, Kathiresan S
<kathiresanselva...@gmail.com
<mailto:kathiresanselva...@gmail.com>> wrote:

We are planning for Cassandra upgrade in our production
environment.
Which version of Cassandra is stable and is advised to
upgrade to, at the moment?



https://www.eventbrite.com/engineering/what-version-of-cassandra-should-i-run/

(IOW, you should run either 2.1.MAX or 2.2.5)

Relatively soon, the answer will be "3.0.x", probably around the
time where 3.0.x is >= 6.

After this series, the change in release cadence may change the
above rule of thumb.

=Rob


-- 
Thanks,

Serj




--
Thanks,
Serj



Re: Cassandra Upgrade 3.0.x vs 3.x (Tick-Tock Release)

2016-03-15 Thread ssiv...@gmail.com
I think that it's not ready, since it has critical bugs. See emails 
about C* memory leaks


On 03/15/2016 01:15 AM, Robert Coli wrote:
On Mon, Mar 14, 2016 at 12:40 PM, Kathiresan S 
> 
wrote:


We are planning for Cassandra upgrade in our production environment.
Which version of Cassandra is stable and is advised to upgrade to,
at the moment?


https://www.eventbrite.com/engineering/what-version-of-cassandra-should-i-run/

(IOW, you should run either 2.1.MAX or 2.2.5)

Relatively soon, the answer will be "3.0.x", probably around the time 
where 3.0.x is >= 6.


After this series, the change in release cadence may change the above 
rule of thumb.


=Rob


--
Thanks,
Serj



Re: C* memory leak during compaction

2016-03-15 Thread ssiv...@gmail.com

Duplicate the answer from Russell Hatch

On 03/14/2016 07:32 PM, Russell Hatch wrote:

Of course, no problem.

On Sat, Mar 12, 2016 at 3:35 PM, ssiv...@gmail.com 
<mailto:ssiv...@gmail.com> <ssiv...@gmail.com 
<mailto:ssiv...@gmail.com>> wrote:


Hi,

Thank you for you reply!
The thing is that I've only inserted the data and just waiting
until compaction is finished. C* process allocates all available
memory during compaction... I'd added swap ~700GB and C* has
occupied it too..

Will itl be "ok" if I duplicate your answer to user@cassandra ?

On 03/12/2016 02:46 AM, Russell Hatch wrote:

Hi there -- not sure if anyone got back to you on this question.
I think I saw your question on irc the other day -- I'm not aware
of any memory specific issues with 2.2.5.

It might be worthwhile to see if you have any very large
partitions in your database, and any potential code that could be
trying to retrieve those very large partitions -- I think that
could be one source for a problem such as this.

You might get some more traction on your question using the
regular cassandra mailing list (this list is for development of
cassandra itself, not development with cassandra).

Cheers,

Russ

On Fri, Mar 11, 2016 at 5:38 AM, ssiv...@gmail.com
<mailto:ssiv...@gmail.com> <ssiv...@gmail.com
<mailto:ssiv...@gmail.com>> wrote:

I have 7 nodes of C* v2.2.5 running on CentOS 7 and using
jemalloc for dynamic storage allocation.
Use only one keyspace and one table with Leveled compaction
strategy.
I've loaded ~500 GB of data into the cluster with replication
factor equals to 3 and waiting until compaction is finished.
But during compaction each of the C* nodes allocates all the
available memory (~128GB) and just stops its process.

This is a known bug ?

-- 
Thanks,

Serj




-- 
Thanks,

Serj




--
Thanks,
Serj



Re: Cassandra 3.2.1: Memory leak?

2016-03-12 Thread ssiv...@gmail.com

Hi, I'll duplicate here my email with the same issue

"/I have 7 nodes of C* v2.2.5 running on CentOS 7 and using jemalloc for 
dynamic storage allocation.

Use only one keyspace and one table with Leveled compaction strategy.
I've loaded ~500 GB of data into the cluster with replication factor 
equals to 3 and waiting until compaction is finished. But during 
compaction each of the C* nodes allocates all the available memory 
(~128GB) and just stops its process.

This is a known bug ? /"

On 03/13/2016 12:56 AM, Mohamed Lrhazi wrote:

Hello,

We installed Datastax community edition, on 8 nodes, RHEL7. We 
inserted some 7 billion rows into a pretty simple table. the inserts 
seem to have completed without issues. but ever since, we find that 
the nodes reliably run out of RAM after few hours, without any user 
activity at all. No reads nor write are sent at all.  What should we 
look for to try and identify root cause?



[root@avesterra-prod-1 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)
[root@avesterra-prod-1 ~]# rpm -qa| grep datastax
datastax-ddc-3.2.1-1.noarch
datastax-ddc-tools-3.2.1-1.noarch
[root@avesterra-prod-1 ~]#

The nodes had 8 GB RAM, which we doubled twice and now are trying with 
40GB... they still manage to consume it all and cause oom_killer to 
kick in.


Pretty much all the settings are the default ones the installation 
created.


Thanks,
Mohamed.


--
Thanks,
Serj



Re: Possible to adjust tokens on a vnode cluster?

2016-01-21 Thread ssiv...@gmail.com

Hello John!

I'm just wonder how often one of your cluster nodes 
failed/crashed/go_down or meets disks crashing? Looking for some sort of 
probability of hardware failure..


Thank you.

On 01/19/2016 09:21 PM, John Sumsion wrote:


I have a 24 node cluster, with vnodes set to 256.


'nodetool status ' looks like this for our keyspace:


UN  588.23 GB  256 11.0% 
0c8708a7-b962-4fc9-996c-617da642d9ee  1a
UN  601.33 GB  256 11.3% 
5ef60730-0b01-4a8b-a578-d828cdf78a1f  1b
UN  613.02 GB  256 11.5% 
dddc78b1-7dc2-4e9f-8e8a-1b52595aa0e3  1a
UN  620.76 GB  256 11.7% 
87ac93ff-dc8e-4cd5-842c-0389ce016d70  1b
UN  631.81 GB  256 11.9% 
8e1416aa-3e75-4ab5-a2a6-49d26f514115  1d
UN  634.65 GB  256 11.9% 
3c97f722-16f5-455c-8f58-71c07ad93d25  1b
UN  634.79 GB  256 11.9% 
3e3d41bd-d6e8-4a7e-aee2-7ea16b1dadb9  1d
UN  637.05 GB  256 12.0% 
2f26f19a-c88f-4cbe-b865-155c0b66bff0  1b
UN  637.83 GB  256 12.0% 
6385e073-5b48-49b3-a85b-e7511fa8b3a0  1a
UN  638.05 GB  256 12.1% 
382681e5-c060-4594-ae2a-062a324c12d4  1d
UN  660.22 GB  256 12.4% 
ea6aad23-7d93-4989-8898-7505df51298f  1d
UN  674.98 GB  256 12.6% 
7d372371-c23f-4235-9e3c-cf030fb52ab3  1a
UN  676.22 GB  256 12.7% 
41c4cb98-91ae-43a6-9bc4-11aa6106faad  1d
UN  680.15 GB  256 12.7% 
65ac3aef-8a9b-423d-83fb-ed8e41f88ccc  1a
UN  681.35 GB  256 12.8% 
e38efc6a-e7eb-4d8e-9069-a0b099bea96e  1d
UN  693.19 GB  256 13.0% 
2b9a5d3e-8529-47fe-8d2c-13553a8df91f  1b
UN  696.92 GB  256 13.0% 
46382cd1-402c-4200-858c-100dade03fc5  1d
UN  698.17 GB  256 13.1% 
a68107e7-8e1a-469e-8dd1-e2d87445fd47  1b
UN  698.92 GB  256 13.1% 
662338a7-1f5c-4eaa-926e-9e9fda926504  1a
UN  699.26 GB  256 13.1% 
e7c15c56-80e6-4961-9cd9-c1302fbf2026  1a
UN  702.98 GB  256 13.2% 
461baba0-60f3-423a-a5cf-e0c482da2dbf  1b
UN  710.27 GB  256 13.3% 
ffa9700d-50ef-4b23-92d9-18f8029c8cd6  1d
UN  740.63 GB  256 13.8% 
d9c6e2a1-2193-4f32-8426-3bd7ad8bf679  1a
UN  744.12 GB  256 13.9% 
ff841094-7624-4dc5-b480-f39138b7f17c  1b


First, the difference in disk usage between 588G (lowest) and 744G 
(highest) is significant - at 156G.  I'm sure it's probably a weird 
pattern in our partition keys, but we can't predict that until we get 
the data loaded.



Maybe someone will advise against using vnodes altogether, but we need 
to be able to add 3 nodes for extra capacity and would like not to 
have to rewrite the vnode token assignment code in order to figure out 
a rack-safe token reassignment.



Given the above, is there any way to manually adjust tokens (while 
still using vnodes) so that we can balance the disk usage out?  If so, 
is there an easy way to do that in a rack-safe manner?



Thanks,

John...



--
Thanks,
Serj



Re: Cassandra Java Driver

2016-01-04 Thread ssiv...@gmail.com

Trying to connect to C* v3.1.1 cluster.
It works nice with cqlsh

/$ cqlsh//
//Connected to Test Cluster at 127.0.0.1:9042.//
//[cqlsh 5.0.1 | Cassandra 3.1.1 | CQL spec 3.3.1 | Native protocol v4]/

But doesn't work with /cassandra-driver-core/.
I use next mvn deps:

///
//com.datastax.cassandra//
//cassandra-driver-core//
//3.0.0-rc1//

//

//org.apache.cassandra//
//cassandra-all//
//3.1.1//
///

And connect in the next code:

/Cluster.Builder builder = Cluster.builder()
.withProtocolVersion(ProtocolVersion.V4)
.withPort(9042)
.addContactPoint("127.0.0.1");

cluster = builder.build();
Metadata metadata = cluster.getMetadata();/

And it doesn't work. I get the exception:
/com.datastax.driver.core.exceptions.NoHostAvailableException: All 
host(s) tried for query failed (tried: /127.0.0.1:9042 
(com.datastax.driver.core.exceptions.TransportException: [/127.0.0.1] 
Cannot connect))//
//at 
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:231)//
//at 
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)//

//at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1382)//
//at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:393)/

Everything is ok for C* 2.2.4 when I use
/
$ cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.2.4 | CQL spec 3.3.1 | Native protocol v4]/

///
//com.datastax.cassandra//
//cassandra-driver-core//
//2.1.9//

//

//org.apache.cassandra//
//cassandra-all//
//3.1.1//
///

/Cluster.Builder builder = Cluster.builder()
.withPort(9042)
.addContactPoint("127.0.0.1");


/C* java driver isn't ready to use?/

/
On 12/30/2015 04:48 PM, DuyHai Doan wrote:


Check protocol version when you create your Cluster object on the 
client side


Le 30 déc. 2015 13:33, "ssiv...@gmail.com <mailto:ssiv...@gmail.com>" 
<ssiv...@gmail.com <mailto:ssiv...@gmail.com>> a écrit :


I've just tried to use cassandra-driver-core-3.0.0_rc1 and
cassandra-driver-core-3.0.0_beta1 with C* 2.2.4
(cassandra-all-2.2.4). And neither of them can connect to the
local cluster. But  cassandra-driver-core-2.1.9. Am I doing wrong?


Happy New Year!

On 12/28/2015 04:08 PM, Alexandre Dutra wrote:

FYI, Java driver 3.0.0-rc1 has just been released

<https://groups.google.com/a/lists.datastax.com/d/msg/java-driver-user/779VHUOVcOM/h7fYfOyOBQAJ>.


On Sat, Dec 26, 2015 at 11:15 AM Brice Dutheil
<brice.duth...@gmail.com <mailto:brice.duth...@gmail.com>> wrote:

Not yet. The latestest DSE (4.8.3) is shipped with a patched
version of Cassandra 2.11.
You can find this information on their website.

4.8 Release note :

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/RNdse.html
From this page in the menu you can navigate and unroll the
menu /Product Guide/ > /Datastax Enterprise/ it should
contain DSE versions.

And there's always other sources like the blog.

Cassandra 3.x should be shipped with DSE 5.x early next year.


HTH

-- Brice

On Sat, Dec 26, 2015 at 3:46 AM, Noorul Islam Kamal Malmiyoda
<noo...@noorul.com <mailto:noo...@noorul.com>> wrote:

Is DSE shipping with 3.x ?

Thanks and Regards
Noorul

On Fri, Dec 25, 2015 at 9:07 PM, Alexandre Dutra
<alexandre.du...@datastax.com
<mailto:alexandre.du...@datastax.com>> wrote:
> Hi Jean,
>
> You should use 3.0.0-beta1.
>
> TL;DR
>
> DataStax Java driver series 2.2.x has been discontinued
in favor of series
> 3.x; we explained why in this mail to the Java driver
mailing list. We do
> not advise users to use this series.
>
> So the most recent driver version compatible with all
versions of Cassandra,
> including 2.2 and 3.x, is now 3.0.0-beta1, although
3.0.0-rc1 will be
> released very soon.
>
> In spite of its "beta" label, version 3.0.0-beta1 has
been thoroughly tested
> against all versions of Cassandra and is definitely
production-ready... as
> long as the Cassandra version in use is also
production-ready. Note however
> that Cassandra 2.2 and 3.0 are quite recent and most
companies AFAICT do not
> consider them yet as production-ready.
>
> Hope that helps,
>
> Alexandre
>
 

Re: Cassandra Java Driver

2015-12-30 Thread ssiv...@gmail.com
I've just tried to use cassandra-driver-core-3.0.0_rc1 and 
cassandra-driver-core-3.0.0_beta1 with C* 2.2.4 (cassandra-all-2.2.4). 
And neither of them can connect to the local cluster. But  
cassandra-driver-core-2.1.9. Am I doing wrong?



Happy New Year!

On 12/28/2015 04:08 PM, Alexandre Dutra wrote:
FYI, Java driver 3.0.0-rc1 has just been released 
. 



On Sat, Dec 26, 2015 at 11:15 AM Brice Dutheil 
> wrote:


Not yet. The latestest DSE (4.8.3) is shipped with a patched
version of Cassandra 2.11.
You can find this information on their website.

4.8 Release note :

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/RNdse.html
From this page in the menu you can navigate and unroll the menu
/Product Guide/ > /Datastax Enterprise/ it should contain DSE
versions.

And there's always other sources like the blog.

Cassandra 3.x should be shipped with DSE 5.x early next year.


HTH

-- Brice

On Sat, Dec 26, 2015 at 3:46 AM, Noorul Islam Kamal Malmiyoda
> wrote:

Is DSE shipping with 3.x ?

Thanks and Regards
Noorul

On Fri, Dec 25, 2015 at 9:07 PM, Alexandre Dutra
> wrote:
> Hi Jean,
>
> You should use 3.0.0-beta1.
>
> TL;DR
>
> DataStax Java driver series 2.2.x has been discontinued in
favor of series
> 3.x; we explained why in this mail to the Java driver
mailing list. We do
> not advise users to use this series.
>
> So the most recent driver version compatible with all
versions of Cassandra,
> including 2.2 and 3.x, is now 3.0.0-beta1, although
3.0.0-rc1 will be
> released very soon.
>
> In spite of its "beta" label, version 3.0.0-beta1 has been
thoroughly tested
> against all versions of Cassandra and is definitely
production-ready... as
> long as the Cassandra version in use is also
production-ready. Note however
> that Cassandra 2.2 and 3.0 are quite recent and most
companies AFAICT do not
> consider them yet as production-ready.
>
> Hope that helps,
>
> Alexandre
>
>
> On Tue, Dec 22, 2015 at 4:40 PM Jean Tremblay
> > wrote:
>>
>> Hi,
>> Which Java Driver is suited for Cassandra 2.2.x. ?
>> I see datastax 3.0.0 beta1 and datastax 2.2.0 rc3...
>> Are they suited for production?
>> Is there anything better?
>> Thanks for your comments and replies?
>> Jean
>
> --
> Alexandre Dutra
> Driver & Tools Engineer @ DataStax


--
Alexandre Dutra
Driver & Tools Engineer @ DataStax


--
Thanks,
Serj



Re: Cassandra Java Driver

2015-12-30 Thread ssiv...@gmail.com

I set it to ProtocolVersion.V4 (the highest).

On 12/30/2015 04:48 PM, DuyHai Doan wrote:


Check protocol version when you create your Cluster object on the 
client side


Le 30 déc. 2015 13:33, "ssiv...@gmail.com <mailto:ssiv...@gmail.com>" 
<ssiv...@gmail.com <mailto:ssiv...@gmail.com>> a écrit :


I've just tried to use cassandra-driver-core-3.0.0_rc1 and
cassandra-driver-core-3.0.0_beta1 with C* 2.2.4
(cassandra-all-2.2.4). And neither of them can connect to the
local cluster. But  cassandra-driver-core-2.1.9. Am I doing wrong?


Happy New Year!

On 12/28/2015 04:08 PM, Alexandre Dutra wrote:

FYI, Java driver 3.0.0-rc1 has just been released

<https://groups.google.com/a/lists.datastax.com/d/msg/java-driver-user/779VHUOVcOM/h7fYfOyOBQAJ>.


On Sat, Dec 26, 2015 at 11:15 AM Brice Dutheil
<brice.duth...@gmail.com <mailto:brice.duth...@gmail.com>> wrote:

Not yet. The latestest DSE (4.8.3) is shipped with a patched
version of Cassandra 2.11.
You can find this information on their website.

4.8 Release note :

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/RNdse.html
From this page in the menu you can navigate and unroll the
menu /Product Guide/ > /Datastax Enterprise/ it should
contain DSE versions.

And there's always other sources like the blog.

Cassandra 3.x should be shipped with DSE 5.x early next year.


HTH

-- Brice

On Sat, Dec 26, 2015 at 3:46 AM, Noorul Islam Kamal Malmiyoda
<noo...@noorul.com <mailto:noo...@noorul.com>> wrote:

Is DSE shipping with 3.x ?

Thanks and Regards
Noorul

On Fri, Dec 25, 2015 at 9:07 PM, Alexandre Dutra
<alexandre.du...@datastax.com
<mailto:alexandre.du...@datastax.com>> wrote:
> Hi Jean,
>
> You should use 3.0.0-beta1.
>
> TL;DR
>
> DataStax Java driver series 2.2.x has been discontinued
in favor of series
> 3.x; we explained why in this mail to the Java driver
mailing list. We do
> not advise users to use this series.
>
> So the most recent driver version compatible with all
versions of Cassandra,
> including 2.2 and 3.x, is now 3.0.0-beta1, although
3.0.0-rc1 will be
> released very soon.
>
> In spite of its "beta" label, version 3.0.0-beta1 has
been thoroughly tested
> against all versions of Cassandra and is definitely
production-ready... as
> long as the Cassandra version in use is also
production-ready. Note however
> that Cassandra 2.2 and 3.0 are quite recent and most
companies AFAICT do not
> consider them yet as production-ready.
>
> Hope that helps,
>
> Alexandre
>
>
> On Tue, Dec 22, 2015 at 4:40 PM Jean Tremblay
> <jean.tremb...@zen-innovations.com
<mailto:jean.tremb...@zen-innovations.com>> wrote:
>>
>> Hi,
>> Which Java Driver is suited for Cassandra 2.2.x. ?
>> I see datastax 3.0.0 beta1 and datastax 2.2.0 rc3...
>> Are they suited for production?
>> Is there anything better?
>> Thanks for your comments and replies?
>> Jean
>
> --
> Alexandre Dutra
> Driver & Tools Engineer @ DataStax


-- 
Alexandre Dutra

Driver & Tools Engineer @ DataStax


-- 
Thanks,

Serj



--
Thanks,
Serj



Re: Cassandra Java Driver

2015-12-30 Thread ssiv...@gmail.com
Sorry, setting protocol version to V4 doesn't work for C* 3.1.1. I sure, 
for C* 2.2.4 it will work...Will check


On 12/30/2015 04:48 PM, DuyHai Doan wrote:


Check protocol version when you create your Cluster object on the 
client side


Le 30 déc. 2015 13:33, "ssiv...@gmail.com <mailto:ssiv...@gmail.com>" 
<ssiv...@gmail.com <mailto:ssiv...@gmail.com>> a écrit :


I've just tried to use cassandra-driver-core-3.0.0_rc1 and
cassandra-driver-core-3.0.0_beta1 with C* 2.2.4
(cassandra-all-2.2.4). And neither of them can connect to the
local cluster. But  cassandra-driver-core-2.1.9. Am I doing wrong?


Happy New Year!

On 12/28/2015 04:08 PM, Alexandre Dutra wrote:

FYI, Java driver 3.0.0-rc1 has just been released

<https://groups.google.com/a/lists.datastax.com/d/msg/java-driver-user/779VHUOVcOM/h7fYfOyOBQAJ>.


On Sat, Dec 26, 2015 at 11:15 AM Brice Dutheil
<brice.duth...@gmail.com <mailto:brice.duth...@gmail.com>> wrote:

Not yet. The latestest DSE (4.8.3) is shipped with a patched
version of Cassandra 2.11.
You can find this information on their website.

4.8 Release note :

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/RNdse.html
From this page in the menu you can navigate and unroll the
menu /Product Guide/ > /Datastax Enterprise/ it should
contain DSE versions.

And there's always other sources like the blog.

Cassandra 3.x should be shipped with DSE 5.x early next year.


HTH

-- Brice

On Sat, Dec 26, 2015 at 3:46 AM, Noorul Islam Kamal Malmiyoda
<noo...@noorul.com <mailto:noo...@noorul.com>> wrote:

Is DSE shipping with 3.x ?

Thanks and Regards
Noorul

On Fri, Dec 25, 2015 at 9:07 PM, Alexandre Dutra
<alexandre.du...@datastax.com
<mailto:alexandre.du...@datastax.com>> wrote:
> Hi Jean,
>
> You should use 3.0.0-beta1.
>
> TL;DR
>
> DataStax Java driver series 2.2.x has been discontinued
in favor of series
> 3.x; we explained why in this mail to the Java driver
mailing list. We do
> not advise users to use this series.
>
> So the most recent driver version compatible with all
versions of Cassandra,
> including 2.2 and 3.x, is now 3.0.0-beta1, although
3.0.0-rc1 will be
> released very soon.
>
> In spite of its "beta" label, version 3.0.0-beta1 has
been thoroughly tested
> against all versions of Cassandra and is definitely
production-ready... as
> long as the Cassandra version in use is also
production-ready. Note however
> that Cassandra 2.2 and 3.0 are quite recent and most
companies AFAICT do not
> consider them yet as production-ready.
>
> Hope that helps,
>
> Alexandre
>
>
> On Tue, Dec 22, 2015 at 4:40 PM Jean Tremblay
> <jean.tremb...@zen-innovations.com
<mailto:jean.tremb...@zen-innovations.com>> wrote:
>>
>> Hi,
>> Which Java Driver is suited for Cassandra 2.2.x. ?
>> I see datastax 3.0.0 beta1 and datastax 2.2.0 rc3...
>> Are they suited for production?
>> Is there anything better?
>> Thanks for your comments and replies?
>> Jean
>
> --
> Alexandre Dutra
> Driver & Tools Engineer @ DataStax


-- 
Alexandre Dutra

Driver & Tools Engineer @ DataStax


-- 
Thanks,

Serj



--
Thanks,
Serj



Re: Cassandra Java Driver

2015-12-30 Thread ssiv...@gmail.com

No...It doesn't work for C* 2.2.4 too..(

On 12/30/2015 04:48 PM, DuyHai Doan wrote:


Check protocol version when you create your Cluster object on the 
client side


Le 30 déc. 2015 13:33, "ssiv...@gmail.com <mailto:ssiv...@gmail.com>" 
<ssiv...@gmail.com <mailto:ssiv...@gmail.com>> a écrit :


I've just tried to use cassandra-driver-core-3.0.0_rc1 and
cassandra-driver-core-3.0.0_beta1 with C* 2.2.4
(cassandra-all-2.2.4). And neither of them can connect to the
local cluster. But  cassandra-driver-core-2.1.9. Am I doing wrong?


Happy New Year!

On 12/28/2015 04:08 PM, Alexandre Dutra wrote:

FYI, Java driver 3.0.0-rc1 has just been released

<https://groups.google.com/a/lists.datastax.com/d/msg/java-driver-user/779VHUOVcOM/h7fYfOyOBQAJ>.


On Sat, Dec 26, 2015 at 11:15 AM Brice Dutheil
<brice.duth...@gmail.com <mailto:brice.duth...@gmail.com>> wrote:

Not yet. The latestest DSE (4.8.3) is shipped with a patched
version of Cassandra 2.11.
You can find this information on their website.

4.8 Release note :

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/RNdse.html
From this page in the menu you can navigate and unroll the
menu /Product Guide/ > /Datastax Enterprise/ it should
contain DSE versions.

And there's always other sources like the blog.

Cassandra 3.x should be shipped with DSE 5.x early next year.


HTH

-- Brice

On Sat, Dec 26, 2015 at 3:46 AM, Noorul Islam Kamal Malmiyoda
<noo...@noorul.com <mailto:noo...@noorul.com>> wrote:

Is DSE shipping with 3.x ?

Thanks and Regards
Noorul

On Fri, Dec 25, 2015 at 9:07 PM, Alexandre Dutra
<alexandre.du...@datastax.com
<mailto:alexandre.du...@datastax.com>> wrote:
> Hi Jean,
>
> You should use 3.0.0-beta1.
>
> TL;DR
>
> DataStax Java driver series 2.2.x has been discontinued
in favor of series
> 3.x; we explained why in this mail to the Java driver
mailing list. We do
> not advise users to use this series.
>
> So the most recent driver version compatible with all
versions of Cassandra,
> including 2.2 and 3.x, is now 3.0.0-beta1, although
3.0.0-rc1 will be
> released very soon.
>
> In spite of its "beta" label, version 3.0.0-beta1 has
been thoroughly tested
> against all versions of Cassandra and is definitely
production-ready... as
> long as the Cassandra version in use is also
production-ready. Note however
> that Cassandra 2.2 and 3.0 are quite recent and most
companies AFAICT do not
> consider them yet as production-ready.
>
> Hope that helps,
>
> Alexandre
>
>
> On Tue, Dec 22, 2015 at 4:40 PM Jean Tremblay
> <jean.tremb...@zen-innovations.com
<mailto:jean.tremb...@zen-innovations.com>> wrote:
>>
>> Hi,
>> Which Java Driver is suited for Cassandra 2.2.x. ?
>> I see datastax 3.0.0 beta1 and datastax 2.2.0 rc3...
>> Are they suited for production?
>> Is there anything better?
>> Thanks for your comments and replies?
>> Jean
>
> --
> Alexandre Dutra
> Driver & Tools Engineer @ DataStax


-- 
Alexandre Dutra

Driver & Tools Engineer @ DataStax


-- 
Thanks,

Serj



--
Thanks,
Serj



Re: SSTable structure

2015-03-30 Thread ssiv...@gmail.com

+1

On 03/30/2015 11:38 AM, Pierre wrote:

Hi,

Does anyone know if there is a more complete and up to date 
documentation about the sstable files structure (data, index, stats 
etc.) than this one : 
http://wiki.apache.org/cassandra/ArchitectureSSTable


I'm looking for a full specification, with schema of the structure if 
possible.


Thanks.


--
Thanks,
Serj



Commitlog activities

2015-02-23 Thread ssiv...@gmail.com

Hi!

I have the following keyspaces

cqlsh SELECT * FROM system.schema_keyspaces;
 keyspace_name  | durable_writes | 
strategy_class  | 
strategy_options

---++-+
system   |   True| 
org.apache.cassandra.locator.LocalStrategy | {}
 system_traces   |  False| 
org.apache.cassandra.locator.SimpleStrategy  | {replication_factor:2}
 a1_ks |  False| 
org.apache.cassandra.locator.SimpleStrategy  | {replication_factor:1}


I have two disks. Data directory is on sda. Commitlog is on sdb.
I do 100% writes into a1_ks.user_table .

Watching IO activities I noticed that C* write something (mutations) 
into commitlog. But it's strange because I disabled durable writes for 
a1_ks.

May be it's system activities and they are flushed into commitlog?


--
Thanks,
Serj



memtable_offheap_space_in_mb and memtable_cleanup_threshold

2015-02-23 Thread ssiv...@gmail.com

Hi everyone!

I do write only workload (into one column family) and experiment with 
offheap-objects memtable space.


I set parameters to:/
//memtable_offheap_space_in_mb = 51200  # 50Gb//
//memtable_cleanup_threshold = 0.99/

and expect that flush will not be triggered until available /memtable 
offheap space /reaches ~50Gb. But flushes are triggered
before that limit. System monitor shows that in used only ~16Gb at that 
moment (linux+jvm+heap+...).


Why such thing is happened?

--
Thanks,
Serj



Re: Which hector version is suitable for cassandra 2.0.6 ?

2014-03-28 Thread ssiv...@gmail.com

Hello,

DS JD

On 03/27/2014 01:06 PM, DE VITO Dominique wrote:

Hi,


-Message d'origine-
De : ssiv...@gmail.com [mailto:ssiv...@gmail.com]
Envoyé : jeudi 27 mars 2014 10:41
À : user@cassandra.apache.org
Objet : Re: Which hector version is suitable for cassandra 2.0.6 ?

On 03/27/2014 12:23 PM, user 01 wrote:

Btw both Hector  Datastax java driver are maintained by Datastax, 
both for java, this speaks for itself !

I'm not sure about the first statement. What do you mean at the second part of 
the sentence?
They are Java-based, but has different API (and I find DS and Astyanax API 
quite more convenient that the Hector's one). They are also can be fine-grained 
configured.
Astyanax performance is about the same to DS (astx now about 5-10% faster), what I 
cannot say about Hector. And the main difference is that the DS supports C* v2 
with cql3, prepared statements, its navite  binary  protocol and other 
features. For example, using Astyanax versus DS on C* v2 shows unstable results 
under the high-load.

Which one shows unstable results under the high-load ? Astyanax ? DS ?

Thanks.

Dominique


Also, CQL is now deprecated and in the future the move is towards CQL3 and thus 
the DataStax driver recommended for future development.
Astyanax working on the facade API so, I guess, it will be possible to change 
the raw level driver in some cases.

--
Thanks,
Serj


--
Thanks,
Serj



Re: Which hector version is suitable for cassandra 2.0.6 ?

2014-03-27 Thread ssiv...@gmail.com
If you're using C* v2 I suggest you to switch to the latest DataStax 
JavaDriver which the only one who supports C* v2. Also you can use 
Astyanax in order to switch to its API but having something like DS 
JavaDriver under the hood.
It may be interesting for you 
http://techblog.netflix.com/2013/12/astyanax-update.html


On 03/27/2014 11:17 AM, user 01 wrote:

Which hector version is suitable for cassandra 2.0.6 ?

I am seeing that version 1.1-4(which I believe is latest release?) has 
been there around since very long time even before C* 2.x.x series 
wasn't out.  So is it the latest release suitable for 2.0 series?


Is Hector under active development nowadays ?




Re: Which hector version is suitable for cassandra 2.0.6 ?

2014-03-27 Thread ssiv...@gmail.com


On 03/27/2014 12:23 PM, user 01 wrote:
Btw both Hector  Datastax java driver are maintained by Datastax,  
both for java, this speaks for itself !
I'm not sure about the first statement. What do you mean at the second 
part of the sentence?
They are Java-based, but has different API (and I find DS and Astyanax 
API quite more convenient that the Hector's one). They are also can be 
fine-grained configured.
Astyanax performance is about the same to DS (astx now about 5-10% 
faster), what I cannot say about Hector. And the main difference is that 
the DS supports C* v2 with cql3, prepared statements,
its navite  binary protocol and other features. For example, using 
Astyanax versus DS on C* v2 shows unstable results under the high-load.
Also, CQL is now deprecated and in the future the move is towards CQL3 
and thus the DataStax driver recommended for future development. 
Astyanax working on the facade API so, I guess, it will be

possible to change the raw level driver in some cases.

--
Thanks,
Serj



Re: unstable write performance

2014-03-26 Thread ssiv...@gmail.com

280 sec: 865658 operations; 2661.5 current ops/sec; [INSERT
AverageLatency(us)=3640.16]
 290 sec: 865658 operations; 0 current ops/sec;

It also may indicate that C* trying to finished active tasks and your write 
requests have been
in the queue all 10 sec. Try to monitor C* doing*$watch nodetool tpstats*  
and*$watch nodetool compactionstats.
*Any values 0 in*  pending*column isn't good.

Enable GC logging in cassandra-env.sh. How much memory is free when running C* ?
Increasing heap size may cause long GC delays since GC need to collect and copy 
memory and it also may
depend on your CPU resources.

Try to run C* on default settings and monitor it to found out the bottleneck.



On 03/26/2014 05:54 PM, Jiaan Zeng wrote:

Hi,

I am doing some performance benchmarks in a *single* node cassandra
1.2.4. BTW, the machine is dedicated to run one cassandra instance.
The workload is 100% write. The throughput varies dramatically and
sometimes even drops to 0. I have tried several things below and still
got the same observation. There is no errors in the log file. One
thing I spotted in the log is GCInspector reports GC takes more than
200 ms. I think that is because the size of the memtable setting. If I
lower the memtable size, that kind of report can go away. Any clues
about what is happening in this case and suggestions about how to
achieve a stable write throughput? Thanks a lot.

1) Increase heap size from 4 G to 8 G. The total memory is 16 G.
2) Increase memtable_total_space_in_mb and
commitlog_total_space_in_mb to decrease the number of memtable
flush.
3) Disable the compaction to eliminate the impact of compaction on disk.

Below is an example of throughput.
280 sec: 865658 operations; 2661.5 current ops/sec; [INSERT
AverageLatency(us)=3640.16]
  290 sec: 865658 operations; 0 current ops/sec;
  300 sec: 903204 operations; 3754.22 current ops/sec; [INSERT
AverageLatency(us)=12341.77]






Re: Why select count(*) from .. hangs ?

2014-03-25 Thread ssiv...@gmail.com

Hi,

What is your hardware, C* version, data structure and typical data size ?

On 03/25/2014 06:36 PM, shahab wrote:

Hi,

I am quite new to Cassandra and  trying to evaluate its feasibility 
for our application.
In our application, we need to insert roughly 30 sensor data every 
30 seconds (basically we need to store time-series data).  I wrote a 
simple java code to insert 30 random data every 30 seconds for 10 
iterations, and measured the number of  entries in the table after 
each insertion.
But after iteration 8,  (i.e. inserting  150 sensor data), the 
select count(') ...)  throws time-out exception and doesn't work 
anymore. I even tried  to execute select count(*)... using Datastax 
DevCenter GUI, but I got same result.


I am sure that I have missed something or misunderstood how Cassandra 
works, but don't know really what? I do appreciate any hints.


best,
/Shahab