Hi, I have weird driver behaviour. Can you help me please to find the
problem?
Problem: I try to insert data using 10 threads.
I see that 10 thread starts, they start to insert some data and then they
hung. It takes enormous amount of time to insert (seconds for 1K inserts).
It runs 1K per second i
Did you tried to use BatchStatement?
On Jul 2, 2015 11:00 AM, "Serega Sheypak" wrote:
> Hi, I have weird driver behaviour. Can you help me please to find the
> problem?
> Problem: I try to insert data using 10 threads.
> I see that 10 thread starts, they start to insert some data and then they
>
What is the reason to do that? I understand BatchStatement as a kind of
atomic insert hack.
How it can help me to solve concurrency problem? 1 thread with sync insert
gives me 1K ops/sec. 10 threads give me 20 ops/sec :)
Here are metrics for single thread async insert:
-- Timers
-
any help?
On Thu, Jul 2, 2015 at 6:18 AM, Neha Trivedi wrote:
> also:
> root@cas03:~# sudo service cassandra start
> root@cas03:~# lsof -n | grep java | wc -l
> 5315
> root@cas03:~# lsof -n | grep java | wc -l
> 977317
> root@cas03:~# lsof -n | grep java | wc -l
> 880240
> root@cas03:~# lsof -n
Indeed you should upgrade to 2.1.7.
And then report if you are still facing problems. Versions up to 2.1.5 (in
the 2.1.x series) are not considered stable.
Regards,
Carlos Juzarte Rolo
Cassandra Consultant
Pythian - Love your data
rolo@pythian | Twitter: cjrolo | Linkedin: *linkedin.com/in/car
If you post the code you're using to test, it would be helpful. You should
also use cassandra-stress to see if you get similar results.
On Thu, Jul 2, 2015 at 1:39 AM Serega Sheypak
wrote:
> What is the reason to do that? I understand BatchStatement as a kind of
> atomic insert hack.
> How it c
The recommended version to use is 2.1.5 because, like you Carlos said,
2.1.6 and 2.1.7 are very new to consider them like
stable.
On 02/07/15 08:55, Carlos Rolo wrote:
Indeed you should upgrade to 2.1.7.
And then report if you are still facing problems. Versions up to 2.1.5
(in the 2.1.x seri
Marco you should also avoid 2.1.5 and 2.1.6 because of
https://issues.apache.org/jira/browse/CASSANDRA-9549
I know (And often don't recommend last versions, I'm still recommending
2.0.x series unless someone is already in 2.1.x) but given the above bug,
2.1.7 is the best option.
Regards,
Carlos
you should check the network connectivity for this node and also its system
average load. is that typo or literary what it is, cassandra 1.2.15.*1* and
java 6 update *85* ?
On Thu, Jul 2, 2015 at 12:59 AM, Shashi Yachavaram
wrote:
> We have a 28 node cluster, out of which only one node is expe
thanks for the reply.!!
I will update it to 2.1.7 and checkout.
On Thu, Jul 2, 2015 at 6:59 PM, Carlos Rolo wrote:
> Marco you should also avoid 2.1.5 and 2.1.6 because of
> https://issues.apache.org/jira/browse/CASSANDRA-9549
>
> I know (And often don't recommend last versions, I'm still recomm
Jason,
The load was evenly distributed. And regarding network connectivity, our
applications were successfully able to connect to the node, but the read
and write operations were timing out. Also we were able to ssh to this
node.
I just pasted "/bin/nodetool -h node version" and "java -version".
Hi,
I am not sure about what is happening (I have never seen this error
before). Yet from
https://github.com/apache/cassandra/blob/cassandra-1.2/CHANGES.txt it
looks like some bugs were fixed in late revision of 1.2.x.
I would advice you upgrading to last 1.2.19 (It is an old and stable
version,
We had six node clusters and when we attempted to join a node to this, cpu
load on two gradually climbed to abnormally high number. Stopping the
join and shutting down cassandra on two high-load nodes restored the
cluster health (we have RF=3)
Anyone have any insight on this cassandra behavior?
Hi.
Here is a schema disagreement we encountered.
Schema versions:
b6467059-5897-3cc1-9ee2-73f31841b0b0: [10.0.1.100, 10.0.1.109]
c8971b2d-0949-3584-aa87-0050a4149bbd: [10.0.1.55, 10.0.1.16,
10.0.1.77]
c733920b-2a31-30f0-bca1-45a8c9130a2c: [10.0.1.221]
We deployed an appli
What version of C* are you running? Some versions of 2.0.x might occasionally
fail to propagate schema changes in a timely fashion (though they would fix
themselves eventually - in the order of a few minutes)
> On Jul 2, 2015, at 9:37 PM, John Wong wrote:
>
> Hi.
>
> Here is a schema disagree
On Thu, Jul 2, 2015 at 11:01 PM, graham sanderson wrote:
> What version of C* are you running? Some versions of 2.0.x might
> occasionally fail to propagate schema changes in a timely fashion (though
> they would fix themselves eventually - in the order of a few minutes)
>
>
Hi Graham. Thanks. We
16 matches
Mail list logo
