[ 
https://issues.apache.org/jira/browse/HIVE-26984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683356#comment-17683356
 ] 

Zoltan Haindrich commented on HIVE-26984:
-----------------------------------------

I understand that you are after the ultimate comfort...but how often you would 
need this? you are saying that you want a system built-in which could tell you 
from "WHERE"  conf keys are being altered...if that happens often - I would be 
interested in the causes of that...

but I think you still have alternatives;  you could probably:
* enable aspectj weaving for the hive-exec module - since we are already 
shading the modul; that's not that big of a change....especially if it could 
shade+weave at the same time..
* you could build-in the Traceable part into the main HiveConf object - right 
now you are returning a different impl if a conf key is set..
** since this is a conf object - the state of that conf key is a chicken-egg 
problem: what if for some HiveConf instances you are loading from a different 
place/etc? and the key is off? you will not see those - but I guess those would 
be the most interesting ones...when someone just wrote `new HiveConf()`...
* as about passing&launching the agent: I'm not sure - but maybe the agent can 
be placed inside say hive-exec or something; and then tweak the tez launch 
params (from inside HS2) to add the -agent to the launch cmdline.... ; probably 
similar for the HS2 startup...but that should be done somewhere in the 
scripts...
** so I don't see that way impossible either...have you already explored these 
paths?

> Deprecate public HiveConf constructors
> --------------------------------------
>
>                 Key: HIVE-26984
>                 URL: https://issues.apache.org/jira/browse/HIVE-26984
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: László Bodor
>            Assignee: László Bodor
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> From time to time we investigate configuration object problems that are hard 
> to investigate. We can improve this area, e.g. with HIVE-26985, but first, we 
> need to introduce a public static factory method to hook into the creation 
> process. I can see this pattern in another projects as well, like: 
> HBaseConfiguration.
> Creating custom HiveConf subclasses can be useful because putting optional 
> (say: if else branches or whatever) stuff into the original HiveConf object's 
> hot codepaths can turn it less performant instantly.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to