cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel S. (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-5025) Schema push/pull race
Date Tue, 20 Dec 2016 16:08:58 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764515#comment-15764515
] 

Pavel S. edited comment on CASSANDRA-5025 at 12/20/16 4:08 PM:
---------------------------------------------------------------

Hi,

Looks like that the issue has not been resolved. 

I've just got this:

{code}
15:52:40.194 [cluster1-nio-worker-1] WARN  c.d.driver.core.RequestHandler - /127.0.0.1:9042
replied with server error (java.lang.RuntimeException: java.util.concurrent.ExecutionException:
org.apache.cassandra.exceptions.ConfigurationException: Column family ID mismatch (found 5230d9a0-c6cc-11e6-9ece-6d2c86545d91;
expected 51d06a20-c6cc-11e6-9ece-6d2c86545d91)), defuncting connection.
{code}

On C* 3.9:

{code}
[cqlsh 5.0.1 | Cassandra 3.9 | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
cqlsh>
{code}

with latest driver: {{"com.datastax.cassandra" % "cassandra-driver-core" % "3.1.2"}}

It's one-node setup and everything I'm doing is just running {{CREATE TABLE IF NOT EXISTS}}
from several threads at the same time.

The only difference with previous version is the fact that applications starts hanging forever
with stack like

{code}
"pool-4-thread-5-ScalaTest-running-CassandraMwsRestTest" #37 prio=5 os_prio=31 tid=0x00007f7f7048a800
nid=0x5113 waiting on condition [0x0000700006010000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0000000796682630> (a com.datastax.driver.core.DefaultResultSetFuture)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:445)
	at com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:143)
	at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:243)
	at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
	at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:43)
{code}


was (Author: pshirshov):
Hi,

Looks like that the issue has not been resolved. 

I've just got this:

{code}
15:52:40.194 [cluster1-nio-worker-1] WARN  c.d.driver.core.RequestHandler - /127.0.0.1:9042
replied with server error (java.lang.RuntimeException: java.util.concurrent.ExecutionException:
org.apache.cassandra.exceptions.ConfigurationException: Column family ID mismatch (found 5230d9a0-c6cc-11e6-9ece-6d2c86545d91;
expected 51d06a20-c6cc-11e6-9ece-6d2c86545d91)), defuncting connection.
{code}

On C* 3.9:

{code}
[cqlsh 5.0.1 | Cassandra 3.9 | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
cqlsh>
{code}

with latest driver: {{"com.datastax.cassandra" % "cassandra-driver-core" % "3.1.2"}}

It's one-node setup and everything I'm doing is just running {{CREATE TABLE IF NOT EXISTS}}
from several threads at the same time.

The only difference with previous version is the fact that applications starts hanging forever
with stack like

{code}
"pool-4-thread-5-ScalaTest-running-CassandraMwsRestTest" #37 prio=5 os_prio=31 tid=0x00007f7f7048a800
nid=0x5113 waiting on condition [0x0000700006010000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0000000796682630> (a com.datastax.driver.core.DefaultResultSetFuture)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:445)
	at com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:143)
	at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:243)
	at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
	at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:43)
	at org.bitbucket.pshirshov.izumitk.cassandra.util.CassandraQueries$$anonfun$createTables$1.apply(CassandraQueries.scala:26)
	at org.bitbucket.pshirshov.izumitk.cassandra.util.CassandraQueries$$anonfun$createTables$1.apply(CassandraQueries.scala:25)
	at scala.collection.immutable.List.foreach(List.scala:381)
{code}

> Schema push/pull race
> ---------------------
>
>                 Key: CASSANDRA-5025
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5025
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.1.0
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 1.1.8
>
>         Attachments: 5025-v2.txt, 5025-v3.txt, 5025-v4.txt, 5025-v5.txt, 5025.txt
>
>
> When a schema change is made, the coordinator pushes the delta to the other nodes in
the cluster.  This is more efficient than sending the entire schema.  But the coordinator
also announces the new schema version, so the other nodes' reception of the new version races
with processing the delta, and usually seeing the new schema wins.  So the other nodes also
issue a pull to the coordinator for the entire schema.
> Thus, schema changes tend to become O(n) in the number of KS and CF present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message