kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piotr Nowojski (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (KAFKA-6132) KafkaProducer.initTransactions dead locks
Date Fri, 27 Oct 2017 14:51:00 GMT

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

Piotr Nowojski edited comment on KAFKA-6132 at 10/27/17 2:50 PM:

Ok, thanks for the quick answer. I hope that will be released in not so distant future.

was (Author: pnowojski):
Ok, thanks for the quick answer. I hope that will be release in not so distant future.

> KafkaProducer.initTransactions dead locks
> -----------------------------------------
>                 Key: KAFKA-6132
>                 URL: https://issues.apache.org/jira/browse/KAFKA-6132
>             Project: Kafka
>          Issue Type: Bug
>          Components: producer 
>    Affects Versions:,
>         Environment: Travis
>            Reporter: Piotr Nowojski
>            Priority: Critical
> I have found some intermittent failures on travis when using Kafka 0.11 transactions
for writing. One of them is a apparent deadlock with the following stack trace:
> {code:java}
> "KafkaTestThread[19, false]" #166 prio=5 os_prio=0 tid=0x00007f4b64c29800 nid=0x1260
waiting on condition [0x00007f4b10fa4000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000947048a8> (a java.util.concurrent.CountDownLatch$Sync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> 	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> 	at org.apache.kafka.clients.producer.internals.TransactionalRequestResult.await(TransactionalRequestResult.java:50)
> 	at org.apache.kafka.clients.producer.KafkaProducer.initTransactions(KafkaProducer.java:537)
> {code}
> I was unsuccessful to reproduce it locally, however I think I can semi reliably reproduce
it on Travis. Scenario includes simultaneous sequence of instantiating new producers, calling
{{KafkaProducer.initTransactions}}, closing them interleaved with writing. I have created
a stripped down version of this scenario as a github project:
> https://github.com/pnowojski/kafka-init-deadlock
> The code for the test scenario is here:
> https://github.com/pnowojski/kafka-init-deadlock/blob/master/src/test/java/pl/nowojski/KafkaInitDeadLockTest.java
> I have defined 30 build profiles that run this test and in case of detecting a dead lock
(5 minutes period of inactivity), stack trace of all threads is being printed out. Example
travis run:
> https://travis-ci.org/pnowojski/kafka-init-deadlock/builds/293256284
> as you can see deadlock occurred in 7 out of 30 builds. It seems like in this scenario
all of them are failing/dead locking in exactly same way. 
> I have observed this issue both on and 

This message was sent by Atlassian JIRA

View raw message