Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining issues


Copy link to this message
-
Re: [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining issues
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]> wrote:
>> >
>> >> On Sat, Aug 3, 2013 at 3:10 PM, Andrew Purtell <[EMAIL PROTECTED]>
>> >> 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)