Re: High end-to-end latency with processing.guarantee=exactly_once

2019-01-03 Thread Dmitry Minkovsky
Also, occasionally I see errors like this. Is it related to this issue? [2018-12-30 18:21:00,552] ERROR (org.apache.kafka.streams.processor.internals.RecordCollectorImpl:131) task [0_4] Error sending record (key value id: "\227\236\022L\205\356\375\373\373\304\241\301n\250H\367" timestamp 1546194

Re: High end-to-end latency with processing.guarantee=exactly_once

2019-01-03 Thread Dmitry Minkovsky
Hi Matthias, I get these errors even on reprocessing, when data is flowing full throttle through the system. Can you help me understand how to tune this behavior, if possible? I appreciate that it's aggressive, but it seems to be so extremely aggressive that I get these errors constantly. Just how

Re: High end-to-end latency with processing.guarantee=exactly_once

2018-12-20 Thread Matthias J. Sax
The problem is repartitions topics: Kafka Streams considers those topics as transient and purges consumed data aggressively (cf https://issues.apache.org/jira/browse/KAFKA-6150) resulting in lost producer state for those topics :( -Matthias On 12/20/18 3:18 AM, Dmitry Minkovsky wrote: > Also, I

Re: High end-to-end latency with processing.guarantee=exactly_once

2018-12-19 Thread Dmitry Minkovsky
Also, I have read through that issue and KIP-360 to the extent my knowledge allows and I don't understand why I get this error constantly when exactly once is enabled. The KIP says > Idempotent/transactional semantics depend on the broker retaining state for each active producer id (e.g. epoch and

Re: High end-to-end latency with processing.guarantee=exactly_once

2018-12-19 Thread Dmitry Minkovsky
Hello įŽ‹įžŽåŠŸ, I am using 2.1.0. And, I think you nailed it on the head, because my application is low throughput and I am seeing UNKNOWN_PRODUCER_ID all the time with exactly once enabled. I've googled this before but couldn't identify the cause. Thank you! Setting retry.backoff.ms to 5 brought the