You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@inlong.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2021/07/28 11:55:01 UTC

[jira] [Updated] (INLONG-585) Optimize the implementation of RmtDataCache class

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

ASF GitHub Bot updated INLONG-585:
----------------------------------
    Labels: pull-request-available  (was: )

> Optimize the implementation of RmtDataCache class
> -------------------------------------------------
>
>                 Key: INLONG-585
>                 URL: https://issues.apache.org/jira/browse/INLONG-585
>             Project: Apache InLong
>          Issue Type: Improvement
>          Components: inlong-tubemq
>            Reporter: Guocheng Zhang
>            Priority: Normal
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> This class is used by the consumer to cache and manage metadata: the heartbeat from the client to the Master will update the cached metadata; the consumption request and response will query the metadata, and clean up the abnormal partition when it is abnormal. It belongs to the type to read more and write less, need to control concurrent access.
>  
> The implementation of it is not very good personally: it uses too many ConcurrentHashMap structures. If the implementation is optimized and adjusted while keeping the functions unchanged, the readability and operating efficiency of this part should be better.
>  
> The difficulty of this part is average, if someone has a better approach, welcome to put forward your ideas and communicate and improve it together.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)