You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Jason Gustafson (Jira)" <ji...@apache.org> on 2020/06/03 17:59:00 UTC

[jira] [Commented] (KAFKA-10080) IllegalStateException after duplicate CompleteCommit append to transaction log

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

Jason Gustafson commented on KAFKA-10080:
-----------------------------------------

Note that this seems to have been introduced in KAFKA-9777, which has not been part of any released version. I have merged the patch into the 2.6 branch, so it should not affect 2.6.0 either.

> IllegalStateException after duplicate CompleteCommit append to transaction log
> ------------------------------------------------------------------------------
>
>                 Key: KAFKA-10080
>                 URL: https://issues.apache.org/jira/browse/KAFKA-10080
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Jason Gustafson
>            Assignee: Jason Gustafson
>            Priority: Major
>
> We noticed this exception in the logs:
> {code}
> java.lang.IllegalStateException: TransactionalId foo completing transaction state transition while it does not have a pending state                                                                            
>         at kafka.coordinator.transaction.TransactionMetadata.$anonfun$completeTransitionTo$1(TransactionMetadata.scala:357)
>         at kafka.coordinator.transaction.TransactionMetadata.completeTransitionTo(TransactionMetadata.scala:353)
>         at kafka.coordinator.transaction.TransactionStateManager.$anonfun$appendTransactionToLog$3(TransactionStateManager.scala:595)                                                                                                                       
>         at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
>         at kafka.coordinator.transaction.TransactionMetadata.inLock(TransactionMetadata.scala:188)
>         at kafka.coordinator.transaction.TransactionStateManager.$anonfun$appendTransactionToLog$15$adapted(TransactionStateManager.scala:587)                                                                                                              
>         at kafka.server.DelayedProduce.onComplete(DelayedProduce.scala:126)
>         at kafka.server.DelayedOperation.forceComplete(DelayedOperation.scala:70)
>         at kafka.server.DelayedProduce.tryComplete(DelayedProduce.scala:107)
>         at kafka.server.DelayedOperation.maybeTryComplete(DelayedOperation.scala:121)
>         at kafka.server.DelayedOperationPurgatory$Watchers.tryCompleteWatched(DelayedOperation.scala:378)
>         at kafka.server.DelayedOperationPurgatory.checkAndComplete(DelayedOperation.scala:280)
>         at kafka.cluster.DelayedOperations.checkAndCompleteAll(Partition.scala:122)
>         at kafka.cluster.Partition.tryCompleteDelayedRequests(Partition.scala:1023)
>         at kafka.cluster.Partition.updateFollowerFetchState(Partition.scala:740)
> {code}
> After inspection, we found that there were two CompleteCommit entries in the transaction state log which explains the failed transition. Indeed the logic for writing the CompleteCommit message does seem prone to race conditions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)