hi @Deepan_N    by running the command below directly in python3:   r0.headers["www-authenticate"]   returns the following error:   Python 3.6.8 (default, Nov 16 2020, 16:55:22) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> r0.headers["www-authenticate"] Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'r0' is not defined >>> below is the screenshot of the commands executed in bash:   ... View more

@yagoaparecidoti    A] Generally /config/topics/ will store all topic level configuration if you have set any.   For example: If you have set any topic level setting then it will be stored there:   [zk: node1.zookeeper-hostname.com:2181(CONNECTED) 6] get /kafka/config/topics/ATLAS_HOOK {"version":1,"config":{"retention.ms":"2678400000","cleanup.policy":"compact"}} [zk:node1.zookeeper-hostname.com:2181(CONNECTED) 7]   Here topic level settings are retention.ms and cleanup.policy=compact   As it has only topic-level configuration details it will not affect the Kafka cluster or applications if applications are not dependent on any topic-level settings.    B] There is no standard Kafka tool which you can use to restore /config/topics but you can easily alter/set topic level settings using the Kafka command below as per your retirement if any.    kafka-configs --zookeeper <ZK_host>:2181/kafka --entity-type topics --entity-name <topic_name> --alter --add-config <configname & value>   Note: Replace all required settings and /kafka (/kafka can be checked from CM >> Kafka >> Conf >> zookeeper.chroot) in the above command   If you found this response assisted with your query, please take a moment to log in and click on  KUDOS 🙂 & ”Accept as Solution" below this post. ... View more

@yagoaparecidoti Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks ... View more

@yagoaparecidoti Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks ... View more

@yagoaparecidoti If you notice that the high memory utilization moves from tablet server to tablet server, then another candidate is a problem with the schema of one or more tables. The specific symptom I am thinking of is that the tablet size may be too high due to too few partitions; this can drive high memory utilization because the of the amount of information that must be loaded into memory. The fast way to determine whether this is the case is to look at the Charts for the Tablet Server with high memory utilization, and check the size of data across all tablets on that server. Then, divide this number by the number of replicas on the server, and this gives us an avg value of the replica size. It is perfectly possible for this problem to originate with a single table, so if you have one or more tables you know have few partitions, I recommend checking that table specifically.   Beyond this will require log analysis, and is better suited to a support case. ... View more

@yagoaparecidoti Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks! ... View more

hi @ChethanYM    unfortunately we need to do this type of blocking only in IMPALA, in HIVE it has to work normally.   when blocking by sentry, it will be replicated for any type of access that the user will use, such as hive, impala, beeline, etc. ... View more

hi@ChethanYM    Thank you for the link.   another question that popped up:   we didn't find anything saying if the coordinators can be used in virtual machines, can you tell us if there is a problem? ... View more