Quick updates: W/ patch of HBASE-22219 or say upgrading kerby version to 1.0.1, the failures listed above in the 1st part of hbase-server disappeared.
However, in the 2nd part of hbase-server UT there're still many ConnectionRefused exceptions (17 errors in total) as shown below, which could be reproduced easily with -Dtest=xxx command on my environments, still checking the root cause. [INFO] Running org.apache.hadoop.hbase.regionserver.TestBlocksRead [ERROR] Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.853 s <<< FAILURE! - in org.apache.hadoop.hbase.regionserver.TestBlocksRead [ERROR] testBlocksStoredWhenCachingDisabled(org.apache.hadoop.hbase.regionserver.TestBlocksRead) Time elapsed: 0.17 s <<< ERROR! java.net.ConnectException: Call From z05f06378.sqa.zth.tbsite.net/11.163.183.195 to localhost:35669 failed on connection exception: java.net.ConnectException: Connection refused; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused at org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112) at org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389) Caused by: java.net.ConnectException: Connection refused at org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112) at org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389) Best Regards, Yu On Fri, 12 Apr 2019 at 13:11, Yu Li <car...@gmail.com> wrote: > I have no doubt that you've run the tests locally before announcing a > release as you're always a great RM boss. And this shows one value of > verifying release, that different voter has different environments. > > Now I think the failures may be kerberos related, since I possibly has > changed some system configuration when doing Flink testing on this env > weeks ago. Located one issue (HBASE-22219) which also observed in 1.4.7, > will further investigate. > > Best Regards, > Yu > > > On Fri, 12 Apr 2019 at 12:38, Andrew Purtell <andrew.purt...@gmail.com> > wrote: > >> “However it's good to find the issue earlier if there >> really is any, before release announced.” >> >> I run the complete unit test suite before announcing a release candidate. >> Just to be clear. >> >> Totally agree we should get these problems sorted before an actual >> release. My policy is to cancel a RC if anyone vetoes for this reason... >> want as much coverage and varying environments as we can manage. >> >> Thank you for your help so far and I hope the failures you see result in >> analysis and fixes that lead to better test stability. >> >> > On Apr 11, 2019, at 9:32 PM, Yu Li <car...@gmail.com> wrote: >> > >> > Confirmed in 1.4.7 source the listed out cases passed (all in the 1st >> part >> > of hbase-server so the result comes out quickly.)... Also confirmed the >> > test ran order are the same... >> > >> > Will try 1.5.0 again to prevent the environment difference caused by >> time. >> > If 1.5.0 still fails, will start to do the git bisect to locate the >> first >> > bad commit. >> > >> > Was also expecting an easy pass and +1 as always to save time and >> efforts, >> > but obvious no luck. However it's good to find the issue earlier if >> there >> > really is any, before release announced. >> > >> > Best Regards, >> > Yu >> > >> > >> >> On Fri, 12 Apr 2019 at 12:16, Yu Li <car...@gmail.com> wrote: >> >> >> >> Fine, let's focus on verifying whether it's a real problem rather than >> >> arguing about wording, after all that's not my intention... >> >> >> >> As mentioned, I participated in the 1.4.7 release vote[1] and IIRC I >> was >> >> using the same env and all tests passed w/o issue, that's where my >> concern >> >> lies and the main reason I gave a -1 vote. I'm running against 1.4.7 >> source >> >> on the same now and let's see the result. >> >> >> >> [1] https://www.mail-archive.com/dev@hbase.apache.org/msg51380.html >> >> >> >> Best Regards, >> >> Yu >> >> >> >> >> >> On Fri, 12 Apr 2019 at 12:05, Andrew Purtell <andrew.purt...@gmail.com >> > >> >> wrote: >> >> >> >>> I believe the test execution order matters. We run some tests in >> >>> parallel. The ordering of tests is determined by readdir() results >> and this >> >>> differs from host to host and checkout to checkout. So when you see a >> >>> repeatable group of failures, that’s great. And when someone else >> doesn’t >> >>> see those same tests fail, or they cannot be reproduced when running >> by >> >>> themselves, the commonly accepted term of art for this is “flaky”. >> >>> >> >>> >> >>>> On Apr 11, 2019, at 8:52 PM, Yu Li <car...@gmail.com> wrote: >> >>>> >> >>>> Sorry but I'd call it "possible environment related problem" or "some >> >>>> feature may not work well in specific environment", rather than a >> flaky. >> >>>> >> >>>> Will check against 1.4.7 released source package before opening any >> >>> JIRA. >> >>>> >> >>>> Best Regards, >> >>>> Yu >> >>>> >> >>>> >> >>>> On Fri, 12 Apr 2019 at 11:37, Andrew Purtell < >> andrew.purt...@gmail.com> >> >>>> wrote: >> >>>> >> >>>>> And if they pass in my environment , then what should we call it >> then. >> >>> I >> >>>>> have no doubt you are seeing failures. Therefore can you please file >> >>> JIRAs >> >>>>> and attach information that can help identify a fix. Thanks. >> >>>>> >> >>>>>> On Apr 11, 2019, at 8:35 PM, Yu Li <car...@gmail.com> wrote: >> >>>>>> >> >>>>>> I ran the test suite with the -Dsurefire.rerunFailingTestsCount=2 >> >>> option >> >>>>>> and on two different env separately, so it sums up to 6 times >> stable >> >>>>>> failure for each case, and from my perspective this is not flaky. >> >>>>>> >> >>>>>> IIRC last time when verifying 1.4.7 on the same env no such issue >> >>>>> observed, >> >>>>>> will double check. >> >>>>>> >> >>>>>> Best Regards, >> >>>>>> Yu >> >>>>>> >> >>>>>> >> >>>>>> On Fri, 12 Apr 2019 at 00:07, Andrew Purtell < >> >>> andrew.purt...@gmail.com> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> There are two failure cases it looks like. And this looks like >> >>> flakes. >> >>>>>>> >> >>>>>>> The wrong FS assertions are not something I see when I run these >> >>> tests >> >>>>>>> myself. I am not able to investigate something I can’t reproduce. >> >>> What I >> >>>>>>> suggest is since you can reproduce do a git bisect to find the >> commit >> >>>>> that >> >>>>>>> introduced the problem. Then we can revert it. As an alternative >> we >> >>> can >> >>>>>>> open a JIRA, report the problem, temporarily @ignore the test, and >> >>>>>>> continue. This latter option only should be done if we are fairly >> >>>>> confident >> >>>>>>> it is a test only problem. >> >>>>>>> >> >>>>>>> The connect exceptions are interesting. I see these sometimes when >> >>> the >> >>>>>>> suite is executed, not this particular case, but when the failed >> >>> test is >> >>>>>>> executed by itself it always passes. It is possible some change to >> >>>>> classes >> >>>>>>> related to the minicluster or startup or shutdown timing are the >> >>> cause, >> >>>>> but >> >>>>>>> it is test time flaky behavior. I’m not happy about this but it >> >>> doesn’t >> >>>>>>> actually fail the release because the failure is never repeatable >> >>> when >> >>>>> the >> >>>>>>> test is run standalone. >> >>>>>>> >> >>>>>>> In general it would be great if some attention was paid to test >> >>>>>>> cleanliness on branch-1. As RM I’m not in a position to insist >> that >> >>>>>>> everything is perfect or there will never be another 1.x release, >> >>>>> certainly >> >>>>>>> not from branch-1. So, tests which fail repeatedly block a release >> >>> IMHO >> >>>>> but >> >>>>>>> flakes do not. >> >>>>>>> >> >>>>>>> >> >>>>>>>> On Apr 10, 2019, at 11:20 PM, Yu Li <car...@gmail.com> wrote: >> >>>>>>>> >> >>>>>>>> -1 >> >>>>>>>> >> >>>>>>>> Observed many UT failures when checking the source package (tried >> >>>>>>> multiple >> >>>>>>>> rounds on two different environments, MacOs and Linux, got the >> same >> >>>>>>>> result), including (but not limited to): >> >>>>>>>> >> >>>>>>>> TestBulkload: >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> shouldBulkLoadSingleFamilyHLog(org.apache.hadoop.hbase.regionserver.TestBulkLoad) >> >>>>>>>> Time elapsed: 0.083 s <<< ERROR! >> >>>>>>>> java.lang.IllegalArgumentException: Wrong FS: >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> file:/var/folders/t6/vch4nh357f98y1wlq09lbm7h0000gn/T/junit1805329913454564189/junit8020757893576011944/data/default/shouldBulkLoadSingleFamilyHLog/8f4a6b584533de2fd1bf3c398dfaac29, >> >>>>>>>> expected: hdfs://localhost:55938 >> >>>>>>>> at >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> org.apache.hadoop.hbase.regionserver.TestBulkLoad.testRegionWithFamiliesAndSpecifiedTableName(TestBulkLoad.java:246) >> >>>>>>>> at >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> org.apache.hadoop.hbase.regionserver.TestBulkLoad.testRegionWithFamilies(TestBulkLoad.java:256) >> >>>>>>>> at >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> org.apache.hadoop.hbase.regionserver.TestBulkLoad.shouldBulkLoadSingleFamilyHLog(TestBulkLoad.java:150) >> >>>>>>>> >> >>>>>>>> TestStoreFile: >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> testCacheOnWriteEvictOnClose(org.apache.hadoop.hbase.regionserver.TestStoreFile) >> >>>>>>>> Time elapsed: 0.083 s <<< ERROR! >> >>>>>>>> java.net.ConnectException: Call From localhost/127.0.0.1 to >> >>>>>>> localhost:55938 >> >>>>>>>> failed on connection exception: java.net.ConnectException: >> >>> Connection >> >>>>>>>> refused; For more details see: >> >>>>>>>> http://wiki.apache.org/hadoop/ConnectionRefused >> >>>>>>>> at >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> org.apache.hadoop.hbase.regionserver.TestStoreFile.writeStoreFile(TestStoreFile.java:1047) >> >>>>>>>> at >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> org.apache.hadoop.hbase.regionserver.TestStoreFile.testCacheOnWriteEvictOnClose(TestStoreFile.java:908) >> >>>>>>>> >> >>>>>>>> TestHFile: >> >>>>>>>> testEmptyHFile(org.apache.hadoop.hbase.io.hfile.TestHFile) Time >> >>>>> elapsed: >> >>>>>>>> 0.08 s <<< ERROR! >> >>>>>>>> java.net.ConnectException: Call From >> >>>>>>>> z05f06378.sqa.zth.tbsite.net/11.163.183.195 to localhost:35529 >> >>> failed >> >>>>> on >> >>>>>>>> connection exception: java.net.ConnectException: Connection >> refused; >> >>>>> For >> >>>>>>>> more details see: >> http://wiki.apache.org/hadoop/ConnectionRefused >> >>>>>>>> at >> >>>>>>>> org.apache.hadoop.hbase.io >> >>>>>>> .hfile.TestHFile.testEmptyHFile(TestHFile.java:90) >> >>>>>>>> Caused by: java.net.ConnectException: Connection refused >> >>>>>>>> at >> >>>>>>>> org.apache.hadoop.hbase.io >> >>>>>>> .hfile.TestHFile.testEmptyHFile(TestHFile.java:90) >> >>>>>>>> >> >>>>>>>> TestBlocksScanned: >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> testBlocksScannedWithEncoding(org.apache.hadoop.hbase.regionserver.TestBlocksScanned) >> >>>>>>>> Time elapsed: 0.069 s <<< ERROR! >> >>>>>>>> java.lang.IllegalArgumentException: Wrong FS: >> >>>>> hdfs://localhost:35529/tmp/ >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> hbase-jueding.ly/hbase/data/default/TestBlocksScannedWithEncoding/a4a416cc3060d9820a621c294af0aa08 >> >>>>>>> , >> >>>>>>>> expected: file:/// >> >>>>>>>> at >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> org.apache.hadoop.hbase.regionserver.TestBlocksScanned._testBlocksScanned(TestBlocksScanned.java:90) >> >>>>>>>> at >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> org.apache.hadoop.hbase.regionserver.TestBlocksScanned.testBlocksScannedWithEncoding(TestBlocksScanned.java:86) >> >>>>>>>> >> >>>>>>>> And please let me know if any known issue I'm not aware of. >> Thanks. >> >>>>>>>> >> >>>>>>>> Best Regards, >> >>>>>>>> Yu >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> On Mon, 8 Apr 2019 at 11:38, Yu Li <car...@gmail.com> wrote: >> >>>>>>>>> >> >>>>>>>>> The performance report LGTM, thanks! (and sorry for the lag due >> to >> >>>>>>>>> Qingming Festival Holiday here in China) >> >>>>>>>>> >> >>>>>>>>> Still verifying the release, just some quick feedback: observed >> >>> some >> >>>>>>>>> incompatible changes in compatibility report including >> >>>>>>>>> HBASE-21492/HBASE-21684 and worth a reminder in ReleaseNote. >> >>>>>>>>> >> >>>>>>>>> Irrelative but noticeable: the 1.4.9 release note URL is >> invalid on >> >>>>>>>>> https://hbase.apache.org/downloads.html >> >>>>>>>>> >> >>>>>>>>> Best Regards, >> >>>>>>>>> Yu >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>> On Fri, 5 Apr 2019 at 08:45, Andrew Purtell < >> apurt...@apache.org> >> >>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> The difference is basically noise per the usual YCSB >> evaluation. >> >>>>> Small >> >>>>>>>>>> differences in workloads D and F (slightly worse) and workload >> E >> >>>>>>> (slightly >> >>>>>>>>>> better) that do not indicate serious regression. >> >>>>>>>>>> >> >>>>>>>>>> Linux version 4.14.55-62.37.amzn1.x86_64 >> >>>>>>>>>> c3.8xlarge x 5 >> >>>>>>>>>> OpenJDK Runtime Environment (build 1.8.0_181-shenandoah-b13) >> >>>>>>>>>> -Xms20g -Xmx20g -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+UseNUMA >> >>>>>>>>>> -XX:-UseBiasedLocking -XX:+ParallelRefProcEnabled >> >>>>>>>>>> Hadoop 2.9.2 >> >>>>>>>>>> Init: Load 100 M rows and snapshot >> >>>>>>>>>> Run: Delete table, clone and redeploy from snapshot, run 10 M >> >>>>>>> operations >> >>>>>>>>>> Args: -threads 100 -target 50000 >> >>>>>>>>>> Test table: {NAME => 'u', BLOOMFILTER => 'ROW', VERSIONS => >> '1', >> >>>>>>> IN_MEMORY >> >>>>>>>>>> => 'false', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING >> => >> >>>>>>>>>> 'ROW_INDEX_V1', TTL => 'FOREVER', COMPRESSION => 'SNAPPY', >> >>>>>>> MIN_VERSIONS => >> >>>>>>>>>> '0', BLOCKCACHE => 'true', BLOCKSIZE => '65536', >> >>> REPLICATION_SCOPE => >> >>>>>>>>>> '0'} >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> YCSB Workload A >> >>>>>>>>>> >> >>>>>>>>>> target 50k/op/s 1.4.9 1.5.0 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> [OVERALL], RunTime(ms) 200592 200583 >> >>>>>>>>>> [OVERALL], Throughput(ops/sec) 49852 49855 >> >>>>>>>>>> [READ], AverageLatency(us) 544 559 >> >>>>>>>>>> [READ], MinLatency(us) 267 292 >> >>>>>>>>>> [READ], MaxLatency(us) 165631 185087 >> >>>>>>>>>> [READ], 95thPercentileLatency(us) 738 742 >> >>>>>>>>>> [READ], 99thPercentileLatency(us), 1877 1961 >> >>>>>>>>>> [UPDATE], AverageLatency(us) 1370 1181 >> >>>>>>>>>> [UPDATE], MinLatency(us) 702 646 >> >>>>>>>>>> [UPDATE], MaxLatency(us) 180735 177279 >> >>>>>>>>>> [UPDATE], 95thPercentileLatency(us) 1943 1652 >> >>>>>>>>>> [UPDATE], 99thPercentileLatency(us) 3257 3085 >> >>>>>>>>>> >> >>>>>>>>>> YCSB Workload B >> >>>>>>>>>> >> >>>>>>>>>> target 50k/op/s 1.4.9 1.5.0 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> [OVERALL], RunTime(ms) 200599 200581 >> >>>>>>>>>> [OVERALL], Throughput(ops/sec) 49850 49855 >> >>>>>>>>>> [READ], AverageLatency(us), 454 471 >> >>>>>>>>>> [READ], MinLatency(us) 203 213 >> >>>>>>>>>> [READ], MaxLatency(us) 183423 174207 >> >>>>>>>>>> [READ], 95thPercentileLatency(us) 563 599 >> >>>>>>>>>> [READ], 99thPercentileLatency(us) 1360 1172 >> >>>>>>>>>> [UPDATE], AverageLatency(us) 1064 1029 >> >>>>>>>>>> [UPDATE], MinLatency(us) 746 726 >> >>>>>>>>>> [UPDATE], MaxLatency(us) 163455 101631 >> >>>>>>>>>> [UPDATE], 95thPercentileLatency(us) 1327 1157 >> >>>>>>>>>> [UPDATE], 99thPercentileLatency(us) 2241 1898 >> >>>>>>>>>> >> >>>>>>>>>> YCSB Workload C >> >>>>>>>>>> >> >>>>>>>>>> target 50k/op/s 1.4.9 1.5.0 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> [OVERALL], RunTime(ms) 200541 200538 >> >>>>>>>>>> [OVERALL], Throughput(ops/sec) 49865 49865 >> >>>>>>>>>> [READ], AverageLatency(us) 332 327 >> >>>>>>>>>> [READ], MinLatency(us) 175 179 >> >>>>>>>>>> [READ], MaxLatency(us) 210559 170367 >> >>>>>>>>>> [READ], 95thPercentileLatency(us) 410 396 >> >>>>>>>>>> [READ], 99thPercentileLatency(us) 871 892 >> >>>>>>>>>> >> >>>>>>>>>> YCSB Workload D >> >>>>>>>>>> >> >>>>>>>>>> target 50k/op/s 1.4.9 1.5.0 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> [OVERALL], RunTime(ms) 200579 200562 >> >>>>>>>>>> [OVERALL], Throughput(ops/sec) 49855 49859 >> >>>>>>>>>> [READ], AverageLatency(us) 487 547 >> >>>>>>>>>> [READ], MinLatency(us) 210 214 >> >>>>>>>>>> [READ], MaxLatency(us) 192255 177535 >> >>>>>>>>>> [READ], 95thPercentileLatency(us) 973 1529 >> >>>>>>>>>> [READ], 99thPercentileLatency(us) 1836 2683 >> >>>>>>>>>> [INSERT], AverageLatency(us) 1239 1152 >> >>>>>>>>>> [INSERT], MinLatency(us) 807 788 >> >>>>>>>>>> [INSERT], MaxLatency(us) 184575 148735 >> >>>>>>>>>> [INSERT], 95thPercentileLatency(us) 1496 1243 >> >>>>>>>>>> [INSERT], 99thPercentileLatency(us) 2965 2495 >> >>>>>>>>>> >> >>>>>>>>>> YCSB Workload E >> >>>>>>>>>> >> >>>>>>>>>> target 10k/op/s 1.4.9 1.5.0 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> [OVERALL], RunTime(ms) 100605 100568 >> >>>>>>>>>> [OVERALL], Throughput(ops/sec) 9939 9943 >> >>>>>>>>>> [SCAN], AverageLatency(us) 3548 2687 >> >>>>>>>>>> [SCAN], MinLatency(us) 696 678 >> >>>>>>>>>> [SCAN], MaxLatency(us) 1059839 238463 >> >>>>>>>>>> [SCAN], 95thPercentileLatency(us) 8327 6791 >> >>>>>>>>>> [SCAN], 99thPercentileLatency(us) 17647 14415 >> >>>>>>>>>> [INSERT], AverageLatency(us) 2688 1555 >> >>>>>>>>>> [INSERT], MinLatency(us) 887 815 >> >>>>>>>>>> [INSERT], MaxLatency(us) 173311 154623 >> >>>>>>>>>> [INSERT], 95thPercentileLatency(us) 4455 2571 >> >>>>>>>>>> [INSERT], 99thPercentileLatency(us) 9303 5375 >> >>>>>>>>>> >> >>>>>>>>>> YCSB Workload F >> >>>>>>>>>> >> >>>>>>>>>> target 50k/op/s 1.4.9 1.5.0 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> [OVERALL], RunTime(ms) 200562 204178 >> >>>>>>>>>> [OVERALL], Throughput(ops/sec) 49859 48976 >> >>>>>>>>>> [READ], AverageLatency(us) 856 1137 >> >>>>>>>>>> [READ], MinLatency(us) 262 257 >> >>>>>>>>>> [READ], MaxLatency(us) 205567 222335 >> >>>>>>>>>> [READ], 95thPercentileLatency(us) 2365 3475 >> >>>>>>>>>> [READ], 99thPercentileLatency(us) 3099 4143 >> >>>>>>>>>> [READ-MODIFY-WRITE], AverageLatency(us) 2559 2917 >> >>>>>>>>>> [READ-MODIFY-WRITE], MinLatency(us) 1100 1034 >> >>>>>>>>>> [READ-MODIFY-WRITE], MaxLatency(us) 208767 204799 >> >>>>>>>>>> [READ-MODIFY-WRITE], 95thPercentileLatency(us) 5747 7627 >> >>>>>>>>>> [READ-MODIFY-WRITE], 99thPercentileLatency(us) 7203 8919 >> >>>>>>>>>> [UPDATE], AverageLatency(us) 1700 1777 >> >>>>>>>>>> [UPDATE], MinLatency(us) 737 687 >> >>>>>>>>>> [UPDATE], MaxLatency(us) 97983 94271 >> >>>>>>>>>> [UPDATE], 95thPercentileLatency(us) 3377 4147 >> >>>>>>>>>> [UPDATE], 99thPercentileLatency(us) 4147 4831 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>> On Thu, Apr 4, 2019 at 1:14 AM Yu Li <car...@gmail.com> >> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks for the efforts boss. >> >>>>>>>>>>> >> >>>>>>>>>>> Since it's a new minor release, do we have performance >> comparison >> >>>>>>> report >> >>>>>>>>>>> with 1.4.9 as we did when releasing 1.4.0? If so, any >> reference? >> >>>>> Many >> >>>>>>>>>>> thanks! >> >>>>>>>>>>> >> >>>>>>>>>>> Best Regards, >> >>>>>>>>>>> Yu >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Thu, 4 Apr 2019 at 07:44, Andrew Purtell < >> apurt...@apache.org >> >>>> >> >>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> The fourth HBase 1.5.0 release candidate (RC3) is available >> for >> >>>>>>>>>> download >> >>>>>>>>>>> at >> >>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.5.0RC3/ >> >>> and >> >>>>>>>>>> Maven >> >>>>>>>>>>>> artifacts are available in the temporary repository >> >>>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>> >> >>> >> https://repository.apache.org/content/repositories/orgapachehbase-1292/ >> >>>>>>>>>>>> >> >>>>>>>>>>>> The git tag corresponding to the candidate is '1.5.0RC3’ >> >>>>>>> (b0bc7225c5). >> >>>>>>>>>>>> >> >>>>>>>>>>>> A detailed source and binary compatibility report for this >> >>> release >> >>>>> is >> >>>>>>>>>>>> available for your review at >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.5.0RC3/compat-check-report.html >> >>>>>>>>>>>> . >> >>>>>>>>>>>> >> >>>>>>>>>>>> A list of the 115 issues resolved in this release can be >> found >> >>> at >> >>>>>>>>>>>> https://s.apache.org/K4Wk . The 1.5.0 changelog is derived >> from >> >>>>> the >> >>>>>>>>>>>> changelog of the last branch-1.4 release, 1.4.9. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Please try out the candidate and vote +1/0/-1. >> >>>>>>>>>>>> >> >>>>>>>>>>>> The vote will be open for at least 72 hours. Unless >> objection I >> >>>>> will >> >>>>>>>>>> try >> >>>>>>>>>>> to >> >>>>>>>>>>>> close it Friday April 12, 2019 if we have sufficient votes. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Prior to making this announcement I made the following >> preflight >> >>>>>>>>>> checks: >> >>>>>>>>>>>> >> >>>>>>>>>>>> RAT check passes (7u80) >> >>>>>>>>>>>> Unit test suite passes (7u80, 8u181)* >> >>>>>>>>>>>> Opened the UI in a browser, poked around >> >>>>>>>>>>>> LTT load 100M rows with 100% verification and 20% updates >> >>> (8u181) >> >>>>>>>>>>>> ITBLL 1B rows with slowDeterministic monkey (8u181) >> >>>>>>>>>>>> ITBLL 1B rows with serverKilling monkey (8u181) >> >>>>>>>>>>>> >> >>>>>>>>>>>> There are known flaky tests. See HBASE-21904 and HBASE-21905. >> >>> These >> >>>>>>>>>> flaky >> >>>>>>>>>>>> tests do not represent serious test failures that would >> prevent >> >>> a >> >>>>>>>>>>> release. >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> -- >> >>>>>>>>>>>> Best regards, >> >>>>>>>>>>>> Andrew >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> Best regards, >> >>>>>>>>>> Andrew >> >>>>>>>>>> >> >>>>>>>>>> Words like orphans lost among the crosstalk, meaning torn from >> >>>>> truth's >> >>>>>>>>>> decrepit hands >> >>>>>>>>>> - A23, Crosstalk >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>> >> >>> >> >> >> >
