I have explained why this patch is very different than a new HFile + Tags, but I'm more than willing to re-iterate those reasons.
* It's at least an order of magnitude smaller than HFile v3. * It's not a new feature. * It's a minor tweak on one that's already there * It's much less risky. * It's in a production ready state now. * It's already got a plus one. * It's been running on integration test clusters for a while (as witnessed by it being used to find actual bugs in 0.95). * This change can't be done on a later date since it changes HTrace's public api that users of HBase would be calling. On Tue, Aug 13, 2013 at 5:40 PM, Andrew Purtell <apurt...@apache.org> wrote: > Elliott, > > It would be good if you could address the specific points that I have > called out. I want to be sure that at least our decision making is > consistent and without the appearance of a double standard. > > > On Tue, Aug 13, 2013 at 5:24 PM, Elliott Clark <ecl...@apache.org> wrote: > >> Any thoughts on HBASE-9121. At it's heart it's just a version bump of >> HTrace to 2.0 (fully released into maven central and available on >> Cloudera's github). The new version of htrace is modularized so that >> hbase-client doesn't drag in any new dependencies on the client side. >> >> Along with that modularization we would get the ability for 0.95/0.96 >> to relay to Zipkin producing some pretty useful info for stabilizing >> the release(tracing is what found that scan pre-fetching was broken) >> and very useful for our users. >> >> For me I think that it's small enough that it would meet a higher bar >> to get things into 0.95. But since there were some thoughts on here >> I've held off on comitting. >> >> On Mon, Aug 5, 2013 at 10:01 AM, Andrew Purtell <apurt...@apache.org> >> wrote: >> > Clarification would be great. I read Elliot's veto of our work as based >> on >> > both process and maturity concerns. Let's see how they stack up. >> > >> >> HFileV3: >> >> * Showed up very late in the merge window >> > >> > Same >> > >> >> * Still needs revisions >> > >> > Has not even been reviewed yet. Depends on code only existing in a >> > developer's private GitHub. >> > >> >> * Hasn't been put on large clusters publicly. >> > >> > Same >> > >> >> * Is not the green field HFileV3, and doesn't have time for a complete >> > re-do >> > >> > Not applicable >> > >> >> * Can easily be done without out downtime >> > >> > Same >> > >> >> * Will 100% have perf impacts. >> > >> > See my other comment about perf impacts if V3 is used without tags. >> > >> > >> > I have no objection to the trace work on technical grounds. >> > >> > >> > On Mon, Aug 5, 2013 at 8:31 AM, Stack <st...@duboce.net> wrote: >> > >> >> On Sat, Aug 3, 2013 at 3:10 PM, Andrew Purtell <apurt...@apache.org> >> >> wrote: >> >> >> >> > JIRA says that was created August 3, ie today, is that right? >> >> > >> >> > >> >> Yes. >> >> >> >> (Elliott can clarify later when he gets in) My understanding is that >> it is >> >> an update to our bundled htrace jar -- pushing a new release -- and >> adding >> >> some trace extra trace spans to expose where time is being spent during >> >> MTTR. >> >> >> >> St.Ack >> >> >> > >> > >> > >> > -- >> > Best regards, >> > >> > - Andy >> > >> > Problems worthy of attack prove their worth by hitting back. - Piet Hein >> > (via Tom White) >> > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White)
