+1.
Build from source.  Tried all the IT with Security using Visibility CP and
ACL CP.  Looks good.
Tried out the shell commands with and without Security CPs.
All looks fine.

Regards
Ram


On Sat, Jul 19, 2014 at 7:35 AM, Anoop John <[email protected]> wrote:

> +1
>
> Built from src. Setup in a small cluster. Random shell commands. Tested the
> per cell security features.  Looks good.
>
> -Anoop-
>
> On Sat, Jul 19, 2014 at 2:39 AM, Andrew Purtell <[email protected]>
> wrote:
>
> > Changing my vote back to +1, sorry for that.
> >
> > Workload E tests on a new testbed instance with careful attention to
> > configuration do not produce the same results. We have instead:
> >
> > * ​Workload E* - 0.98.4RC0
> >
> >
> >
> >
> >
> > [OVERALL]RunTime(ms) 1270229[OVERALL]Throughput(ops/sec)
> > 7944[INSERT] Operations
> > 499175 [INSERT]AverageLatency(us)
> > 18[INSERT] MinLatency(us)
> > 5 [INSERT]MaxLatency(us)
> > 571160[INSERT]95thPercentileLatency(ms)
> > 0[INSERT] 99thPercentileLatency(ms)
> > 0 [SCAN]Operations
> > 9500825[SCAN] AverageLatency(us)
> > ​​
> >  ​​
> > 21089[SCAN] MinLatency(us)
> > 772 [SCAN]MaxLatency(us)
> > 3300020[SCAN]95thPercentileLatency(ms)
> > 107[SCAN] 99thPercentileLatency(ms)
> > 152
> >
> > I ran workload E a few times to insure the results were consistent. They
> > vary a bit due to natural variance but not by 23%.
> >
> > I don't have yesterday's test cluster around. I strongly suspect I made
> an
> > unseen error setting up for that workload.
> >
> >
> > On Thu, Jul 17, 2014 at 8:24 PM, Andrew Purtell <[email protected]>
> > wrote:
> >
> > > The difference observed on the remote testbed doesn't show up in
> > > all-localhost testing:
> > >
> > >  HEAD
> > >
> > > [SCAN], Operations, 949967
> > > [SCAN], AverageLatency(us), 23847.456127423375
> > > [SCAN], MinLatency(us), 625
> > > [SCAN], MaxLatency(us), 1806981
> > > [SCAN], 95thPercentileLatency(ms), 56
> > > [SCAN], 99thPercentileLatency(ms), 71
> > >
> > >
> > > HEAD~50: 5f853cb... HBASE-11436
> > >
> > > [SCAN], Operations, 949937
> > > [SCAN], AverageLatency(us), 23844.437741660764
> > > [SCAN], MinLatency(us), 961
> > > [SCAN], MaxLatency(us), 1843125
> > > [SCAN], 95thPercentileLatency(ms), 55
> > > [SCAN], 99thPercentileLatency(ms), 70
> > >
> > >
> > > 0ca0ced Update CHANGES.txt for 0.98.3RC1
> > >
> > > [SCAN], Operations, 950224
> > > [SCAN], AverageLatency(us), 24303.889086152318
> > > [SCAN], MinLatency(us), 956
> > > [SCAN], MaxLatency(us), 2091141
> > > [SCAN], 95thPercentileLatency(ms), 56
> > > [SCAN], 99thPercentileLatency(ms), 71
> > >
> > >
> > > I have the testbed for one more day. I'll try an educated guess.
> > > Otherwise, will need to change my vote back to +1 because I can't veto
> a
> > RC
> > > for something I can't verify.
> > >
> > >
> > >
> > > On Thu, Jul 17, 2014 at 5:51 PM, Andrew Purtell <[email protected]>
> > > wrote:
> > >
> > >> Bisecting now.
> > >>
> > >> I plan to find and revert the culprit and any related commits, confirm
> > >> improvement with workload E, push those changes back onto the pile for
> > .5,
> > >> and roll .4 RC1 on or before Monday. Phoenix has a release deadline at
> > the
> > >> end of the month and changes in .4 they need (if not the issue).
> > >>
> > >>
> > >> On Thu, Jul 17, 2014 at 5:12 PM, Andrew Purtell <[email protected]>
> > >> wrote:
> > >>
> > >>> See thread on dev@ titled "Comparing the performance of 0.98.4 RC0
> and
> > >>> 0.98.0 using YCSB - 23% perf regression in workload E"
> > >>>
> > >>> -1 on this RC for now, pending reproduction and further analysis on a
> > >>> dev box.
> > >>>
> > >>> [...]
> > >>>
> > >>> These tests were run with no security coprocessors installed, using
> > >>> HFile V2. The workload E results are a concern. *It appears we have a
> > >>> 23% decline in measured scan throughput and an 23% increase in
> average
> > op
> > >>> time from 27 ms to 35 ms. *This does not correspond to any active
> > >>> security feature (though that could worsen results potentially,
> > untested)
> > >>> so is something changed in core code. Other workloads are not
> affected
> > so
> > >>> this is something specific to scanning. Perhaps delete tracking.
> > >>>
> > >>> [...]
> > >>>
> > >>> *Workload E*
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> [OVERALL] RunTime(ms)16009102078826 [OVERALL]Throughput(ops/sec) 6308
> > >>> 4835[INSERT] Operations499131500322 [INSERT]AverageLatency(us) 1417
> >  >>> [INSERT] MinLatency(us)55 [INSERT]MaxLatency(us)
> 506079564468[INSERT]
> > >>> 95thPercentileLatency(ms)0 0[INSERT]99thPercentileLatency(ms) 00
> [SCAN]
> > >>> Operations9500869 9499678[SCAN] AverageLatency(us)
> > >>> ​​
> > >>>  ​​
> > >>> 2663634620 [SCAN]MinLatency(us) 746755[SCAN] MaxLatency(us)8067864
> > >>> 4615914[SCAN]95thPercentileLatency(ms) 117136 [SCAN]
> > >>> 99thPercentileLatency(ms)169 187
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Jul 14, 2014 at 8:38 PM, Andrew Purtell <[email protected]
> >
> > >>> wrote:
> > >>>
> > >>>> The 1st HBase 0.98.4 release candidate (RC0) is available for
> download
> > >>>> at http://people.apache.org/~apurtell/0.98.4RC0/ and Maven
> artifacts
> > >>>> are also available in the temporary repository
> > >>>>
> > https://repository.apache.org/content/repositories/orgapachehbase-1026/
> > >>>>
> > >>>> Signed with my code signing key D5365CCD.
> > >>>>
> > >>>> The issues resolved in this release can be found here:
> > >>>>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12326810
> > >>>>
> > >>>>
> > >>>> Please try out the candidate and vote +1/-1 by midnight Pacific Time
> > >>>> (00:00 -0800 GMT) on July 21 on whether or not we should release
> this
> > as
> > >>>> 0.98.4. Three +1 votes from PMC will be required to release.
> > >>>>
> > >>>>
> > >>
> > >>
> > >> --
> > >> 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)
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>

Reply via email to