[
https://issues.apache.org/jira/browse/CASSANDRA-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-7724:
Attachment: aggregateddump.txt
Attached is your thread dump reformatted to be easier to digest. Looking at it,
there appears to be an incoming read on the IncomingTcpConnection, which is
quite likely one of the prepare requests or responses being processed by the
node, although it's hard to say for certain. There are multiple threads
involved - the native transport requests start the work, however the mutation
stage processes the paxos messages on receipt, and the incoming/outbound tcp
connections deliver those messages. It's still a bit funny that you can never
see these threads live, though, in any of your dumps, and I would be interested
in getting a few to double check.
Either way, this raises the sensible prospect of optimising cas when RF=1.
Native-Transport threads get stuck in StorageProxy.preparePaxos with no one
making progress
---
Key: CASSANDRA-7724
URL: https://issues.apache.org/jira/browse/CASSANDRA-7724
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux 3.13.11-4 #4 SMP PREEMPT x86_64 Intel(R) Core(TM)
i7 CPU 950 @ 3.07GHz GenuineIntel
java version 1.8.0_05
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
cassandra 2.0.9
Reporter: Anton Lebedevich
Attachments: aggregateddump.txt, cassandra.threads2
We've got a lot of write timeouts (cas) when running
INSERT INTO cas_demo(pri_id, sec_id, flag, something) VALUES(?, ?, ?, ?) IF
NOT EXISTS
from 16 connections in parallel using the same pri_id and different sec_id.
Doing the same from 4 connections in parallel works ok.
All configuration values are at their default values.
CREATE TABLE cas_demo (
pri_id varchar,
sec_id varchar,
flag boolean,
something setvarchar,
PRIMARY KEY (pri_id, sec_id)
);
CREATE INDEX cas_demo_flag ON cas_demo(flag);
Full thread dump is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
