cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Yang (JIRA)" <>
Subject [jira] [Issue Comment Edited] (CASSANDRA-3253) inherent deadlock situation in commitLog flush?
Date Fri, 23 Sep 2011 19:27:26 GMT


Yang Yang edited comment on CASSANDRA-3253 at 9/23/11 7:27 PM:

looks to be related to

      was (Author: yangyangyyy):
    looks to be the same of
> inherent deadlock situation in commitLog flush?
> -----------------------------------------------
>                 Key: CASSANDRA-3253
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.0.0
>            Reporter: Yang Yang
> after my system ran for a while, it consitently goes into frozen state where all the
mutations stage threads are waiting
> on the switchlock,
> the reason is that the switchlock is held by commit log, as shown by the following thread
> "COMMIT-LOG-WRITER" prio=10 tid=0x00000000010df000 nid=0x32d3 waiting on condition [0x00007f2d81557000]
>    java.lang.Thread.State: WAITING (parking)
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <0x00007f3579eec060> (a java.util.concurrent.FutureTask$Sync)
>         at java.util.concurrent.locks.LockSupport.park(
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(
>         at java.util.concurrent.FutureTask$Sync.innerGet(
>         at java.util.concurrent.FutureTask.get(
>         at org.apache.cassandra.db.commitlog.CommitLog.getContext(
>         at org.apache.cassandra.db.ColumnFamilyStore.maybeSwitchMemtable(
>         at org.apache.cassandra.db.ColumnFamilyStore.forceFlush(
>         at org.apache.cassandra.db.commitlog.CommitLog.createNewSegment(
>         at org.apache.cassandra.db.commitlog.CommitLog.access$300(
>         at org.apache.cassandra.db.commitlog.CommitLog$
>         at org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(
>         at
>         at
> we can clearly see that the COMMIT-LOG-WRITER thread is running the regular appender
, but the appender itself calls getContext(), which again submits a new Callable to be executed,
and waits on the Callable. but the new Callable is never going to be executed since the executor
has only *one* thread.
> I believe this is a deterministic bug.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message