[jira] [Commented] (KAFKA-14275) KRaft Controllers should crash after failing to apply any metadata record
[ https://issues.apache.org/jira/browse/KAFKA-14275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612452#comment-17612452 ] Niket Goel commented on KAFKA-14275: PR – https://github.com/apache/kafka/pull/12709 > KRaft Controllers should crash after failing to apply any metadata record > -- > > Key: KAFKA-14275 > URL: https://issues.apache.org/jira/browse/KAFKA-14275 > Project: Kafka > Issue Type: Bug > Components: kraft >Affects Versions: 3.3.1 >Reporter: Niket Goel >Assignee: Niket Goel >Priority: Major > > When replaying records on a standby controller, any error encountered will > halt further processing of that batch. Currently we log an error and allow > the controller to continue normal operation. In contrast a similar error on > the active controller causes it to halt and exit the jvm. This is > inconsistent behavior as nothing prevents a standby from eventually becoming > the active controller (even when it had skipped over a record batch). We > should halt the process in the case of a standby controller as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (KAFKA-14275) KRaft Controllers should crash after failing to apply any metadata record
[ https://issues.apache.org/jira/browse/KAFKA-14275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niket Goel reassigned KAFKA-14275: -- Assignee: Niket Goel > KRaft Controllers should crash after failing to apply any metadata record > -- > > Key: KAFKA-14275 > URL: https://issues.apache.org/jira/browse/KAFKA-14275 > Project: Kafka > Issue Type: Bug > Components: kraft >Affects Versions: 3.3.1 >Reporter: Niket Goel >Assignee: Niket Goel >Priority: Major > > When replaying records on a standby controller, any error encountered will > halt further processing of that batch. Currently we log an error and allow > the controller to continue normal operation. In contrast a similar error on > the active controller causes it to halt and exit the jvm. This is > inconsistent behavior as nothing prevents a standby from eventually becoming > the active controller (even when it had skipped over a record batch). We > should halt the process in the case of a standby controller as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-14275) KRaft Controllers should crash after failing to apply any metadata record
Niket Goel created KAFKA-14275: -- Summary: KRaft Controllers should crash after failing to apply any metadata record Key: KAFKA-14275 URL: https://issues.apache.org/jira/browse/KAFKA-14275 Project: Kafka Issue Type: Bug Components: kraft Affects Versions: 3.3.1 Reporter: Niket Goel When replaying records on a standby controller, any error encountered will halt further processing of that batch. Currently we log an error and allow the controller to continue normal operation. In contrast a similar error on the active controller causes it to halt and exit the jvm. This is inconsistent behavior as nothing prevents a standby from eventually becoming the active controller (even when it had skipped over a record batch). We should halt the process in the case of a standby controller as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (KAFKA-14274) Implement fetching logic
Philip Nee created KAFKA-14274: -- Summary: Implement fetching logic Key: KAFKA-14274 URL: https://issues.apache.org/jira/browse/KAFKA-14274 Project: Kafka Issue Type: Sub-task Components: consumer Reporter: Philip Nee The fetch request and fetch processing should happen asynchronously. More specifically, we have the background thread to send fetch requests autonomously and relay the response back to the polling thread. The polling thread collects these fetch requests and returns the ConsumerRecord. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-14273) Kafka doesn't start with KRaft on Windows
[
https://issues.apache.org/jira/browse/KAFKA-14273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kedar Joshi updated KAFKA-14273:
Description:
{{Basic setup doesn't work on Windows 10.}}
*{{Steps}}*
* {{Initialize cluster with -}}
{code:sh}
bin\windows\kafka-storage.bat random-uuid
bin\windows\kafka-storage.bat format -t %cluster_id% -c
.\config\kraft\server.properties{code}
* Start Kafka with -
{code:sh}
bin\windows\kafka-server-start.bat .\config\kraft\server.properties{code}
*Stacktrace*
Kafka fails to start with following exception -
{code:java}
D:\LocationGuru\Servers\Kafka-3.3>bin\windows\kafka-server-start.bat
.\config\kraft\server.properties
[2022-10-03 23:14:20,089] INFO Registered kafka:type=kafka.Log4jController
MBean (kafka.utils.Log4jControllerRegistration$)
[2022-10-03 23:14:20,375] INFO Setting -D
jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated TLS
renegotiation (org.apache.zookeeper.common.X509Util)
[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Loading producer
state till offset 0 with message format version 2 (kafka.log.UnifiedLog$)
[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Reloading from
producer snapshot and rebuilding producer state from offset 0
(kafka.log.UnifiedLog$)
[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Producer state
recovery took 0ms for snapshot load and 0ms for segment recovery from offset 0
(kafka.log.UnifiedLog$)
[2022-10-03 23:14:20,640] INFO Initialized snapshots with IDs SortedSet() from
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0
(kafka.raft.KafkaMetadataLog$)
[2022-10-03 23:14:20,734] INFO [raft-expiration-reaper]: Starting
(kafka.raft.TimingWheelExpirationService$ExpiredOperationReaper)
[2022-10-03 23:14:20,900] ERROR Exiting Kafka due to fatal exception
(kafka.Kafka$)
java.io.UncheckedIOException: Error while writing the Quorum status from the
file
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0\quorum-state
at
org.apache.kafka.raft.FileBasedStateStore.writeElectionStateToFile(FileBasedStateStore.java:155)
at
org.apache.kafka.raft.FileBasedStateStore.writeElectionState(FileBasedStateStore.java:128)
at org.apache.kafka.raft.QuorumState.transitionTo(QuorumState.java:477)
at org.apache.kafka.raft.QuorumState.initialize(QuorumState.java:212)
at
org.apache.kafka.raft.KafkaRaftClient.initialize(KafkaRaftClient.java:369)
at kafka.raft.KafkaRaftManager.buildRaftClient(RaftManager.scala:200)
at kafka.raft.KafkaRaftManager.(RaftManager.scala:127)
at kafka.server.KafkaRaftServer.(KafkaRaftServer.scala:83)
at kafka.Kafka$.buildServer(Kafka.scala:79)
at kafka.Kafka$.main(Kafka.scala:87)
at kafka.Kafka.main(Kafka.scala)
Caused by: java.nio.file.FileSystemException:
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs_cluster_metadata-0\quorum-state.tmp
->
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs_cluster_metadata-0\quorum-state:
The process cannot access the file because it is being used by another process
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:403)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
at java.base/java.nio.file.Files.move(Files.java:1430)
at
org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:935)
at
org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:918)
at
org.apache.kafka.raft.FileBasedStateStore.writeElectionStateToFile(FileBasedStateStore.java:152)
... 10 more
Suppressed: java.nio.file.FileSystemException:
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs_cluster_metadata-0\quorum-state.tmp
->
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs_cluster_metadata-0\quorum-state:
The process cannot access the file because it is being used by another process
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at
java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
at
[jira] [Updated] (KAFKA-14273) Kafka doesn't start with KRaft on Windows
[
https://issues.apache.org/jira/browse/KAFKA-14273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kedar Joshi updated KAFKA-14273:
Description:
{{Basic cluster setup doesn't work on Windows 10.}}
*{{Steps}}*
* {{Initialize cluster with -}}
{code:sh}
bin\windows\kafka-storage.bat random-uuid
bin\windows\kafka-storage.bat format -t %cluster_id% -c
.\config\kraft\server.properties{code}
* Start Kafka with -
{code:sh}
bin\windows\kafka-server-start.bat .\config\kraft\server.properties{code}
*Stacktrace*
Kafka fails to start with following exception -
{code:java}
D:\LocationGuru\Servers\Kafka-3.3>bin\windows\kafka-server-start.bat
.\config\kraft\server.properties
[2022-10-03 23:14:20,089] INFO Registered kafka:type=kafka.Log4jController
MBean (kafka.utils.Log4jControllerRegistration$)
[2022-10-03 23:14:20,375] INFO Setting -D
jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated TLS
renegotiation (org.apache.zookeeper.common.X509Util)
[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Loading producer
state till offset 0 with message format version 2 (kafka.log.UnifiedLog$)
[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Reloading from
producer snapshot and rebuilding producer state from offset 0
(kafka.log.UnifiedLog$)
[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Producer state
recovery took 0ms for snapshot load and 0ms for segment recovery from offset 0
(kafka.log.UnifiedLog$)
[2022-10-03 23:14:20,640] INFO Initialized snapshots with IDs SortedSet() from
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0
(kafka.raft.KafkaMetadataLog$)
[2022-10-03 23:14:20,734] INFO [raft-expiration-reaper]: Starting
(kafka.raft.TimingWheelExpirationService$ExpiredOperationReaper)
[2022-10-03 23:14:20,900] ERROR Exiting Kafka due to fatal exception
(kafka.Kafka$)
java.io.UncheckedIOException: Error while writing the Quorum status from the
file
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0\quorum-state
at
org.apache.kafka.raft.FileBasedStateStore.writeElectionStateToFile(FileBasedStateStore.java:155)
at
org.apache.kafka.raft.FileBasedStateStore.writeElectionState(FileBasedStateStore.java:128)
at org.apache.kafka.raft.QuorumState.transitionTo(QuorumState.java:477)
at org.apache.kafka.raft.QuorumState.initialize(QuorumState.java:212)
at
org.apache.kafka.raft.KafkaRaftClient.initialize(KafkaRaftClient.java:369)
at kafka.raft.KafkaRaftManager.buildRaftClient(RaftManager.scala:200)
at kafka.raft.KafkaRaftManager.(RaftManager.scala:127)
at kafka.server.KafkaRaftServer.(KafkaRaftServer.scala:83)
at kafka.Kafka$.buildServer(Kafka.scala:79)
at kafka.Kafka$.main(Kafka.scala:87)
at kafka.Kafka.main(Kafka.scala)
Caused by: java.nio.file.FileSystemException:
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs_cluster_metadata-0\quorum-state.tmp
->
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs_cluster_metadata-0\quorum-state:
The process cannot access the file because it is being used by another process
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:403)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
at java.base/java.nio.file.Files.move(Files.java:1430)
at
org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:935)
at
org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:918)
at
org.apache.kafka.raft.FileBasedStateStore.writeElectionStateToFile(FileBasedStateStore.java:152)
... 10 more
Suppressed: java.nio.file.FileSystemException:
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs_cluster_metadata-0\quorum-state.tmp
->
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs_cluster_metadata-0\quorum-state:
The process cannot access the file because it is being used by another process
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at
java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
at
[jira] [Created] (KAFKA-14273) Kafka doesn't start with KRaft on Windows
Kedar Joshi created KAFKA-14273:
---
Summary: Kafka doesn't start with KRaft on Windows
Key: KAFKA-14273
URL: https://issues.apache.org/jira/browse/KAFKA-14273
Project: Kafka
Issue Type: Bug
Components: kraft
Affects Versions: 3.3.1
Reporter: Kedar Joshi
{{Basic cluster setup doesn't work on Windows 10.}}
*{{Steps}}*
* {{Initialize cluster with -}}
{{ bin\windows\kafka-storage.bat random-uuid}}
{{ bin\windows\kafka-storage.bat format -t %cluster_id% -c
.\config\kraft\server.properties}}
* Start Kafka with -
{{ bin\windows\kafka-server-start.bat .\config\kraft\server.properties}}
*Stacktrace*
Kafka fails to start with following exception -
{{D:\LocationGuru\Servers\Kafka-3.3>bin\windows\kafka-server-start.bat
.\config\kraft\server.properties}}
{{[2022-10-03 23:14:20,089] INFO Registered kafka:type=kafka.Log4jController
MBean (kafka.utils.Log4jControllerRegistration$)}}
{{[2022-10-03 23:14:20,375] INFO Setting -D
jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated TLS
renegotiation (org.apache.zookeeper.common.X509Util)}}
{{[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Loading producer
state till offset 0 with message format version 2 (kafka.log.UnifiedLog$)}}
{{[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Reloading from
producer snapshot and rebuilding producer state from offset 0
(kafka.log.UnifiedLog$)}}
{{[2022-10-03 23:14:20,594] INFO [LogLoader partition=__cluster_metadata-0,
dir=D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs] Producer state
recovery took 0ms for snapshot load and 0ms for segment recovery from offset 0
(kafka.log.UnifiedLog$)}}
{{[2022-10-03 23:14:20,640] INFO Initialized snapshots with IDs SortedSet()
from
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0
(kafka.raft.KafkaMetadataLog$)}}
{{[2022-10-03 23:14:20,734] INFO [raft-expiration-reaper]: Starting
(kafka.raft.TimingWheelExpirationService$ExpiredOperationReaper)}}
{{[2022-10-03 23:14:20,900] ERROR Exiting Kafka due to fatal exception
(kafka.Kafka$)}}
{{java.io.UncheckedIOException: Error while writing the Quorum status from the
file
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0\quorum-state}}
{{ at
org.apache.kafka.raft.FileBasedStateStore.writeElectionStateToFile(FileBasedStateStore.java:155)}}
{{ at
org.apache.kafka.raft.FileBasedStateStore.writeElectionState(FileBasedStateStore.java:128)}}
{{ at
org.apache.kafka.raft.QuorumState.transitionTo(QuorumState.java:477)}}
{{ at
org.apache.kafka.raft.QuorumState.initialize(QuorumState.java:212)}}
{{ at
org.apache.kafka.raft.KafkaRaftClient.initialize(KafkaRaftClient.java:369)}}
{{ at
kafka.raft.KafkaRaftManager.buildRaftClient(RaftManager.scala:200)}}
{{ at kafka.raft.KafkaRaftManager.(RaftManager.scala:127)}}
{{ at kafka.server.KafkaRaftServer.(KafkaRaftServer.scala:83)}}
{{ at kafka.Kafka$.buildServer(Kafka.scala:79)}}
{{ at kafka.Kafka$.main(Kafka.scala:87)}}
{{ at kafka.Kafka.main(Kafka.scala)}}
{{Caused by: java.nio.file.FileSystemException:
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0\quorum-state.tmp
->
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0\quorum-state:
The process cannot access the file because it is being used by another
process}}
{{ at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)}}
{{ at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)}}
{{ at
java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:403)}}
{{ at
java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)}}
{{ at java.base/java.nio.file.Files.move(Files.java:1430)}}
{{ at
org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:935)}}
{{ at
org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:918)}}
{{ at
org.apache.kafka.raft.FileBasedStateStore.writeElectionStateToFile(FileBasedStateStore.java:152)}}
{{ ... 10 more}}
{{ Suppressed: java.nio.file.FileSystemException:
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0\quorum-state.tmp
->
D:\LocationGuru\Servers\Kafka-3.3\tmp\kraft-combined-logs__cluster_metadata-0\quorum-state:
The process cannot access the file because it is being used by another
process}}
{{ at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)}}
{{ at
[jira] [Updated] (KAFKA-14247) Implement EventHandler interface and DefaultEventHandler
[ https://issues.apache.org/jira/browse/KAFKA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Nee updated KAFKA-14247: --- Description: The background thread runs inside of the DefaultEventHandler to consume events from the ApplicationEventQueue and produce events to the BackgroundEventQueue. The background thread runnable consist of a loop that tries to poll events from the ApplicationQueue, processes the event if there are any, and poll networkClient. In this implementation, the DefaultEventHandler spawns a thread that runs the BackgroundThreadRunnable. The runnable, as of the current PR, does the following things: # Initialize the networkClient # Poll ApplicationEvent from the queue if there's any # process the event # poll the networkClient PR: https://github.com/apache/kafka/pull/12672 was: The background thread runs inside of the DefaultEventHandler to consume events from the ApplicationEventQueue and produce events to the BackgroundEventQueue. The background thread runnable consist of a loop that tries to poll events from the ApplicationQueue, processes the event if there are any, and poll networkClient. In this implementation, the DefaultEventHandler spawns a thread that runs the BackgroundThreadRunnable. The runnable, as of the current PR, does the following things: # Initialize the networkClient # Poll ApplicationEvent from the queue if there's any # process the event # poll the networkClient PR: [https://github.com/apache/kafka/pull/12663] > Implement EventHandler interface and DefaultEventHandler > > > Key: KAFKA-14247 > URL: https://issues.apache.org/jira/browse/KAFKA-14247 > Project: Kafka > Issue Type: Sub-task > Components: consumer >Reporter: Philip Nee >Assignee: Philip Nee >Priority: Major > > The background thread runs inside of the DefaultEventHandler to consume > events from the ApplicationEventQueue and produce events to the > BackgroundEventQueue. > The background thread runnable consist of a loop that tries to poll events > from the ApplicationQueue, processes the event if there are any, and poll > networkClient. > In this implementation, the DefaultEventHandler spawns a thread that runs the > BackgroundThreadRunnable. The runnable, as of the current PR, does the > following things: > # Initialize the networkClient > # Poll ApplicationEvent from the queue if there's any > # process the event > # poll the networkClient > PR: https://github.com/apache/kafka/pull/12672 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (KAFKA-14247) Implement EventHandler interface and DefaultEventHandler
[
https://issues.apache.org/jira/browse/KAFKA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Nee updated KAFKA-14247:
---
Description:
The background thread runs inside of the DefaultEventHandler to consume events
from the ApplicationEventQueue and produce events to the BackgroundEventQueue.
The background thread runnable consist of a loop that tries to poll events from
the ApplicationQueue, processes the event if there are any, and poll
networkClient.
In this implementation, the DefaultEventHandler spawns a thread that runs the
BackgroundThreadRunnable. The runnable, as of the current PR, does the
following things:
# Initialize the networkClient
# Poll ApplicationEvent from the queue if there's any
# process the event
# poll the networkClient
PR: [https://github.com/apache/kafka/pull/12663]
was:
The polling thread uses events to communicate with the background thread. The
events send to the background thread are the {_}Requests{_}, and the events
send from the background thread to the polling thread are the {_}Responses{_}.
Here we have an EventHandler interface and DefaultEventHandler implementation.
The implementation uses two blocking queues to send events both ways. The two
methods, add and poll allows the client, i.e., the polling thread, to retrieve
and add events to the handler.
PR: https://github.com/apache/kafka/pull/12663
> Implement EventHandler interface and DefaultEventHandler
>
>
> Key: KAFKA-14247
> URL: https://issues.apache.org/jira/browse/KAFKA-14247
> Project: Kafka
> Issue Type: Sub-task
> Components: consumer
>Reporter: Philip Nee
>Assignee: Philip Nee
>Priority: Major
>
> The background thread runs inside of the DefaultEventHandler to consume
> events from the ApplicationEventQueue and produce events to the
> BackgroundEventQueue.
> The background thread runnable consist of a loop that tries to poll events
> from the ApplicationQueue, processes the event if there are any, and poll
> networkClient.
> In this implementation, the DefaultEventHandler spawns a thread that runs the
> BackgroundThreadRunnable. The runnable, as of the current PR, does the
> following things:
> # Initialize the networkClient
> # Poll ApplicationEvent from the queue if there's any
> # process the event
> # poll the networkClient
> PR: [https://github.com/apache/kafka/pull/12663]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (KAFKA-14247) Implement EventHandler interface and DefaultEventHandler
[
https://issues.apache.org/jira/browse/KAFKA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gustafson resolved KAFKA-14247.
-
Resolution: Fixed
> Implement EventHandler interface and DefaultEventHandler
>
>
> Key: KAFKA-14247
> URL: https://issues.apache.org/jira/browse/KAFKA-14247
> Project: Kafka
> Issue Type: Sub-task
> Components: consumer
>Reporter: Philip Nee
>Assignee: Philip Nee
>Priority: Major
>
> The polling thread uses events to communicate with the background thread.
> The events send to the background thread are the {_}Requests{_}, and the
> events send from the background thread to the polling thread are the
> {_}Responses{_}.
>
> Here we have an EventHandler interface and DefaultEventHandler
> implementation. The implementation uses two blocking queues to send events
> both ways. The two methods, add and poll allows the client, i.e., the
> polling thread, to retrieve and add events to the handler.
>
> PR: https://github.com/apache/kafka/pull/12663
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
