You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Guozhang Wang (JIRA)" <ji...@apache.org> on 2017/05/16 16:59:04 UTC

[jira] [Resolved] (KAFKA-5151) Refactor TransactionCoordinator in-memory structure and error handling logic

     [ https://issues.apache.org/jira/browse/KAFKA-5151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guozhang Wang resolved KAFKA-5151.
----------------------------------
       Resolution: Fixed
    Fix Version/s: 0.11.0.0

> Refactor TransactionCoordinator in-memory structure and error handling logic
> ----------------------------------------------------------------------------
>
>                 Key: KAFKA-5151
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5151
>             Project: Kafka
>          Issue Type: Sub-task
>          Components: core
>            Reporter: Guozhang Wang
>            Assignee: Guozhang Wang
>             Fix For: 0.11.0.0
>
>
> Current status:
> 1. we are having two types of threads: request handling thread for any client requests as well as controller requests for `immigration` and `emigration`, and the marker sender thread for draining queued marker entries and handle responses. They maintain different in-memory cache structures like the `txnMetadataCache`, and the `pendingTxnMap` which are storing the same info, and they access some of the shared structures concurrently, like the markers queue and the markerPurgatory.
> 2. we are having one queue per broker today, and due to the emigration purpose we probably are having one queue per brokerId + TxnLogPartitionId + DataPartitionId, which would result in a lot of queues to handle.
> This ticket is for collapsing some of these structures and simplify the access of them from concurrent threads.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)