[jira] [Commented] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using exactly_once
[
https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752396#comment-17752396
]
Tomonari Yamashita commented on KAFKA-15259:
My opinion is neutral on whether it should be solved right away in Kafka
Streams. I would like to hear from others if they have an opinion. (But I think
there is no problem to solve it with the Kafka Producer first.
If I could write opinions on both sides:
- [Kafka Producer First] Similar issues occur not only with Kafka Streams but
also with Kafka Producer. Skipping messages is difficult even for the Kafka
Procuder. it needs to be resolved first in the Kafka Producer ticket.
- [Kafka Streams First] The behavior with Kafka Streams is a bug, but the
behavior with Kafka Producer is expected behavior, and resolving Kafka Streams
should take priority over Kafka Producer.
> Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using exactly_once
>
>
> Key: KAFKA-15259
> URL: https://issues.apache.org/jira/browse/KAFKA-15259
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.1
>Reporter: Tomonari Yamashita
>Priority: Major
> Attachments: Reproducer.java, app_at_least_once.log,
> app_exactly_once.log
>
>
> [Problem]
> - Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using exactly_once.
> -- "CONTINUE will signal that Streams should ignore the issue and continue
> processing"(1), so Kafka Streams should continue processing even if using
> exactly_once when ProductionExceptionHandlerResponse.CONTINUE used.
> -- However, if using exactly_once, Kafka Streams does not continue
> processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE. And the client will be shut down
> as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
> [Environment]
> - Kafka Streams 3.5.1
> [Reproduction procedure]
> # Create "input-topic" topic and "output-topic"
> # Put several messages on "input-topic"
> # Execute a simple Kafka streams program that transfers too large messages
> from "input-topic" to "output-topic" with exactly_once and returns
> ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
> producer. Please refer to the reproducer program (attached file:
> Reproducer.java).
> # ==> However, Kafka Streams does not continue processing due to rollback
> despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
> shutdown as the default
> behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT) (2). Please refer to
> the debug log (attached file: app_exactly_once.log).
> ## My excepted behavior is that Kafka Streams should continue processing
> even if using exactly_once. when ProductionExceptionHandlerResponse.CONTINUE
> used.
> [As far as my investigation]
> - FYI, if using at_least_once instead of exactly_once, Kafka Streams
> continue processing without rollback when
> ProductionExceptionHandlerResponse.CONTINUE is used. Please refer to the
> debug log (attached file: app_at_least_once.log).
> - "continue" worked in Kafka Streams 3.1.2, but no longer works since Kafka
> Streams 3.2.0, as rollback occurs.
> (1) CONFIGURING A STREAMS APPLICATION > default.production.exception.handler
> -
> [https://kafka.apache.org/35/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler]
> (2) Transaction abort and shutdown occur
> {code:java}
> 2023-07-26 21:27:19 DEBUG KafkaProducer:1073 - [Producer
> clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
> transactionalId=java-kafka-streams-0_0] Exception occurred during message
> send:
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger than 1048576, which is the
> value of the max.request.size configuration.
> 2023-07-26 21:27:19 ERROR RecordCollectorImpl:322 - stream-thread
> [java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
> stream-task [0_0] Error encountered sending record to topic output-topic for
> task 0_0 due to:
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger than 1048576, which is the
> value of the max.request.size configuration.
> Exception handler choose to CONTINUE processing in spite of this error but
> written offsets would not be recorded.
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is
[jira] [Commented] (KAFKA-15309) Add custom error handler to Producer
[ https://issues.apache.org/jira/browse/KAFKA-15309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752369#comment-17752369 ] Tomonari Yamashita commented on KAFKA-15309: FYI, I've created a simple reproducer. The Kafka Producer behavior has changed since Kafka 3.2.0 implemented KAFKA-9279, which forces the transaction to abort if any of the individual producer.send()'s fail, and this change is expected behavior. This reproducer is able to confirm that the Kafka Producer behavior has changed. In addition, maybe, by integrating the extension of the error handler provided in this ticket, it could be used as the basis for a reference implementation that skips wrong messages. [Reproduction procedure] # Create "input-topic" topic and "output-topic" # Put several messages on "input-topic" # Execute a simple Kafka Producer program that transfers too large messages from "input-topic" to "output-topic" with transaction and ignores RecordTooLargeException of producer.send(). Please refer to the reproducer program (attached file: KafkaProducerReproducer.java). # ==> Changing the version of Kafka Producer will lead to a different behavior whether commit is available or not (i.e., the transaction aborts), as follows: -- Kafka 2.8.2 : It is possible to commit ignoring RecordTooLargeException -- Kafka 3.0.0 : It is possible to commit ignoring RecordTooLargeException -- Kafka 3.1.2 : It is possible to commit ignoring RecordTooLargeException -- Kafka 3.2.0 : Cannot skip messages by ignoring RecordTooLargeException because the transaction was rollbacked/aborted. -- Kafka 3.2.3 : Cannot skip messages by ignoring RecordTooLargeException because the transaction was rollbacked/aborted. -- Kafka 3.5.1 : Cannot skip messages by ignoring RecordTooLargeException because the transaction was rollbacked/aborted. > Add custom error handler to Producer > > > Key: KAFKA-15309 > URL: https://issues.apache.org/jira/browse/KAFKA-15309 > Project: Kafka > Issue Type: New Feature > Components: producer >Reporter: Matthias J. Sax >Priority: Major > Labels: needs-kip > Attachments: KafkaProducerReproducer.java, app.log > > > The producer collects multiple records into batches, and a single record > specific error might fail the whole batch (eg, `RecordTooLargeException`). > This ticket suggests to add a per-record error handler, that allows user to > opt into skipping bad records without failing the whole batch (similar to > Kafka Streams `ProductionExceptionHandler`). > The fix of https://issues.apache.org/jira/browse/KAFKA-9279 caused > https://issues.apache.org/jira/browse/KAFKA-15259 which inspired this ticket. > Another example for which a production exception handler could be useful, if > a user tries to write into a non-existing topic, which returns a retryable > error code; with infinite retries the producer would hang retrying forever. A > handler could help to break the infinite retry loop. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15309) Add custom error handler to Producer
[ https://issues.apache.org/jira/browse/KAFKA-15309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-15309: --- Attachment: app.log KafkaProducerReproducer.java > Add custom error handler to Producer > > > Key: KAFKA-15309 > URL: https://issues.apache.org/jira/browse/KAFKA-15309 > Project: Kafka > Issue Type: New Feature > Components: producer >Reporter: Matthias J. Sax >Priority: Major > Labels: needs-kip > Attachments: KafkaProducerReproducer.java, app.log > > > The producer collects multiple records into batches, and a single record > specific error might fail the whole batch (eg, `RecordTooLargeException`). > This ticket suggests to add a per-record error handler, that allows user to > opt into skipping bad records without failing the whole batch (similar to > Kafka Streams `ProductionExceptionHandler`). > The fix of https://issues.apache.org/jira/browse/KAFKA-9279 caused > https://issues.apache.org/jira/browse/KAFKA-15259 which inspired this ticket. > Another example for which a production exception handler could be useful, if > a user tries to write into a non-existing topic, which returns a retryable > error code; with infinite retries the producer would hang retrying forever. A > handler could help to break the infinite retry loop. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using exactly_once
[
https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15259:
---
Description:
[Problem]
- Kafka Streams does not continue processing due to rollback despite
ProductionExceptionHandlerResponse.CONTINUE if using exactly_once.
-- "CONTINUE will signal that Streams should ignore the issue and continue
processing"(1), so Kafka Streams should continue processing even if using
exactly_once when ProductionExceptionHandlerResponse.CONTINUE used.
-- However, if using exactly_once, Kafka Streams does not continue processing
due to rollback despite ProductionExceptionHandlerResponse.CONTINUE. And the
client will be shut down as the default
behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
[Environment]
- Kafka Streams 3.5.1
[Reproduction procedure]
# Create "input-topic" topic and "output-topic"
# Put several messages on "input-topic"
# Execute a simple Kafka streams program that transfers too large messages
from "input-topic" to "output-topic" with exactly_once and returns
ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
producer. Please refer to the reproducer program (attached file:
Reproducer.java).
# ==> However, Kafka Streams does not continue processing due to rollback
despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
shutdown as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
(2). Please refer to the debug log (attached file: app_exactly_once.log).
## My excepted behavior is that Kafka Streams should continue processing even
if using exactly_once. when ProductionExceptionHandlerResponse.CONTINUE used.
[As far as my investigation]
- FYI, if using at_least_once instead of exactly_once, Kafka Streams continue
processing without rollback when ProductionExceptionHandlerResponse.CONTINUE is
used. Please refer to the debug log (attached file: app_at_least_once.log).
- "continue" worked in Kafka Streams 3.1.2, but no longer works since Kafka
Streams 3.2.0, as rollback occurs.
(1) CONFIGURING A STREAMS APPLICATION > default.production.exception.handler
-
[https://kafka.apache.org/35/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler]
(2) Transaction abort and shutdown occur
{code:java}
2023-07-26 21:27:19 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Exception occurred during message send:
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
stream-task [0_0] Error encountered sending record to topic output-topic for
task 0_0 due to:
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
Exception handler choose to CONTINUE processing in spite of this error but
written offsets would not be recorded.
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 INFO TransactionManager:393 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Transiting to abortable error state
due to org.apache.kafka.common.errors.RecordTooLargeException: The message is
1188 bytes when serialized which is larger than 1048576, which is the value
of the max.request.size configuration.
2023-07-26 21:27:19 DEBUG TransactionManager:986 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Transition from state IN_TRANSACTION
to error state ABORTABLE_ERROR
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 DEBUG StreamThread:825 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
Processed 1 records with 1 iterations; invoking punctuators if necessary
2023-07-26 21:27:19 DEBUG StreamThread:837 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1] 0
punctuators ran.
2023-07-26 21:27:19 DEBUG StreamThread:1117 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
Committing all active tasks [0_0] an
[jira] [Updated] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using exactly_once
[
https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15259:
---
Summary: Kafka Streams does not continue processing due to rollback despite
ProductionExceptionHandlerResponse.CONTINUE if using exactly_once (was: Kafka
Streams does not continue processing due to rollback despite
ProductionExceptionHandlerResponse.CONTINUE if using execute_once)
> Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using exactly_once
>
>
> Key: KAFKA-15259
> URL: https://issues.apache.org/jira/browse/KAFKA-15259
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.1
>Reporter: Tomonari Yamashita
>Priority: Major
> Attachments: Reproducer.java, app_at_least_once.log,
> app_exactly_once.log
>
>
> [Problem]
> - Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using execute_once.
> -- "CONTINUE will signal that Streams should ignore the issue and continue
> processing"(1), so Kafka Streams should continue processing even if using
> execute_once when ProductionExceptionHandlerResponse.CONTINUE used.
> -- However, if using execute_once, Kafka Streams does not continue
> processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE. And the client will be shut down
> as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
> [Environment]
> - Kafka Streams 3.5.1
> [Reproduction procedure]
> # Create "input-topic" topic and "output-topic"
> # Put several messages on "input-topic"
> # Execute a simple Kafka streams program that transfers too large messages
> from "input-topic" to "output-topic" with execute_once and returns
> ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
> producer. Please refer to the reproducer program (attached file:
> Reproducer.java).
> # ==> However, Kafka Streams does not continue processing due to rollback
> despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
> shutdown as the default
> behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT) (2). Please refer to
> the debug log (attached file: app_exactly_once.log).
> ## My excepted behavior is that Kafka Streams should continue processing
> even if using execute_once. when ProductionExceptionHandlerResponse.CONTINUE
> used.
> [As far as my investigation]
> - FYI, if using at_least_once instead of execute_once, Kafka Streams
> continue processing without rollback when
> ProductionExceptionHandlerResponse.CONTINUE is used. Please refer to the
> debug log (attached file: app_at_least_once.log).
> - "continue" worked in Kafka Streams 3.1.2, but no longer works since Kafka
> Streams 3.2.0, as rollback occurs.
> (1) CONFIGURING A STREAMS APPLICATION > default.production.exception.handler
> -
> [https://kafka.apache.org/35/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler]
> (2) Transaction abort and shutdown occur
> {code:java}
> 2023-07-26 21:27:19 DEBUG KafkaProducer:1073 - [Producer
> clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
> transactionalId=java-kafka-streams-0_0] Exception occurred during message
> send:
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger than 1048576, which is the
> value of the max.request.size configuration.
> 2023-07-26 21:27:19 ERROR RecordCollectorImpl:322 - stream-thread
> [java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
> stream-task [0_0] Error encountered sending record to topic output-topic for
> task 0_0 due to:
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger than 1048576, which is the
> value of the max.request.size configuration.
> Exception handler choose to CONTINUE processing in spite of this error but
> written offsets would not be recorded.
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger than 1048576, which is the
> value of the max.request.size configuration.
> 2023-07-26 21:27:19 INFO TransactionManager:393 - [Producer
> clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
> transactionalId=java-kafka-streams-0_0] Transiting to abortable error state
> due to org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger t
[jira] [Updated] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using exactly_once
[
https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15259:
---
Description:
[Problem]
- Kafka Streams does not continue processing due to rollback despite
ProductionExceptionHandlerResponse.CONTINUE if using exactly_once.
-- "CONTINUE will signal that Streams should ignore the issue and continue
processing"(1), so Kafka Streams should continue processing even if using
exactly_once when ProductionExceptionHandlerResponse.CONTINUE used.
-- However, if using execute_once, Kafka Streams does not continue processing
due to rollback despite ProductionExceptionHandlerResponse.CONTINUE. And the
client will be shut down as the default
behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
[Environment]
- Kafka Streams 3.5.1
[Reproduction procedure]
# Create "input-topic" topic and "output-topic"
# Put several messages on "input-topic"
# Execute a simple Kafka streams program that transfers too large messages
from "input-topic" to "output-topic" with exactly_once and returns
ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
producer. Please refer to the reproducer program (attached file:
Reproducer.java).
# ==> However, Kafka Streams does not continue processing due to rollback
despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
shutdown as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
(2). Please refer to the debug log (attached file: app_exactly_once.log).
## My excepted behavior is that Kafka Streams should continue processing even
if using execute_once. when ProductionExceptionHandlerResponse.CONTINUE used.
[As far as my investigation]
- FYI, if using at_least_once instead of execute_once, Kafka Streams continue
processing without rollback when ProductionExceptionHandlerResponse.CONTINUE is
used. Please refer to the debug log (attached file: app_at_least_once.log).
- "continue" worked in Kafka Streams 3.1.2, but no longer works since Kafka
Streams 3.2.0, as rollback occurs.
(1) CONFIGURING A STREAMS APPLICATION > default.production.exception.handler
-
[https://kafka.apache.org/35/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler]
(2) Transaction abort and shutdown occur
{code:java}
2023-07-26 21:27:19 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Exception occurred during message send:
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
stream-task [0_0] Error encountered sending record to topic output-topic for
task 0_0 due to:
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
Exception handler choose to CONTINUE processing in spite of this error but
written offsets would not be recorded.
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 INFO TransactionManager:393 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Transiting to abortable error state
due to org.apache.kafka.common.errors.RecordTooLargeException: The message is
1188 bytes when serialized which is larger than 1048576, which is the value
of the max.request.size configuration.
2023-07-26 21:27:19 DEBUG TransactionManager:986 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Transition from state IN_TRANSACTION
to error state ABORTABLE_ERROR
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 DEBUG StreamThread:825 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
Processed 1 records with 1 iterations; invoking punctuators if necessary
2023-07-26 21:27:19 DEBUG StreamThread:837 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1] 0
punctuators ran.
2023-07-26 21:27:19 DEBUG StreamThread:1117 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
Committing all active tasks [0_0] an
[jira] [Commented] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using execute_once
[
https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751862#comment-17751862
]
Tomonari Yamashita commented on KAFKA-15259:
Thank you for creating the new ticket for Kafka Producer:
https://issues.apache.org/jira/browse/KAFKA-15309. I think that similar
problems occur not only with Kafka Streams but also with Kafka Producer, so I
agree that it needs to be resolved first in the Kafka Producer ticket.
> Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using execute_once
>
>
> Key: KAFKA-15259
> URL: https://issues.apache.org/jira/browse/KAFKA-15259
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.1
>Reporter: Tomonari Yamashita
>Priority: Major
> Attachments: Reproducer.java, app_at_least_once.log,
> app_exactly_once.log
>
>
> [Problem]
> - Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using execute_once.
> -- "CONTINUE will signal that Streams should ignore the issue and continue
> processing"(1), so Kafka Streams should continue processing even if using
> execute_once when ProductionExceptionHandlerResponse.CONTINUE used.
> -- However, if using execute_once, Kafka Streams does not continue
> processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE. And the client will be shut down
> as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
> [Environment]
> - Kafka Streams 3.5.1
> [Reproduction procedure]
> # Create "input-topic" topic and "output-topic"
> # Put several messages on "input-topic"
> # Execute a simple Kafka streams program that transfers too large messages
> from "input-topic" to "output-topic" with execute_once and returns
> ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
> producer. Please refer to the reproducer program (attached file:
> Reproducer.java).
> # ==> However, Kafka Streams does not continue processing due to rollback
> despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
> shutdown as the default
> behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT) (2). Please refer to
> the debug log (attached file: app_exactly_once.log).
> ## My excepted behavior is that Kafka Streams should continue processing
> even if using execute_once. when ProductionExceptionHandlerResponse.CONTINUE
> used.
> [As far as my investigation]
> - FYI, if using at_least_once instead of execute_once, Kafka Streams
> continue processing without rollback when
> ProductionExceptionHandlerResponse.CONTINUE is used. Please refer to the
> debug log (attached file: app_at_least_once.log).
> - "continue" worked in Kafka Streams 3.1.2, but no longer works since Kafka
> Streams 3.2.0, as rollback occurs.
> (1) CONFIGURING A STREAMS APPLICATION > default.production.exception.handler
> -
> [https://kafka.apache.org/35/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler]
> (2) Transaction abort and shutdown occur
> {code:java}
> 2023-07-26 21:27:19 DEBUG KafkaProducer:1073 - [Producer
> clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
> transactionalId=java-kafka-streams-0_0] Exception occurred during message
> send:
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger than 1048576, which is the
> value of the max.request.size configuration.
> 2023-07-26 21:27:19 ERROR RecordCollectorImpl:322 - stream-thread
> [java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
> stream-task [0_0] Error encountered sending record to topic output-topic for
> task 0_0 due to:
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger than 1048576, which is the
> value of the max.request.size configuration.
> Exception handler choose to CONTINUE processing in spite of this error but
> written offsets would not be recorded.
> org.apache.kafka.common.errors.RecordTooLargeException: The message is
> 1188 bytes when serialized which is larger than 1048576, which is the
> value of the max.request.size configuration.
> 2023-07-26 21:27:19 INFO TransactionManager:393 - [Producer
> clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
> transactionalId=java-kafka-streams-0_0] Transiting to abortable error state
> due to org.apache.kafka.common.errors.RecordTooLargeException: The message is
[jira] [Commented] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using execute_once
[ https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751698#comment-17751698 ] Tomonari Yamashita commented on KAFKA-15259: Hi [~mjsax], Thank you for sharing the information. Should we create a new ticket for Kafka Producer? If I understand correctly, the similar problem occurs not only in Kafka Streams but also in Kafka producer, so there are two problems as below: - Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using execute_once - Kafka Producer does not continue processing due to rollback despite ignoring non-retriable exception at the producer.send() if using transaction (expected behavior since https://issues.apache.org/jira/browse/KAFKA-9279) As a use case, if a non-retriable exception such as RecordTooLargeException occurs during production, we would need to have the option of removing such a source message and continuing the processing even if transaction/execute_once is used. In other words, a use case where a dead letter queue is needed. However, Kafka Streams is impossible to do so. Kafka Producer is not impossible, but there is probably no easy way to implement it. For example, if RecordTooLargeException is thrown in producer.send(), in what way can we continue the process or implement sending to dead letter queue? I understand https://issues.apache.org/jira/browse/KAFKA-9279, certainly, in some cases, it may be troublesome to commit a transaction despite an error in producer.send(). On the other hand, if errors such as RecordTooLargeException prevent the commit, then there is no way to ignore the error, causing concern that the Kafka Producer application might continue to get stuck with the same source message, for example if it consumes messages from a source topic and does sendOffsetsToTransaction(). I think adding a "production exception handler" to Kafka Producer is one of the good ideas. But it is no longer just a problem with Kafka Streams, but also with Kafka Producer. Rather, perhaps a solution for Kafka Producer should be considered more seriously because it may involve a change of API(public method) of Kafka Producer. Should we create a new ticket for Kafka Producer? If so, I can file it. > Kafka Streams does not continue processing due to rollback despite > ProductionExceptionHandlerResponse.CONTINUE if using execute_once > > > Key: KAFKA-15259 > URL: https://issues.apache.org/jira/browse/KAFKA-15259 > Project: Kafka > Issue Type: Bug > Components: streams >Affects Versions: 3.5.1 >Reporter: Tomonari Yamashita >Priority: Major > Attachments: Reproducer.java, app_at_least_once.log, > app_exactly_once.log > > > [Problem] > - Kafka Streams does not continue processing due to rollback despite > ProductionExceptionHandlerResponse.CONTINUE if using execute_once. > -- "CONTINUE will signal that Streams should ignore the issue and continue > processing"(1), so Kafka Streams should continue processing even if using > execute_once when ProductionExceptionHandlerResponse.CONTINUE used. > -- However, if using execute_once, Kafka Streams does not continue > processing due to rollback despite > ProductionExceptionHandlerResponse.CONTINUE. And the client will be shut down > as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT) > [Environment] > - Kafka Streams 3.5.1 > [Reproduction procedure] > # Create "input-topic" topic and "output-topic" > # Put several messages on "input-topic" > # Execute a simple Kafka streams program that transfers too large messages > from "input-topic" to "output-topic" with execute_once and returns > ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the > producer. Please refer to the reproducer program (attached file: > Reproducer.java). > # ==> However, Kafka Streams does not continue processing due to rollback > despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread > shutdown as the default > behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT) (2). Please refer to > the debug log (attached file: app_exactly_once.log). > ## My excepted behavior is that Kafka Streams should continue processing > even if using execute_once. when ProductionExceptionHandlerResponse.CONTINUE > used. > [As far as my investigation] > - FYI, if using at_least_once instead of execute_once, Kafka Streams > continue processing without rollback when > ProductionExceptionHandlerResponse.CONTINUE is used. Please refer to the > debug log (attached file: app_at_least_once.log). > - "continue" worked in Kafka Streams 3.1.2, but no longer work
[jira] [Commented] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using execute_once
[
https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748555#comment-17748555
]
Tomonari Yamashita commented on KAFKA-15259:
Hi [~mjsax],
I think the stacktrace can be ignored. This problem cause is that sending a too
large message to "output-topic", then RecordTooLargeException occurs in
producer.send(), and the transaction would be rollbacked/aborted (3) despite
ProductionExceptionHandlerResponse.CONTINUE if using execute_once. The
stacktrace is just secondary disaster with an error caused by a subsequent
commit on the transaction that has already been rollbacked/aborted.
As far as we have tested, even using the same source code (attached file:
Reproducer.java), changing the version of Kafka Streams will lead to a
different behavior whether "continue" is available or not (i.e., the
transaction aborts), as follows:
- Kafka 2.6.3 : OK. "continue" worked as I assume.
- Kafka 2.8.2 : OK. "continue" worked as I assume.
- Kafka 3.0.0 : OK. "continue" worked as I assume.
- Kafka 3.1.2 : OK. "continue" worked as I assume.
- Kafka 3.2.0 : NG. "continue" didn't work because the transaction was
rollbacked/aborted.
- Kafka 3.2.3 : NG. "continue" didn't work because the transaction was
rollbacked/aborted.
- Kafka 3.5.1 : NG. "continue" didn't work because the transaction was
rollbacked/aborted.
>From what I have seen in the debugger, it is probably transaction aborting at
>those codes(3).
Probably due to this change (4)(5) in Kafka 3.2.0, if any of the individual
producer.send() fails, the transaction is aborted forcibly.
Since this change (4) (5) is in Kafka producer, I realize that it would be
difficult to achieve the behavior prior to 3.1.2, which allows "continue" to be
used. However, if "continue" is not available, there is a concern that Kafka
Streams applications will continue to get stuck because there is no way to
ignore messages that raise RecordTooLargeException by sending them to the dead
letter queue.
(3)
https://github.com/apache/kafka/blob/3.5.1/clients/src/main/java/org/apache/kafka/clients/producer/KafkaProducer.java#L1081-L1083
{code:java}
if (transactionManager != null) {
transactionManager.maybeTransitionToErrorState(e);
}
{code}
(4) Silent data loss in Kafka producer
https://issues.apache.org/jira/browse/KAFKA-9279
(5) KAFKA-9279: Fail producer transactions for asynchronously-reported,
synchronously-encountered ApiExceptions #11508
https://github.com/apache/kafka/pull/11508
> Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using execute_once
>
>
> Key: KAFKA-15259
> URL: https://issues.apache.org/jira/browse/KAFKA-15259
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.1
>Reporter: Tomonari Yamashita
>Priority: Major
> Attachments: Reproducer.java, app_at_least_once.log,
> app_exactly_once.log
>
>
> [Problem]
> - Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using execute_once.
> -- "CONTINUE will signal that Streams should ignore the issue and continue
> processing"(1), so Kafka Streams should continue processing even if using
> execute_once when ProductionExceptionHandlerResponse.CONTINUE used.
> -- However, if using execute_once, Kafka Streams does not continue
> processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE. And the client will be shut down
> as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
> [Environment]
> - Kafka Streams 3.5.1
> [Reproduction procedure]
> # Create "input-topic" topic and "output-topic"
> # Put several messages on "input-topic"
> # Execute a simple Kafka streams program that transfers too large messages
> from "input-topic" to "output-topic" with execute_once and returns
> ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
> producer. Please refer to the reproducer program (attached file:
> Reproducer.java).
> # ==> However, Kafka Streams does not continue processing due to rollback
> despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
> shutdown as the default
> behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT) (2). Please refer to
> the debug log (attached file: app_exactly_once.log).
> ## My excepted behavior is that Kafka Streams should continue processing
> even if using execute_once. when ProductionExceptionHandlerResponse.CONTINUE
> used.
> [As far as my investigation]
> - FYI, if using at_least_once instead of execute_once
[jira] [Updated] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using execute_once
[
https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15259:
---
Description:
[Problem]
- Kafka Streams does not continue processing due to rollback despite
ProductionExceptionHandlerResponse.CONTINUE if using execute_once.
-- "CONTINUE will signal that Streams should ignore the issue and continue
processing"(1), so Kafka Streams should continue processing even if using
execute_once when ProductionExceptionHandlerResponse.CONTINUE used.
-- However, if using execute_once, Kafka Streams does not continue processing
due to rollback despite ProductionExceptionHandlerResponse.CONTINUE. And the
client will be shut down as the default
behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
[Environment]
- Kafka Streams 3.5.1
[Reproduction procedure]
# Create "input-topic" topic and "output-topic"
# Put several messages on "input-topic"
# Execute a simple Kafka streams program that transfers too large messages
from "input-topic" to "output-topic" with execute_once and returns
ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
producer. Please refer to the reproducer program (attached file:
Reproducer.java).
# ==> However, Kafka Streams does not continue processing due to rollback
despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
shutdown as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
(2). Please refer to the debug log (attached file: app_exactly_once.log).
## My excepted behavior is that Kafka Streams should continue processing even
if using execute_once. when ProductionExceptionHandlerResponse.CONTINUE used.
[As far as my investigation]
- FYI, if using at_least_once instead of execute_once, Kafka Streams continue
processing without rollback when ProductionExceptionHandlerResponse.CONTINUE is
used. Please refer to the debug log (attached file: app_at_least_once.log).
- "continue" worked in Kafka Streams 3.1.2, but no longer works since Kafka
Streams 3.2.0, as rollback occurs.
(1) CONFIGURING A STREAMS APPLICATION > default.production.exception.handler
-
[https://kafka.apache.org/35/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler]
(2) Transaction abort and shutdown occur
{code:java}
2023-07-26 21:27:19 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Exception occurred during message send:
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
stream-task [0_0] Error encountered sending record to topic output-topic for
task 0_0 due to:
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
Exception handler choose to CONTINUE processing in spite of this error but
written offsets would not be recorded.
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 INFO TransactionManager:393 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Transiting to abortable error state
due to org.apache.kafka.common.errors.RecordTooLargeException: The message is
1188 bytes when serialized which is larger than 1048576, which is the value
of the max.request.size configuration.
2023-07-26 21:27:19 DEBUG TransactionManager:986 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Transition from state IN_TRANSACTION
to error state ABORTABLE_ERROR
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 DEBUG StreamThread:825 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
Processed 1 records with 1 iterations; invoking punctuators if necessary
2023-07-26 21:27:19 DEBUG StreamThread:837 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1] 0
punctuators ran.
2023-07-26 21:27:19 DEBUG StreamThread:1117 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
Committing all active tasks [0_0] an
[jira] [Commented] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using execute_once
[
https://issues.apache.org/jira/browse/KAFKA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748120#comment-17748120
]
Tomonari Yamashita commented on KAFKA-15259:
Hi [~mjsax],
Thank you.
I believe that even "execute_once" would need to be able to use "continue". As
a use case, if a non-retriable exception such as RecordTooLargeException occurs
during production, we would need to have the option of removing such a source
message and continuing the processing even if "execute_once" is used. In other
words, a situation where a dead letter queue(1) is needed (even if
"execute_once" is used).
Many non-Kafka MQs( and Kafka Connect) have a dead letter queue feature, and it
can be combined with "execute_once". However, Kafka and Kafka Streams do not
have a dead letter queue feature, but instead Kafka Streams has
ProductionExceptionHandler and ProductionExceptionHandlerResponse.CONTINUE, if
my understanding is correct.
We actually had implemented a custom implementation of dead letter queue in
ProductionExceptionHandler with ProductionExceptionHandlerResponse.CONTINUE,
however, it no longer works with the latest version(3.5.1) of Kafka Streams.
Our additional testing revealed that "continue" worked in Kafka Streams 3.1.2,
but no longer works since Kafka Streams 3.2.0, as rollback occurs.
For this reason, I believe that "execute_once" and "continue" should be
available individually and in combination, and this behavior is a bug
introduced since Kafka Streams 3.2.0.
But if that is already considered expected behavior due to specification
changes etc, it would be necessary to provide another feature that allows
additional implementations such as a dead letter queue.
(1) Dead Letter Channel
https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html
> Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using execute_once
>
>
> Key: KAFKA-15259
> URL: https://issues.apache.org/jira/browse/KAFKA-15259
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.1
>Reporter: Tomonari Yamashita
>Priority: Major
> Attachments: Reproducer.java, app_at_least_once.log,
> app_exactly_once.log
>
>
> [Problem]
> - Kafka Streams does not continue processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE if using execute_once.
> -- "CONTINUE will signal that Streams should ignore the issue and continue
> processing"(1), so Kafka Streams should continue processing even if using
> execute_once when ProductionExceptionHandlerResponse.CONTINUE used.
> -- However, if using execute_once, Kafka Streams does not continue
> processing due to rollback despite
> ProductionExceptionHandlerResponse.CONTINUE. And the client will be shut down
> as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
> [Environment]
> - Kafka Streams 3.5.1
> [Reproduction procedure]
> # Create "input-topic" topic and "output-topic"
> # Put several messages on "input-topic"
> # Execute a simple Kafka streams program that transfers too large messages
> from "input-topic" to "output-topic" with execute_once and returns
> ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
> producer. Please refer to the reproducer program (attached file:
> Reproducer.java).
> # ==> However, Kafka Streams does not continue processing due to rollback
> despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
> shutdown as the default
> behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT) (2). Please refer to
> the debug log (attached file: app_exactly_once.log).
> ## My excepted behavior is that Kafka Streams should continue processing
> even if using execute_once. when ProductionExceptionHandlerResponse.CONTINUE
> used.
> [As far as my investigation]
> - FYI, if using at_least_once instead of execute_once, Kafka Streams
> continue processing without rollback when
> ProductionExceptionHandlerResponse.CONTINUE is used. Please refer to the
> debug log (attached file: app_at_least_once.log).
> (1) CONFIGURING A STREAMS APPLICATION > default.production.exception.handler
> -
> [https://kafka.apache.org/35/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler]
> (2) Transaction abort and shutdown occur
> {code:java}
> 2023-07-26 21:27:19 DEBUG KafkaProducer:1073 - [Producer
> clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
> transactionalId=java-kafka-streams-0_0] Exception occurred during message
> send:
> org.apache
[jira] [Created] (KAFKA-15259) Kafka Streams does not continue processing due to rollback despite ProductionExceptionHandlerResponse.CONTINUE if using execute_once
Tomonari Yamashita created KAFKA-15259:
--
Summary: Kafka Streams does not continue processing due to
rollback despite ProductionExceptionHandlerResponse.CONTINUE if using
execute_once
Key: KAFKA-15259
URL: https://issues.apache.org/jira/browse/KAFKA-15259
Project: Kafka
Issue Type: Bug
Components: streams
Affects Versions: 3.5.1
Reporter: Tomonari Yamashita
Attachments: Reproducer.java, app_at_least_once.log,
app_exactly_once.log
[Problem]
- Kafka Streams does not continue processing due to rollback despite
ProductionExceptionHandlerResponse.CONTINUE if using execute_once.
-- "CONTINUE will signal that Streams should ignore the issue and continue
processing"(1), so Kafka Streams should continue processing even if using
execute_once when ProductionExceptionHandlerResponse.CONTINUE used.
-- However, if using execute_once, Kafka Streams does not continue processing
due to rollback despite ProductionExceptionHandlerResponse.CONTINUE. And the
client will be shut down as the default
behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
[Environment]
- Kafka Streams 3.5.1
[Reproduction procedure]
# Create "input-topic" topic and "output-topic"
# Put several messages on "input-topic"
# Execute a simple Kafka streams program that transfers too large messages
from "input-topic" to "output-topic" with execute_once and returns
ProductionExceptionHandlerResponse.CONTINUE when an exception occurs in the
producer. Please refer to the reproducer program (attached file:
Reproducer.java).
# ==> However, Kafka Streams does not continue processing due to rollback
despite ProductionExceptionHandlerResponse.CONTINUE. And the stream thread
shutdown as the default behavior(StreamThreadExceptionResponse.SHUTDOWN_CLIENT)
(2). Please refer to the debug log (attached file: app_exactly_once.log).
## My excepted behavior is that Kafka Streams should continue processing even
if using execute_once. when ProductionExceptionHandlerResponse.CONTINUE used.
[As far as my investigation]
- FYI, if using at_least_once instead of execute_once, Kafka Streams continue
processing without rollback when ProductionExceptionHandlerResponse.CONTINUE is
used. Please refer to the debug log (attached file: app_at_least_once.log).
(1) CONFIGURING A STREAMS APPLICATION > default.production.exception.handler
-
[https://kafka.apache.org/35/documentation/streams/developer-guide/config-streams.html#default-production-exception-handler]
(2) Transaction abort and shutdown occur
{code:java}
2023-07-26 21:27:19 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Exception occurred during message send:
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
stream-task [0_0] Error encountered sending record to topic output-topic for
task 0_0 due to:
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
Exception handler choose to CONTINUE processing in spite of this error but
written offsets would not be recorded.
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 INFO TransactionManager:393 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Transiting to abortable error state
due to org.apache.kafka.common.errors.RecordTooLargeException: The message is
1188 bytes when serialized which is larger than 1048576, which is the value
of the max.request.size configuration.
2023-07-26 21:27:19 DEBUG TransactionManager:986 - [Producer
clientId=java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1-0_0-producer,
transactionalId=java-kafka-streams-0_0] Transition from state IN_TRANSACTION
to error state ABORTABLE_ERROR
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1188
bytes when serialized which is larger than 1048576, which is the value of the
max.request.size configuration.
2023-07-26 21:27:19 DEBUG StreamThread:825 - stream-thread
[java-kafka-streams-e3187cf9-5337-4155-a7cd-fd4e426b889d-StreamThread-1]
Processed 1 records with 1 iterations; invoking punctuators if necessary
2023-07-26 21:27:19 DEBUG StreamThread:837 - stream-thread
[java-kafka-streams
[jira] [Commented] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by streams producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735625#comment-17735625
]
Tomonari Yamashita commented on KAFKA-15108:
Hi [~mjsax],
Thank you. I wasn't sure if this issume was unexpected behavior or not, so your
advice was very helpful.
> task.timeout.ms does not work when TimeoutException is thrown by streams
> producer
> -
>
> Key: KAFKA-15108
> URL: https://issues.apache.org/jira/browse/KAFKA-15108
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.0
>Reporter: Tomonari Yamashita
>Priority: Major
>
> [Problem]
> - task.timeout.ms does not work when TimeoutException is thrown by streams
> producer
> -- Kafka Streams upgrade guide says, "Kafka Streams is now handling
> TimeoutException thrown by the consumer, producer, and admin client."(1) and
> "To bound how long Kafka Streams retries a task, you can set task.timeout.ms
> (default is 5 minutes)."(1).
> -- However, it doesn't look like task.timeout.ms is working for the streams
> producer, then it seems to keep retrying forever.
> [Environment]
> - Kafka Streams 3.5.0
> [Reproduction procedure]
> # Create "input-topic" topic
> # Put several messages on "input-topic"
> # DONT create "output-topic" topic, to fire TimeoutException
> # Create the following simple Kafka streams program; this program just
> transfers messages from "input-topic" to "output-topic".
> --
> {code:java}
> Properties props = new Properties();
> props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
> props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
> props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
> props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
> props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
> // not needed
> StreamsBuilder builder = new StreamsBuilder();
> builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
> .to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
> KafkaStreams streams = new KafkaStreams(builder.build(), props);
> {code}
> # Wait for task.timeout.ms (default is 5 minutes).
> ## If the debug log is enabled, a large number of
> UNKNOWN_TOPIC_OR_PARTITIONs will be logged because "output-topic" does not
> exist.
> ## And every one minute, TimeoutException will be generated (2)
> # ==> However, it doesn't look like task.timeout.ms is working for the
> streams producer, then it seems to keep retrying forever.
> ## My excepted behavior is that task.timeout.ms is working, and the client
> will be shutdown because the default behavior is
> StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
> [As far as my investigation]
> - TimeoutException thrown by the streams producer is replaced with
> TaskCorruptedException in RecordCollectorImpl.recordSendError(...) (3)
> - And after that it does not appear to be executing code that contains logic
> related to task.timeout.ms.
> (1) Kafka Streams upgrade guide
> - [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
> -
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-572%3A+Improve+timeouts+and+retries+in+Kafka+Streams]
> {code:java}
> Kafka Streams is now handling TimeoutException thrown by the consumer,
> producer, and admin client. If a timeout occurs on a task, Kafka Streams
> moves to the next task and retries to make progress on the failed task in the
> next iteration. To bound how long Kafka Streams retries a task, you can set
> task.timeout.ms (default is 5 minutes). If a task does not make progress
> within the specified task timeout, which is tracked on a per-task basis,
> Kafka Streams throws a TimeoutException (cf. KIP-572).
> {code}
> (2) TimeoutException occurs
> {code:java}
> 2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Error while fetching metadata with correlation id 1065 :
> {output-topic=UNKNOWN_TOPIC_OR_PARTITION}
> 2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Requesting metadata update for topic output-topic due to error
> UNKNOWN_TOPIC_OR_PARTITION
> 2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Updated cluster metadata updateVersion 1064 to
> MetadataCache{clusterId='ulBlb0C3Qdau
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by streams producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms does not work when TimeoutException is thrown by streams
producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the streams
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduction procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the streams
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the streams producer is replaced with
TaskCorruptedException in RecordCollectorImpl.recordSendError(...) (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
- [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
-
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-572%3A+Improve+timeouts+and+retries+in+Kafka+Streams]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
202
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by streams producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms does not work when TimeoutException is thrown by streams
producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the streams
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the streams
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the streams producer is replaced with
TaskCorruptedException in RecordCollectorImpl.recordSendError(...) (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
- [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
-
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-572%3A+Improve+timeouts+and+retries+in+Kafka+Streams]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by streams producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms does not work when TimeoutException is thrown by streams
producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the streams
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
- [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
-
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-572%3A+Improve+timeouts+and+retries+in+Kafka+Streams]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - s
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by streams producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms does not work when TimeoutException is thrown by streams
producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
- [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
-
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-572%3A+Improve+timeouts+and+retries+in+Kafka+Streams]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - st
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by streams producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms does not work when TimeoutException is thrown by streams
producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the streams
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the streams
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the streams producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
- [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
-
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-572%3A+Improve+timeouts+and+retries+in+Kafka+Streams]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 -
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms does not work when TimeoutException is thrown by stream
producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
- [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
-
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-572%3A+Improve+timeouts+and+retries+in+Kafka+Streams]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - str
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by streams producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Summary: task.timeout.ms does not work when TimeoutException is thrown by
streams producer (was: task.timeout.ms does not work when TimeoutException is
thrown by stream producer)
> task.timeout.ms does not work when TimeoutException is thrown by streams
> producer
> -
>
> Key: KAFKA-15108
> URL: https://issues.apache.org/jira/browse/KAFKA-15108
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.0
>Reporter: Tomonari Yamashita
>Priority: Major
>
> [Problem]
> - task.timeout.ms does not work when TimeoutException is thrown by stream
> producer
> -- Kafka Streams upgrade guide says, "Kafka Streams is now handling
> TimeoutException thrown by the consumer, producer, and admin client."(1) and
> "To bound how long Kafka Streams retries a task, you can set task.timeout.ms
> (default is 5 minutes)."(1).
> -- However, it doesn't look like task.timeout.ms is working for the stream
> producer, then it seems to keep retrying forever.
> [Environment]
> - Kafka Streams 3.5.0
> [Reproduce procedure]
> # Create "input-topic" topic
> # Put several messages on "input-topic"
> # DONT create "output-topic" topic, to fire TimeoutException
> # Create the following simple Kafka streams program; this program just
> transfers messages from "input-topic" to "output-topic".
> --
> {code:java}
> Properties props = new Properties();
> props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
> props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
> props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
> props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
> props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
> // not needed
> StreamsBuilder builder = new StreamsBuilder();
> builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
> .to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
> KafkaStreams streams = new KafkaStreams(builder.build(), props);
> {code}
> # Wait for task.timeout.ms (default is 5 minutes).
> ## If the debug log is enabled, a large number of
> UNKNOWN_TOPIC_OR_PARTITIONs will be logged because "output-topic" does not
> exist.
> ## And every one minute, TimeoutException will be generated (2)
> # ==> However, it doesn't look like task.timeout.ms is working for the
> stream producer, then it seems to keep retrying forever.
> ## My excepted behavior is that task.timeout.ms is working, and the client
> will be shutdown because the default behavior is
> StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
> [As far as my investigation]
> - TimeoutException thrown by the stream producer is replaced with
> TaskCorruptedException (3)
> - And after that it does not appear to be executing code that contains logic
> related to task.timeout.ms.
> (1) Kafka Streams upgrade guide
> - [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
> -
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-572%3A+Improve+timeouts+and+retries+in+Kafka+Streams]
> {code:java}
> Kafka Streams is now handling TimeoutException thrown by the consumer,
> producer, and admin client. If a timeout occurs on a task, Kafka Streams
> moves to the next task and retries to make progress on the failed task in the
> next iteration. To bound how long Kafka Streams retries a task, you can set
> task.timeout.ms (default is 5 minutes). If a task does not make progress
> within the specified task timeout, which is tracked on a per-task basis,
> Kafka Streams throws a TimeoutException (cf. KIP-572).
> {code}
> (2) TimeoutException occurs
> {code:java}
> 2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Error while fetching metadata with correlation id 1065 :
> {output-topic=UNKNOWN_TOPIC_OR_PARTITION}
> 2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Requesting metadata update for topic output-topic due to error
> UNKNOWN_TOPIC_OR_PARTITION
> 2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Updated cluster metadata updateVersion 1064 to
> MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
> nodes={0=a86b6e81dded542bb86
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Summary: task.timeout.ms does not work when TimeoutException is thrown by
stream producer (was: Task.timeout.ms does not work when TimeoutException is
thrown by stream producer)
> task.timeout.ms does not work when TimeoutException is thrown by stream
> producer
>
>
> Key: KAFKA-15108
> URL: https://issues.apache.org/jira/browse/KAFKA-15108
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.0
>Reporter: Tomonari Yamashita
>Priority: Major
>
> [Problem]
> - task.timeout.ms does not work when TimeoutException is thrown by stream
> producer
> -- Kafka Streams upgrade guide says, "Kafka Streams is now handling
> TimeoutException thrown by the consumer, producer, and admin client."(1) and
> "To bound how long Kafka Streams retries a task, you can set task.timeout.ms
> (default is 5 minutes)."(1).
> -- However, it doesn't look like task.timeout.ms is working for the stream
> producer, then it seems to keep retrying forever.
> [Environment]
> - Kafka Streams 3.5.0
> [Reproduce procedure]
> # Create "input-topic" topic
> # Put several messages on "input-topic"
> # DONT create "output-topic" topic, to fire TimeoutException
> # Create the following simple Kafka streams program; this program just
> transfers messages from "input-topic" to "output-topic".
> --
> {code:java}
> Properties props = new Properties();
> props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
> props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
> props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
> props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
> props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
> // not needed
> StreamsBuilder builder = new StreamsBuilder();
> builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
> .to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
> KafkaStreams streams = new KafkaStreams(builder.build(), props);
> {code}
> # Wait for task.timeout.ms (default is 5 minutes).
> ## If the debug log is enabled, a large number of
> UNKNOWN_TOPIC_OR_PARTITIONs will be logged because "output-topic" does not
> exist.
> ## And every one minute, TimeoutException will be generated (2)
> # ==> However, it doesn't look like task.timeout.ms is working for the
> stream producer, then it seems to keep retrying forever.
> ## My excepted behavior is that task.timeout.ms is working, and the client
> will be shutdown because the default behavior is
> StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
> [As far as my investigation]
> - TimeoutException thrown by the stream producer is replaced with
> TaskCorruptedException (3)
> - And after that it does not appear to be executing code that contains logic
> related to task.timeout.ms.
> (1) Kafka Streams upgrade guide
> [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
> {code:java}
> Kafka Streams is now handling TimeoutException thrown by the consumer,
> producer, and admin client. If a timeout occurs on a task, Kafka Streams
> moves to the next task and retries to make progress on the failed task in the
> next iteration. To bound how long Kafka Streams retries a task, you can set
> task.timeout.ms (default is 5 minutes). If a task does not make progress
> within the specified task timeout, which is tracked on a per-task basis,
> Kafka Streams throws a TimeoutException (cf. KIP-572).
> {code}
> (2) TimeoutException occurs
> {code:java}
> 2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Error while fetching metadata with correlation id 1065 :
> {output-topic=UNKNOWN_TOPIC_OR_PARTITION}
> 2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Requesting metadata update for topic output-topic due to error
> UNKNOWN_TOPIC_OR_PARTITION
> 2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Updated cluster metadata updateVersion 1064 to
> MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
> nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
> (id: 0 rack: null),
> 1=a99402a2de0054c2a96e87075df0f5
[jira] [Updated] (KAFKA-15108) task.timeout.ms does not work when TimeoutException is thrown by stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms does not work when TimeoutException is thrown by stream
producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
[https://kafka.apache.org/35/documentation/streams/upgrade-guide]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1]
stream-task [0_0] Error encou
[jira] [Updated] (KAFKA-15108) Task.timeout.ms does not work when TimeoutException is thrown by stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms does not work when TimeoutException is thrown by stream
producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
[https://kafka.apache.org/35/documentation/streams/upgrade-guide]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1]
stream-task [0_0] Error enco
[jira] [Updated] (KAFKA-15108) Task.timeout.ms does not work when TimeoutException is thrown by stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Summary: Task.timeout.ms does not work when TimeoutException is thrown by
stream producer (was: task.timeout.ms doesn't work for the stream producer)
> Task.timeout.ms does not work when TimeoutException is thrown by stream
> producer
>
>
> Key: KAFKA-15108
> URL: https://issues.apache.org/jira/browse/KAFKA-15108
> Project: Kafka
> Issue Type: Bug
> Components: streams
>Affects Versions: 3.5.0
>Reporter: Tomonari Yamashita
>Priority: Major
>
> [Problem]
> - task.timeout.ms doesn't work for the stream producer
> -- Kafka Streams upgrade guide says, "Kafka Streams is now handling
> TimeoutException thrown by the consumer, producer, and admin client."(1) and
> "To bound how long Kafka Streams retries a task, you can set task.timeout.ms
> (default is 5 minutes)."(1).
> -- However, it doesn't look like task.timeout.ms is working for the stream
> producer, then it seems to keep retrying forever.
> [Environment]
> - Kafka Streams 3.5.0
> [Reproduce procedure]
> # Create "input-topic" topic
> # Put several messages on "input-topic"
> # DONT create "output-topic" topic, to fire TimeoutException
> # Create the following simple Kafka streams program; this program just
> transfers messages from "input-topic" to "output-topic".
> --
> {code:java}
> Properties props = new Properties();
> props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
> props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
> props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
> props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
> props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
> // not needed
> StreamsBuilder builder = new StreamsBuilder();
> builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
> .to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
> KafkaStreams streams = new KafkaStreams(builder.build(), props);
> {code}
> # Wait for task.timeout.ms (default is 5 minutes).
> ## If the debug log is enabled, a large number of
> UNKNOWN_TOPIC_OR_PARTITIONs will be logged because "output-topic" does not
> exist.
> ## And every one minute, TimeoutException will be generated (2)
> # ==> However, it doesn't look like task.timeout.ms is working for the
> stream producer, then it seems to keep retrying forever.
> ## My excepted behavior is that task.timeout.ms is working, and the client
> will be shutdown because the default behavior is
> StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
> [As far as my investigation]
> - TimeoutException thrown by the stream producer is replaced with
> TaskCorruptedException (3)
> - And after that it does not appear to be executing code that contains logic
> related to task.timeout.ms.
> (1) Kafka Streams upgrade guide
> [https://kafka.apache.org/35/documentation/streams/upgrade-guide]
> {code:java}
> Kafka Streams is now handling TimeoutException thrown by the consumer,
> producer, and admin client. If a timeout occurs on a task, Kafka Streams
> moves to the next task and retries to make progress on the failed task in the
> next iteration. To bound how long Kafka Streams retries a task, you can set
> task.timeout.ms (default is 5 minutes). If a task does not make progress
> within the specified task timeout, which is tracked on a per-task basis,
> Kafka Streams throws a TimeoutException (cf. KIP-572).
> {code}
> (2) TimeoutException occurs
> {code:java}
> 2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Error while fetching metadata with correlation id 1065 :
> {output-topic=UNKNOWN_TOPIC_OR_PARTITION}
> 2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Requesting metadata update for topic output-topic due to error
> UNKNOWN_TOPIC_OR_PARTITION
> 2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
> clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
> Updated cluster metadata updateVersion 1064 to
> MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
> nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
> (id: 0 rack: null),
> 1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
> (id: 1
[jira] [Updated] (KAFKA-15108) task.timeout.ms doesn't work for the stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms doesn't work for the stream producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged because "output-topic" does not exist.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
[https://kafka.apache.org/35/documentation/streams/upgrade-guide]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1]
stream-task [0_0] Error encountered sending record to topi
[jira] [Updated] (KAFKA-15108) task.timeout.ms doesn't work for the stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms doesn't work for the stream producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeoutException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
[https://kafka.apache.org/35/documentation/streams/upgrade-guide]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1]
stream-task [0_0] Error encountered sending record to topic output-topic for
task 0_0 due to:
o
[jira] [Updated] (KAFKA-15108) task.timeout.ms doesn't work for the stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms doesn't work for the stream producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged.
## And every one minute, TimeoutException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeoutException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
[https://kafka.apache.org/35/documentation/streams/upgrade-guide]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1]
stream-task [0_0] Error encountered sending record to topic output-topic for
task 0_0 due to:
org.a
[jira] [Updated] (KAFKA-15108) task.timeout.ms doesn't work for the stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms doesn't work for the stream producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
--
{code:java}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged.
## And every one minute, TimeException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
[https://kafka.apache.org/35/documentation/streams/upgrade-guide]
{code:java}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1]
stream-task [0_0] Error encountered sending record to topic output-topic for
task 0_0 due to:
org.apache
[jira] [Updated] (KAFKA-15108) task.timeout.ms doesn't work for the stream producer
[
https://issues.apache.org/jira/browse/KAFKA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomonari Yamashita updated KAFKA-15108:
---
Description:
[Problem]
- task.timeout.ms doesn't work for the stream producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
-- {code}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged.
## And every one minute, TimeException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
## My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
https://kafka.apache.org/35/documentation/streams/upgrade-guide
{code}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - stream-thread
[java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1]
stream-task [0_0] Error encountered sending record to topic output-topic for
task 0_0 due to:
org.apache.kafka.common.errors
[jira] [Created] (KAFKA-15108) task.timeout.ms doesn't work for the stream producer
Tomonari Yamashita created KAFKA-15108:
--
Summary: task.timeout.ms doesn't work for the stream producer
Key: KAFKA-15108
URL: https://issues.apache.org/jira/browse/KAFKA-15108
Project: Kafka
Issue Type: Bug
Components: streams
Affects Versions: 3.5.0
Reporter: Tomonari Yamashita
[Problem]
- task.timeout.ms doesn't work for the stream producer
-- Kafka Streams upgrade guide says, "Kafka Streams is now handling
TimeoutException thrown by the consumer, producer, and admin client."(1) and
"To bound how long Kafka Streams retries a task, you can set task.timeout.ms
(default is 5 minutes)."(1).
-- However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
[Environment]
- Kafka Streams 3.5.0
[Reproduce procedure]
# Create "input-topic" topic
# Put several messages on "input-topic"
# DONT create "output-topic" topic, to fire TimeException
# Create the following simple Kafka streams program; this program just
transfers messages from "input-topic" to "output-topic".
-- {code}
Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "java-kafka-streams");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serdes$StringSerde");
props.put(StreamsConfig.DEFAULT_PRODUCTION_EXCEPTION_HANDLER_CLASS_CONFIG,"com.example.CustomProductionExceptionHandler");
// not needed
StreamsBuilder builder = new StreamsBuilder();
builder.stream("input-topic", Consumed.with(Serdes.String(), Serdes.String()))
.to("output-topic", Produced.with(Serdes.String(), Serdes.String()));
KafkaStreams streams = new KafkaStreams(builder.build(), props);
{code}
# Wait for task.timeout.ms (default is 5 minutes).
## If the debug log is enabled, a large number of UNKNOWN_TOPIC_OR_PARTITIONs
will be logged.
## And every one minute, TimeException will be generated (2)
# ==> However, it doesn't look like task.timeout.ms is working for the stream
producer, then it seems to keep retrying forever.
# ==> My excepted behavior is that task.timeout.ms is working, and the client
will be shutdown because the default behavior is
StreamThreadExceptionResponse.SHUTDOWN_CLIENT when an exception is thrown.
[As far as my investigation]
- TimeException thrown by the stream producer is replaced with
TaskCorruptedException (3)
- And after that it does not appear to be executing code that contains logic
related to task.timeout.ms.
(1) Kafka Streams upgrade guide
https://kafka.apache.org/35/documentation/streams/upgrade-guide
{code}
Kafka Streams is now handling TimeoutException thrown by the consumer,
producer, and admin client. If a timeout occurs on a task, Kafka Streams moves
to the next task and retries to make progress on the failed task in the next
iteration. To bound how long Kafka Streams retries a task, you can set
task.timeout.ms (default is 5 minutes). If a task does not make progress within
the specified task timeout, which is tracked on a per-task basis, Kafka Streams
throws a TimeoutException (cf. KIP-572).
{code}
(2) TimeoutException occurs
{code:java}
2023-06-19 19:51:26 WARN NetworkClient:1145 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Error while fetching metadata with correlation id 1065 :
{output-topic=UNKNOWN_TOPIC_OR_PARTITION}
2023-06-19 19:51:26 DEBUG Metadata:363 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Requesting metadata update for topic output-topic due to error
UNKNOWN_TOPIC_OR_PARTITION
2023-06-19 19:51:26 DEBUG Metadata:291 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Updated cluster metadata updateVersion 1064 to
MetadataCache{clusterId='ulBlb0C3QdaurHgFmPLYew',
nodes={0=a86b6e81dded542bb867337e34fa7954-1776321381.ap-northeast-1.elb.amazonaws.com:9094
(id: 0 rack: null),
1=a99402a2de0054c2a96e87075df0f545-254291543.ap-northeast-1.elb.amazonaws.com:9094
(id: 1 rack: null),
2=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}, partitions=[],
controller=a82f92d2e86d145b48447de89694d879-1900034172.ap-northeast-1.elb.amazonaws.com:9094
(id: 2 rack: null)}
2023-06-19 19:51:26 DEBUG KafkaProducer:1073 - [Producer
clientId=java-kafka-streams-8dd73f1e-f9b6-4058-895f-448143c4e5cf-StreamThread-1-producer]
Exception occurred during message send:
org.apache.kafka.common.errors.TimeoutException: Topic output-topic not present
in metadata after 6 ms.
2023-06-19 19:51:26 ERROR RecordCollectorImpl:322 - stream-thread
[java
[jira] [Created] (KAFKA-13996) log.cleaner.io.max.bytes.per.second cannot be changed dynamically
Tomonari Yamashita created KAFKA-13996:
--
Summary: log.cleaner.io.max.bytes.per.second cannot be changed
dynamically
Key: KAFKA-13996
URL: https://issues.apache.org/jira/browse/KAFKA-13996
Project: Kafka
Issue Type: Bug
Components: config, core, log cleaner
Affects Versions: 3.2.0
Reporter: Tomonari Yamashita
Assignee: Tomonari Yamashita
- log.cleaner.io.max.bytes.per.second cannot be changed dynamically using
bin/kafka-configs.sh
- Reproduction procedure:
-# Create a topic with cleanup.policy=compact
{code:java}
bin/kafka-topics.sh --bootstrap-server localhost:9092 --create
--replication-factor 1 --partitions 1 --topic my-topic --config
cleanup.policy=compact --config cleanup.policy=compact --config
segment.bytes=104857600 --config compression.type=producer
{code}
-# Change log.cleaner.io.max.bytes.per.second=10485760 using
bin/kafka-configs.sh
{code:java}
bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers
--entity-default --alter --add-config
log.cleaner.io.max.bytes.per.second=10485760
{code}
-# Send enough messages(> segment.bytes=104857600) to activate Log Cleaner
-# logs/log-cleaner.log, configuration by
log.cleaner.io.max.bytes.per.second=10485760 is not reflected and Log Cleaner
does not slow down (>= log.cleaner.io.max.bytes.per.second=10485760).
{code:java}
[2022-06-15 14:52:14,988] INFO [kafka-log-cleaner-thread-0]:
Log cleaner thread 0 cleaned log my-topic-0 (dirty section = [39786,
81666])
3,999.0 MB of log processed in 2.7 seconds (1,494.4 MB/sec).
Indexed 3,998.9 MB in 0.9 seconds (4,218.2 Mb/sec, 35.4% of total time)
Buffer utilization: 0.0%
Cleaned 3,999.0 MB in 1.7 seconds (2,314.2 Mb/sec, 64.6% of total time)
Start size: 3,999.0 MB (41,881 messages)
End size: 0.1 MB (1 messages)
100.0% size reduction (100.0% fewer messages)
(kafka.log.LogCleaner)
{code}
- Problem cause:
-- log.cleaner.io.max.bytes.per.second is used in Throttler in LogCleaner,
however, it is only passed to Throttler at initialization time.
---
https://github.com/apache/kafka/blob/4380eae7ceb840dd93fee8ec90cd89a72bad7a3f/core/src/main/scala/kafka/log/LogCleaner.scala#L107-L112
-- Need to change Throttler configuration value at reconfigure() of LogCleaner.
---
https://github.com/apache/kafka/blob/4380eae7ceb840dd93fee8ec90cd89a72bad7a3f/core/src/main/scala/kafka/log/LogCleaner.scala#L192-L196
- A workaround is that restarting every broker adding
log.cleaner.io.max.bytes.per.second to config/server.properties
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita closed KAFKA-13619. -- > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Assignee: Tomonari Yamashita >Priority: Minor > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > - I've submitted pull request : " KAFKA-13619: zookeeper.sync.time.ms is no > longer used [#11717|https://github.com/apache/kafka/pull/11717]"; > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Priority: Minor (was: Major) > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Assignee: Tomonari Yamashita >Priority: Minor > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > - I've submitted pull request : " KAFKA-13619: zookeeper.sync.time.ms is no > longer used [#11717|https://github.com/apache/kafka/pull/11717]"; > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita reassigned KAFKA-13619: -- Assignee: Tomonari Yamashita > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Assignee: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > - I've submitted pull request : " KAFKA-13619: zookeeper.sync.time.ms is no > longer used [#11717|https://github.com/apache/kafka/pull/11717]"; > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Description: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. - I've submitted pull request : " KAFKA-13619: zookeeper.sync.time.ms is no longer used [#11717|https://github.com/apache/kafka/pull/11717]"; (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] was: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). - I've submitted pull request : " KAFKA-13619: zookeeper.sync.time.ms is no longer used [#11717|https://github.com/apache/kafka/pull/11717]"; (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > - I've submitted pull request : " KAFKA-13619: zookeeper.sync.time.ms is no > longer used [#11717|https://github.com/apache/kafka/pull/11717]"; > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Description: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). - I've submitted pull request : " KAFKA-13619: zookeeper.sync.time.ms is no longer used [#11717|https://github.com/apache/kafka/pull/11717]"; (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] was: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). - I've submitted pull request : "[#11717] KAFKA-13619: zookeeper.sync.time.ms is no longer used" (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > -- Although for a different purpose and base is old, there is a pull request > that tried to remove it (2). > - I've submitted pull request : " KAFKA-13619: zookeeper.sync.time.ms is no > longer used [#11717|https://github.com/apache/kafka/pull/11717]"; > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] > (2) [https://github.com/apache/kafka/pull/3167] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Description: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). - I've submitted pull request : "[#11717] KAFKA-13619: zookeeper.sync.time.ms is no longer used" (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] was: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). - I've submitted "[#11717] KAFKA-13619: zookeeper.sync.time.ms is no longer used" (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > -- Although for a different purpose and base is old, there is a pull request > that tried to remove it (2). > - I've submitted pull request : "[#11717] KAFKA-13619: > zookeeper.sync.time.ms is no longer used" > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] > (2) [https://github.com/apache/kafka/pull/3167] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Description: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). - I've submitted "[#11717] KAFKA-13619: zookeeper.sync.time.ms is no longer used" (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] was: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). - (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > -- Although for a different purpose and base is old, there is a pull request > that tried to remove it (2). > - I've submitted "[#11717] KAFKA-13619: zookeeper.sync.time.ms is no longer > used" > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] > (2) [https://github.com/apache/kafka/pull/3167] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Description: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). - (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] was: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > -- Although for a different purpose and base is old, there is a pull request > that tried to remove it (2). > - > > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] > (2) [https://github.com/apache/kafka/pull/3167] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Description: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and old, there is a pull request that tried to remove it (2). (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] was: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose, there is a pull request that tried to remove it (2). (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) https://github.com/apache/kafka/pull/3167 > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > -- Although for a different purpose and old, there is a pull request that > tried to remove it (2). > > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] > (2) [https://github.com/apache/kafka/pull/3167] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Description: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and base is old, there is a pull request that tried to remove it (2). (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] was: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose and old, there is a pull request that tried to remove it (2). (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) [https://github.com/apache/kafka/pull/3167] > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > -- Although for a different purpose and base is old, there is a pull request > that tried to remove it (2). > > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] > (2) [https://github.com/apache/kafka/pull/3167] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Description: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation (1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- As far as I can see, it was already out of use by v2.0.0. -- Although for a different purpose, there is a pull request that tried to remove it (2). (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] (2) https://github.com/apache/kafka/pull/3167 was: - zookeeper.sync.time.ms is no longer used. But it is present in the documentation(1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- FYI, as far as I can see, it was already out of use by v2.0.0. (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation (1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- As far as I can see, it was already out of use by v2.0.0. > -- Although for a different purpose, there is a pull request that tried to > remove it (2). > > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] > (2) https://github.com/apache/kafka/pull/3167 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
[ https://issues.apache.org/jira/browse/KAFKA-13619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomonari Yamashita updated KAFKA-13619: --- Component/s: core documentation > zookeeper.sync.time.ms is no longer used > > > Key: KAFKA-13619 > URL: https://issues.apache.org/jira/browse/KAFKA-13619 > Project: Kafka > Issue Type: Bug > Components: core, documentation >Affects Versions: 2.0.0, 3.1.0 >Reporter: Tomonari Yamashita >Priority: Major > > - zookeeper.sync.time.ms is no longer used. But it is present in the > documentation(1) > -- The implementation and documentation of zookeeper.sync.time.ms should be > removed. > -- FYI, as far as I can see, it was already out of use by v2.0.0. > > (1) > [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (KAFKA-13619) zookeeper.sync.time.ms is no longer used
Tomonari Yamashita created KAFKA-13619: -- Summary: zookeeper.sync.time.ms is no longer used Key: KAFKA-13619 URL: https://issues.apache.org/jira/browse/KAFKA-13619 Project: Kafka Issue Type: Bug Affects Versions: 3.1.0, 2.0.0 Reporter: Tomonari Yamashita - zookeeper.sync.time.ms is no longer used. But it is present in the documentation(1) -- The implementation and documentation of zookeeper.sync.time.ms should be removed. -- FYI, as far as I can see, it was already out of use by v2.0.0. (1) [https://kafka.apache.org/documentation/#brokerconfigs_zookeeper.sync.time.ms] -- This message was sent by Atlassian Jira (v8.20.1#820001)
