[ https://issues.apache.org/jira/browse/HADOOP-15566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807619#comment-16807619 ]
Elek, Marton edited comment on HADOOP-15566 at 4/2/19 10:16 AM: ---------------------------------------------------------------- Thanks the questions [~bogdandrutu], sorry I missed this comment earlier. bq. What implementation will be shipped with the official HBase binary? I don't know it depends from the HBase imho. With using OT we can use multiple implementation, HBase can provide any implementation. bq. How can somebody use a different implementation? It should be configurable. AFAIK the only vendor specific part is the initialization code. It's easy to create an interface to initialize different implementation (eg. a class name which should be called to initialize the implementation. bq. How do you ensure that a different implementation (that is not tested with your entire test suite) may not corrupt user data? I think it is very important that all the tests are running with the implementation that user uses in production. I don't think that we need to test all the implementation. We should prove that the OT api used well and use one implementation as an example. And we clearly write the documentation what is tested and what is not. Not tested implementations which are provided by other vendors can be used but should be tested before by the users. bq. use one implementation (pick something that you like the most) and export these data to an configurable endpoint Interesting. Can you please give me more details? What is the configurable endpoint? How the tracing information would be stored? was (Author: elek): Thanks the questions [~bogdandrutu] q. What implementation will be shipped with the official HBase binary? I don't know it depends from the HBase imho. With using OT we can use multiple implementation, HBase can provide any implementation. q. How can somebody use a different implementation? It should be configurable. AFAIK the only vendor specific part is the initialization code. It's easy to create an interface to initialize different implementation (eg. a class name which should be called to initialize the implementation. q. How do you ensure that a different implementation (that is not tested with your entire test suite) may not corrupt user data? I think it is very important that all the tests are running with the implementation that user uses in production. I don't think that we need to test all the implementation. We should prove that the OT api used well and use one implementation as an example. And we clearly write the documentation what is tested and what is not. Not tested implementations which are provided by other vendors can be used but should be tested before by the users. q. use one implementation (pick something that you like the most) and export these data to an configurable endpoint Interesting. Can you please give me more details? What is the configurable endpoint? How the tracing information would be stored? > Remove HTrace support > --------------------- > > Key: HADOOP-15566 > URL: https://issues.apache.org/jira/browse/HADOOP-15566 > Project: Hadoop Common > Issue Type: Improvement > Components: metrics > Affects Versions: 3.1.0 > Reporter: Todd Lipcon > Priority: Major > Labels: security > Attachments: Screen Shot 2018-06-29 at 11.59.16 AM.png, > ss-trace-s3a.png > > > The HTrace incubator project has voted to retire itself and won't be making > further releases. The Hadoop project currently has various hooks with HTrace. > It seems in some cases (eg HDFS-13702) these hooks have had measurable > performance overhead. Given these two factors, I think we should consider > removing the HTrace integration. If there is someone willing to do the work, > replacing it with OpenTracing might be a better choice since there is an > active community. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org