[jira] [Created] (HBASE-14064) Thrift Server skip put operation without column qualifier but client is not aware of this.
Hao Lin created HBASE-14064: --- Summary: Thrift Server skip put operation without column qualifier but client is not aware of this. Key: HBASE-14064 URL: https://issues.apache.org/jira/browse/HBASE-14064 Project: HBase Issue Type: Bug Components: Thrift Affects Versions: 0.98.6 Reporter: Hao Lin Priority: Minor After upgrading from 0.94.6 to 0.98.6, we found that a Put return success at Thrift client side does not write the data actually. We found the following messages in HBase server log: 2015-07-13 16:41:13,513 WARN [thrift-worker-0] thrift.ThriftServerRunner$HBaseHandler: No column qualifier specified. Delete is the only mutation supported over the whole column family. We found that the semantic of put operation with no column qualifier has changed. It is treated as empty qualifier in 0.94, but it is skipped in 0.98. The client is not aware of this change at all, no return value, no exception. Maybe it's better to throw an exception than skip the operation silently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: github mirror is not getting updated
Yup. It got fixed now. Thanks all. Regards Ram On Tue, Jul 14, 2015 at 2:41 AM, Dima Spivak dspi...@cloudera.com wrote: Looks to be fixed now. -Dima On Mon, Jul 13, 2015 at 11:06 AM, Andrew Purtell apurt...@apache.org wrote: File an INFRA ticket Ram? On Mon, Jul 13, 2015 at 9:57 AM, ramkrishna vasudevan ramkrishna.s.vasude...@gmail.com wrote: Hi All https://github.com/apache/hbase The github mirror is not getting updated. The last commit it shows is on Jul 10th. Is something wrong ? Regards Ram -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: [VOTE] First release candidate for HBase 1.0.2 (RC0) is available. Please vote by July 14 2015
+1 Downloaded src tarball. Verified md5 and signature. Checked RAT Built. Ran standalone instance. Loaded some data. Veriied it there. St.Ack On Tue, Jul 7, 2015 at 1:30 PM, Enis Söztutar e...@apache.org wrote: I am pleased to announce that the first release candidate for the release 1.0.2 (HBase-1.0.2RC0), is available for download at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.0.2RC0/ Maven artifacts are also available in the temporary repository https://repository.apache.org/content/repositories/orgapachehbase-1088 Signed with my code signing key E964B5FF. Can be found here: https://people.apache.org/keys/committer/enis.asc Signed tag in the repository can be found here: https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=11de648322d50c509e15373b3e35db1020a7d2c1 HBase 1.0.2 is the next “patch” release in the 1.0.x release line and supersedes 1.0.0 and 1.0.1. According to the HBase’s semantic version guide (See [1]), the release candidate is source and binary compatible with 1.0.x for client applications and server side libraries (coprocessors, filters, etc). Binary / source compatibility report of 1.0.2RC0 compared to 1.0.1 can be reached here: https://people.apache.org/~enis/1.0.1_1.0.2RC0_compat_report.html 1.0.2 release contains 123 fixes on top of 1.0.1 release. Most of the changes are bug fixes or test fixes except for the following: ** Improvement * [HBASE-12415] - Add add(byte[][] arrays) to Bytes. * [HBASE-12957] - region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data * [HBASE-13247] - Change BufferedMutatorExample to use addColumn() since add() is deprecated * [HBASE-13344] - Add enforcer rule that matches our JDK support statement * [HBASE-13366] - Throw DoNotRetryIOException instead of read only IOException * [HBASE-13420] - RegionEnvironment.offerExecutionLatency Blocks Threads under Heavy Load * [HBASE-13431] - Allow to skip store file range check based on column family while creating reference files in HRegionFileSystem#splitStoreFile * [HBASE-13550] - [Shell] Support unset of a list of table attributes * [HBASE-13761] - Optimize FuzzyRowFilter * [HBASE-13780] - Default to 700 for HDFS root dir permissions for secure deployments * [HBASE-13828] - Add group permissions testing coverage to AC. * [HBASE-13925] - Use zookeeper multi to clear znodes in ZKProcedureUtil ** New Feature * [HBASE-13057] - Provide client utility to easily enable and disable table replication ** Task * [HBASE-13764] - Backport HBASE-7782 (HBaseTestingUtility.truncateTable() not acting like CLI) to branch-1.x * [HBASE-13799] - javadoc how Scan gets polluted when used; if you set attributes or ask for scan metrics ** Sub-task * [HBASE-7847] - Use zookeeper multi to clear znodes * [HBASE-13035] - [0.98] Backport HBASE-12867 - Shell does not support custom replication endpoint specification * [HBASE-13201] - Remove HTablePool from thrift-server * [HBASE-13496] - Make Bytes$LexicographicalComparerHolder$UnsafeComparer::compareTo inlineable * [HBASE-13497] - Remove MVCC stamps from HFile when that is safe * [HBASE-13563] - Add missing table owner to AC tests. * [HBASE-13579] - Avoid isCellTTLExpired() for NO-TAG cases * [HBASE-13937] - Partially revert HBASE-13172· * [HBASE-13983] - Doc how the oddball HTable methods getStartKey, getEndKey, etc. will be removed in 2.0.0 * [HBASE-14003] - work around jdk8 spec bug in WALPerfEval Full list of the issues can be found at https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329865styleName=HtmlprojectId=12310753Create=Create Compatibility - This release (1.0.2) is source, wire and binary compatible with all previous 1.0.x releases. Client applications do not have to be recompiled with the new version (unless new API is used) if upgrading from a previous 1.0.x. It is a drop-in replacement. See release notes for 1.0.0 [2] for compatibility with earlier versions (0.94, 0.96, 0.98). Compatibility of 1.0.2 with earlier versions is the same as in 1.0.0. Source Compatibility: Client side code in HBase-1.0.x is (mostly) source compatible with 0.98.x versions. Some minor API changes might be needed from the client side. Wire Compatibility: HBase-1.0.x release is wire compatible with 0.98.x releases. Clients and servers running in different versions as long as new features are not used should be possible. A rolling upgrade from 0.98.x clusters to 1.0.x is supported as well. Rolling upgrade from 0.96 directly to 1.0.x is not supported. 1.0.x is NOT wire compatible with earlier releases (0.94, etc). Binary Compatibility: Binary compatibility at the Java API layer with earlier versions (0.98.x, 0.96.x and 0.94.x) is not supported. You may have to recompile your client code and any server side code
Re: [DISCUSS] Requesting releases from our upstream dependencies
How's this sound? Hi Hadoopers! Over in HBase we've been discussing the impact of our dependencies on our downstream users. As our most fundamental dependency, Hadoop plays a big role in the operational cost of running an HBase instance. Currently the HBase 1.y release line supports Hadoop 2.4, 2.5, and 2.6[1]. We don't drop Hadoop minor release lines in minor releases so we are unlikely remove anything from this set until HBase 2.0, probably at the end of 2015 / start of 2016 (and currently we plan to continue supporting at least 2.4 for HBase 2.0 [2]). Lately we've been discussing updating our shipped binaries to Hadoop 2.6, following some stability testing by part of our community[3]. Unfortunately, 2.6.0 in particular has a couple of bugs that could destroy HBase clusters should users decide to turn on HDFS encryption[4]. Our installation instructions tell folks to replace these jars with the version of Hadoop they are actually running, but not all users follow those instructions so we want to minimize the pain for them. Regular maintenance releases are key to keeping operational burdens low for our downstream users; we don't want them to be forced to choose between living with broken systems and stomaching the risk of upgrades across minor/major version numbers. Looking back over the three aforementioned Hadoop versions, 2.6 hasn't had a patch release since 2.6.0 came out in Nov 2014, when 2.5 had its last patch release as well. Hadoop 2.4 looks to be a year without a release[5]. On our discussion of shipping Hadoop 2.6 binaries, one of your PMC members mentioned that with continued work on the 2.7 line y'all weren't planning any additional releases of the earlier minor versions[6]. The HBase community requests that Hadoop pick up making bug-fix-only patch releases again on a regular schedule[7]. Preferably on the 2.6 line and preferably monthly. We realize that given the time gap since 2.6.0 it will likely take a big to get 2.6.1 together, but after that it should take much less effort to continue. [1]: http://hbase.apache.org/book.html#hadoop [2]: http://s.apache.org/ReP [3]: HBASE-13339 [4]: HADOOP-11674 and HADOOP-11710 [5]: http://hadoop.apache.org/releases.html [6]: http://s.apache.org/MTY [7]: http://s.apache.org/ViP -Sean On Wed, Jul 1, 2015 at 6:54 PM, Ted Yu yuzhih...@gmail.com wrote: +1 On Wed, Jul 1, 2015 at 4:53 PM, Nick Dimiduk ndimi...@gmail.com wrote: This strikes me as a reasonable (and, err, surprising-that-it's-necissary) request. +1 On Wed, Jul 1, 2015 at 3:46 PM, Andrew Purtell apurt...@apache.org wrote: +1 On Wed, Jul 1, 2015 at 3:27 PM, Stack st...@duboce.net wrote: +1 on making request. St.Ack On Wed, Jul 1, 2015 at 2:33 PM, Sean Busbey bus...@cloudera.com wrote: On one of our open issues about Hadoop versions, one of the Hadoop PMC members mentioned that the 2.6.z line wasn't planning any additional releases[1]. I'd like us to request, as a downstream community, that the Hadoop project plan for maintenance releases on this line given the non-production status of 2.7.0, unevaluated quality of further 2.7 releases and the unknown status of a 2.8 release. Right now, there's substantial evidence from our Elliot that we should be pushing our users from the 2.4/2.5 releases onto 2.6. At the moment, 2.6.0 contains a couple of critical bugs that effectively prevent the use of HDFS transparent encryption[2]. Now, that feature isn't needed but it's nice to have as an operational alternative to our own implementation. And the current bug _destroys_ HBase clusters, so the consequences for the curious are severe. That specific issue aside, however, as a system that runs on top of Hadoop we impose on our downstream users a dependency on that project. Regular maintenance releases are critical to easing long term operational pain, so we should proactively look out for them by prodding our less stable upstream dependencies. [1]: http://s.apache.org/MTY [2]: HADOOP-11674 and HADOOP-11710 -- Sean -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) -- Sean
Re: [DISCUSS] Requesting releases from our upstream dependencies
Reads well. Thanks Sean, St.Ack On Mon, Jul 13, 2015 at 9:58 PM, Sean Busbey bus...@cloudera.com wrote: How's this sound? Hi Hadoopers! Over in HBase we've been discussing the impact of our dependencies on our downstream users. As our most fundamental dependency, Hadoop plays a big role in the operational cost of running an HBase instance. Currently the HBase 1.y release line supports Hadoop 2.4, 2.5, and 2.6[1]. We don't drop Hadoop minor release lines in minor releases so we are unlikely remove anything from this set until HBase 2.0, probably at the end of 2015 / start of 2016 (and currently we plan to continue supporting at least 2.4 for HBase 2.0 [2]). Lately we've been discussing updating our shipped binaries to Hadoop 2.6, following some stability testing by part of our community[3]. Unfortunately, 2.6.0 in particular has a couple of bugs that could destroy HBase clusters should users decide to turn on HDFS encryption[4]. Our installation instructions tell folks to replace these jars with the version of Hadoop they are actually running, but not all users follow those instructions so we want to minimize the pain for them. Regular maintenance releases are key to keeping operational burdens low for our downstream users; we don't want them to be forced to choose between living with broken systems and stomaching the risk of upgrades across minor/major version numbers. Looking back over the three aforementioned Hadoop versions, 2.6 hasn't had a patch release since 2.6.0 came out in Nov 2014, when 2.5 had its last patch release as well. Hadoop 2.4 looks to be a year without a release[5]. On our discussion of shipping Hadoop 2.6 binaries, one of your PMC members mentioned that with continued work on the 2.7 line y'all weren't planning any additional releases of the earlier minor versions[6]. The HBase community requests that Hadoop pick up making bug-fix-only patch releases again on a regular schedule[7]. Preferably on the 2.6 line and preferably monthly. We realize that given the time gap since 2.6.0 it will likely take a big to get 2.6.1 together, but after that it should take much less effort to continue. [1]: http://hbase.apache.org/book.html#hadoop [2]: http://s.apache.org/ReP [3]: HBASE-13339 [4]: HADOOP-11674 and HADOOP-11710 [5]: http://hadoop.apache.org/releases.html [6]: http://s.apache.org/MTY [7]: http://s.apache.org/ViP -Sean On Wed, Jul 1, 2015 at 6:54 PM, Ted Yu yuzhih...@gmail.com wrote: +1 On Wed, Jul 1, 2015 at 4:53 PM, Nick Dimiduk ndimi...@gmail.com wrote: This strikes me as a reasonable (and, err, surprising-that-it's-necissary) request. +1 On Wed, Jul 1, 2015 at 3:46 PM, Andrew Purtell apurt...@apache.org wrote: +1 On Wed, Jul 1, 2015 at 3:27 PM, Stack st...@duboce.net wrote: +1 on making request. St.Ack On Wed, Jul 1, 2015 at 2:33 PM, Sean Busbey bus...@cloudera.com wrote: On one of our open issues about Hadoop versions, one of the Hadoop PMC members mentioned that the 2.6.z line wasn't planning any additional releases[1]. I'd like us to request, as a downstream community, that the Hadoop project plan for maintenance releases on this line given the non-production status of 2.7.0, unevaluated quality of further 2.7 releases and the unknown status of a 2.8 release. Right now, there's substantial evidence from our Elliot that we should be pushing our users from the 2.4/2.5 releases onto 2.6. At the moment, 2.6.0 contains a couple of critical bugs that effectively prevent the use of HDFS transparent encryption[2]. Now, that feature isn't needed but it's nice to have as an operational alternative to our own implementation. And the current bug _destroys_ HBase clusters, so the consequences for the curious are severe. That specific issue aside, however, as a system that runs on top of Hadoop we impose on our downstream users a dependency on that project. Regular maintenance releases are critical to easing long term operational pain, so we should proactively look out for them by prodding our less stable upstream dependencies. [1]: http://s.apache.org/MTY [2]: HADOOP-11674 and HADOOP-11710 -- Sean -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) -- Sean
[jira] [Created] (HBASE-14070) Hybrid Logical Clocks for HBase
Enis Soztutar created HBASE-14070: - Summary: Hybrid Logical Clocks for HBase Key: HBASE-14070 URL: https://issues.apache.org/jira/browse/HBASE-14070 Project: HBase Issue Type: New Feature Reporter: Enis Soztutar Assignee: Enis Soztutar HBase and Phoenix uses systems physical clock (PT) to give timestamps to events (read and writes). This works mostly when the system clock is strictly monotonically increasing and there is no cross-dependency between servers clocks. However we know that leap seconds, general clock skew and clock drift are in fact real. This jira proposes using Hybrid Logical Clocks (HLC) as an implementation of hybrid physical clock + a logical clock. HLC is best of both worlds where it keeps causality relationship similar to logical clocks, but still is compatible with NTP based physical system clock. HLC can be represented in 64bits. A design document is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14071) Document HBase directory layout for troubleshooting purposes
Misty Stanley-Jones created HBASE-14071: --- Summary: Document HBase directory layout for troubleshooting purposes Key: HBASE-14071 URL: https://issues.apache.org/jira/browse/HBASE-14071 Project: HBase Issue Type: Task Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones Document how to troubleshoot things like unexpected snapshot and WAL growth on the filesystem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
github mirror is not getting updated
Hi All https://github.com/apache/hbase The github mirror is not getting updated. The last commit it shows is on Jul 10th. Is something wrong ? Regards Ram
[jira] [Reopened] (HBASE-7782) HBaseTestingUtility.truncateTable() not acting like CLI
[ https://issues.apache.org/jira/browse/HBASE-7782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reopened HBASE-7782: HBaseTestingUtility.truncateTable() not acting like CLI --- Key: HBASE-7782 URL: https://issues.apache.org/jira/browse/HBASE-7782 Project: HBase Issue Type: Improvement Components: test Affects Versions: 0.94.3 Reporter: Adrien Mogenet Assignee: Sean Busbey Priority: Minor Labels: cli, hbasetest, test Fix For: 2.0.0 Attachments: HBASE-7782.patch I would like to discuss the behavior of the truncateTable() method of HBaseTestingUtility. It's currently only removing the data through a scan/delete pattern. However, the truncate command in CLI is doing additional things: it disables the tables, drop, creates (with similar column descriptors) and then enables the table. I think the truncateTable() method is misleading; for example I used it to force a coprocessor to be reloaded, but it did not. Of course I can disable and enable the table by myself within my unit test, but perhaps it deserves to be discussed? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14065) ref guide section on release candidate generation refers to old doc files
Sean Busbey created HBASE-14065:
---
Summary: ref guide section on release candidate generation refers
to old doc files
Key: HBASE-14065
URL: https://issues.apache.org/jira/browse/HBASE-14065
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: Sean Busbey
currently it says to copy files from the master version of {{src/main/docbkx}}
which is incorrect since the move to asciidoc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-14066) clean out old docbook docs from branch-1
Sean Busbey created HBASE-14066: --- Summary: clean out old docbook docs from branch-1 Key: HBASE-14066 URL: https://issues.apache.org/jira/browse/HBASE-14066 Project: HBase Issue Type: Task Components: documentation Affects Versions: 1.2.0 Reporter: Sean Busbey Assignee: Sean Busbey Fix For: 1.2.0 branch-1 has the old docbook docs and a placeholder for the new asciidoc docs. Since we make all documentation changes to asciidoc and copy it over the documentation for a release line, excise the docbook directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-13724) ReplicationSource dies under certain conditions reading a sequence file
[
https://issues.apache.org/jira/browse/HBASE-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-13724.
Resolution: Not A Problem
Resolving as Not A Problem because there hasn't been any progress and we can't
recommend running in production with -ea. Never mind HBase code, what else is
out there waiting to be tripped. No problem to reopen when and if there's a
patch available for review.
ReplicationSource dies under certain conditions reading a sequence file
---
Key: HBASE-13724
URL: https://issues.apache.org/jira/browse/HBASE-13724
Project: HBase
Issue Type: Bug
Reporter: churro morales
A little background,
We run our server in -ea mode and have seen quite a few replication sources
silently die over the past few months.
Note: the stacktrace I posted below comes from a regionserver running 0.94
but quickly looking at this issue, I believe this will happen in 98 too.
Should we harden replication source to deal with these types of assertion
errors by catching throwables, should we be dealing with this at the sequence
file reader level? Still looking into the root cause of this issue but when
manually shutdown our regionservers the regionserver that recovered its queue
replicated that log just fine. So in our case a simple retry would've worked
just fine.
{code}
2015-05-08 11:04:23,348 ERROR
org.apache.hadoop.hbase.replication.regionserver.ReplicationSource:
Unexpected exception in ReplicationSource,
currentPath=hdfs://hm6.xxx.flurry.com:9000/hbase/.logs/x.yy.flurry.com,60020,1426792702998/x.atl.flurry.com%2C60020%2C1426792702998.1431107922449
java.lang.AssertionError
at
org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader$WALReader$WALReaderFSDataInputStream.getPos(SequenceFileLogReader.java:121)
at
org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1489)
at
org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1479)
at
org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1474)
at
org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader$WALReader.init(SequenceFileLogReader.java:55)
at
org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.init(SequenceFileLogReader.java:178)
at
org.apache.hadoop.hbase.regionserver.wal.HLog.getReader(HLog.java:734)
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationHLogReaderManager.openReader(ReplicationHLogReaderManager.java:69)
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.openReader(ReplicationSource.java:583)
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:373)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Review request for HBASE-13743
We had a user get bit by this so I'd like to get HBASE-13743 into 0.98.14, first RC planned for tomorrow. It's going to hold up the RC until it goes in. Can I get a reviewer for this? I'm not getting clean precommit builds and can't tell if it is Jenkins noise (TestImportExport is notorious since it's heavyweight) or something more - tests pass for me locally, repeatedly. Please consider running the tests flagged in the precommit locally too. -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
[jira] [Resolved] (HBASE-13706) CoprocessorClassLoader should not exempt Hive classes
[ https://issues.apache.org/jira/browse/HBASE-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-13706. Resolution: Not A Problem CoprocessorClassLoader should not exempt Hive classes - Key: HBASE-13706 URL: https://issues.apache.org/jira/browse/HBASE-13706 Project: HBase Issue Type: Bug Components: Coprocessors Affects Versions: 2.0.0, 1.0.1, 1.1.0, 0.98.12 Reporter: Jerry He Priority: Minor CoprocessorClassLoader is used to load classes from the coprocessor jar. Certain classes are exempt from being loaded by this ClassLoader, which means they will be ignored in the coprocessor jar, but loaded from parent classpath instead. One problem is that we categorically exempt org.apache.hadoop. But it happens that Hive packages start with org.apache.hadoop. There is no reason to exclude hive classes from theCoprocessorClassLoader. HBase does not even include Hive jars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: github mirror is not getting updated
File an INFRA ticket Ram? On Mon, Jul 13, 2015 at 9:57 AM, ramkrishna vasudevan ramkrishna.s.vasude...@gmail.com wrote: Hi All https://github.com/apache/hbase The github mirror is not getting updated. The last commit it shows is on Jul 10th. Is something wrong ? Regards Ram -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
[jira] [Reopened] (HBASE-13632) Backport HBASE-13368 to branch-1 and 0.98
[ https://issues.apache.org/jira/browse/HBASE-13632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reopened HBASE-13632: - Backport HBASE-13368 to branch-1 and 0.98 - Key: HBASE-13632 URL: https://issues.apache.org/jira/browse/HBASE-13632 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Trivial Fix For: 0.98.13, 1.0.2, 1.2.0, 1.1.1 Attachments: HBASE-13368_0.98.patch, HBASE-13368_branch-1.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-7782) HBaseTestingUtility.truncateTable() not acting like CLI
[ https://issues.apache.org/jira/browse/HBASE-7782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-7782. Resolution: Fixed Hadoop Flags: Incompatible change,Reviewed (was: Reviewed) Release Note: HBaseTestingUtility now uses the truncate API added in HBASE-8332 so that calls to HBTU.truncateTable will behave like the shell command: effectively dropping the table and recreating a new one with the same split points. Previously, HBTU.truncateTable instead issued deletes for all the data already in the table. If you wish to maintain the same behavior, you should use the newly added HBTU.deleteTableData method. HBaseTestingUtility.truncateTable() not acting like CLI --- Key: HBASE-7782 URL: https://issues.apache.org/jira/browse/HBASE-7782 Project: HBase Issue Type: Improvement Components: test Affects Versions: 0.94.3 Reporter: Adrien Mogenet Assignee: Sean Busbey Priority: Minor Labels: cli, hbasetest, test Fix For: 2.0.0 Attachments: HBASE-7782.patch I would like to discuss the behavior of the truncateTable() method of HBaseTestingUtility. It's currently only removing the data through a scan/delete pattern. However, the truncate command in CLI is doing additional things: it disables the tables, drop, creates (with similar column descriptors) and then enables the table. I think the truncateTable() method is misleading; for example I used it to force a coprocessor to be reloaded, but it did not. Of course I can disable and enable the table by myself within my unit test, but perhaps it deserves to be discussed? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-13764) Backport HBASE-7782 (HBaseTestingUtility.truncateTable() not acting like CLI) to branch-1.x
[
https://issues.apache.org/jira/browse/HBASE-13764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey resolved HBASE-13764.
-
Resolution: Fixed
Hadoop Flags: Incompatible change,Reviewed (was: Reviewed)
Release Note:
HBaseTestingUtility now uses the truncate API added in HBASE-8332 so that calls
to HBTU.truncateTable will behave like the shell command: effectively dropping
the table and recreating a new one with the same split points.
Previously, HBTU.truncateTable instead issued deletes for all the data already
in the table. If you wish to maintain the same behavior, you should use the
newly added HBTU.deleteTableData method.
Backport HBASE-7782 (HBaseTestingUtility.truncateTable() not acting like CLI)
to branch-1.x
---
Key: HBASE-13764
URL: https://issues.apache.org/jira/browse/HBASE-13764
Project: HBase
Issue Type: Task
Affects Versions: 1.2.0
Reporter: Srikanth Srungarapu
Assignee: Ashish Singhi
Priority: Minor
Fix For: 1.0.2, 1.2.0, 1.1.1
Attachments: 13764-branch-1.patch, 13764-branch-1_v1.patch,
HBASE-13764-branch-1.patch
Backport this test infrastructure improvement, which makes
{{truncateTable()}} in HBaseTestingUtility behave in the same way it's CLI
counterpart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (HBASE-13764) Backport HBASE-7782 (HBaseTestingUtility.truncateTable() not acting like CLI) to branch-1.x
[
https://issues.apache.org/jira/browse/HBASE-13764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey reopened HBASE-13764:
-
Backport HBASE-7782 (HBaseTestingUtility.truncateTable() not acting like CLI)
to branch-1.x
---
Key: HBASE-13764
URL: https://issues.apache.org/jira/browse/HBASE-13764
Project: HBase
Issue Type: Task
Affects Versions: 1.2.0
Reporter: Srikanth Srungarapu
Assignee: Ashish Singhi
Priority: Minor
Fix For: 1.0.2, 1.2.0, 1.1.1
Attachments: 13764-branch-1.patch, 13764-branch-1_v1.patch,
HBASE-13764-branch-1.patch
Backport this test infrastructure improvement, which makes
{{truncateTable()}} in HBaseTestingUtility behave in the same way it's CLI
counterpart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: github mirror is not getting updated
Looks to be fixed now. -Dima On Mon, Jul 13, 2015 at 11:06 AM, Andrew Purtell apurt...@apache.org wrote: File an INFRA ticket Ram? On Mon, Jul 13, 2015 at 9:57 AM, ramkrishna vasudevan ramkrishna.s.vasude...@gmail.com wrote: Hi All https://github.com/apache/hbase The github mirror is not getting updated. The last commit it shows is on Jul 10th. Is something wrong ? Regards Ram -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
[jira] [Created] (HBASE-14069) Add the ability for RegionSplitter to rolling split without using a SplitAlgorithm
Elliott Clark created HBASE-14069: - Summary: Add the ability for RegionSplitter to rolling split without using a SplitAlgorithm Key: HBASE-14069 URL: https://issues.apache.org/jira/browse/HBASE-14069 Project: HBase Issue Type: New Feature Reporter: Elliott Clark RegionSplittler is the utility that can rolling split regions. It would be nice to be able to split regions and have the normal split points get computed for me so that I'm not reliant on knowing data distribution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14067) bundle ruby files for hbase shell into a jar.
Sean Busbey created HBASE-14067: --- Summary: bundle ruby files for hbase shell into a jar. Key: HBASE-14067 URL: https://issues.apache.org/jira/browse/HBASE-14067 Project: HBase Issue Type: Improvement Components: shell Reporter: Sean Busbey Fix For: 2.0.0, 1.3.0, 0.98.15 We currently package all the ruby scripts for the hbase shell by placing them in a directory within lib/. We should be able to put these in a jar file since we rely on jruby. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14068) How to Release docs should include pointers for making signed tags
Sean Busbey created HBASE-14068: --- Summary: How to Release docs should include pointers for making signed tags Key: HBASE-14068 URL: https://issues.apache.org/jira/browse/HBASE-14068 Project: HBase Issue Type: Improvement Components: documentation Reporter: Sean Busbey Assignee: Sean Busbey Fix For: 2.0.0 current how to make a release candidate section includes a step to make a tag for the RC, but doesn't talk about signing said tag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] First release candidate for HBase 1.0.2 (RC0) is available. Please vote by July 14 2015
Here is my official +1. Checked sigs, crcs. Checked layout, jar files. Checked the book. Checked versions, Checked the compatibility report. Compiled with Hadoop-2.2+ Ran single node, checked web UI seems fine. Run LTT on single node. Run some simple smoke tests from shell Checked the logs, nothing out of ordinary Run the hbase-downstreamer project on the mvn artifacts Unit tests seems fine except for TestShell that we discussed above: https://builds.apache.org/view/All/job/HBase-1.0.2RC0/ Running TestShell locally, I cannot reproduce the failure even after 20 runs. I don't want to sink the RC due to a flaky test. Kind reminder that the vote ends tomorrow. Enis On Thu, Jul 9, 2015 at 3:39 PM, Jean-Marc Spaggiari jean-m...@spaggiari.org wrote: :( Culprit files were the console output of the tests. I removed the files and it passed. sorry about that. JM 2015-07-09 18:02 GMT-04:00 Ted Yu yuzhih...@gmail.com: I ran 'mvn apache-rat:check' and it passed. Can you take a look at rat.txt and tell us which files lack license ? Cheers On Thu, Jul 9, 2015 at 2:57 PM, Jean-Marc Spaggiari jean-m...@spaggiari.org wrote: See below for the rat check. I ran it against the src. jmspaggi@node8:/tmp/ dist.apache.org/repos/dist/dev/hbase/hbase-1.0.2RC0/hbase-1.0.2-src$ export JAVA_HOME=/usr/local/jdk1.7.0_45/ jmspaggi@node8:/tmp/ dist.apache.org/repos/dist/dev/hbase/hbase-1.0.2RC0/hbase-1.0.2-src$ mvn apache-rat:check [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] HBase [INFO] HBase - Checkstyle [INFO] HBase - Annotations [INFO] HBase - Common [INFO] HBase - Protocol [INFO] HBase - Client [INFO] HBase - Hadoop Compatibility [INFO] HBase - Hadoop Two Compatibility [INFO] HBase - Prefix Tree [INFO] HBase - Server [INFO] HBase - Testing Util [INFO] HBase - Thrift [INFO] HBase - Rest [INFO] HBase - Shell [INFO] HBase - Integration Tests [INFO] HBase - Examples [INFO] HBase - Assembly [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 [INFO] [INFO] [INFO] Building HBase 1.0.2 [INFO] [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 [INFO] [INFO] --- apache-rat-plugin:0.11:check (default-cli) @ hbase --- [INFO] 67 implicit excludes (use -debug for more details). [INFO] Exclude: **/*.versionsBackup [INFO] Exclude: **/*.log [INFO] Exclude: **/.* [INFO] Exclude: **/*.tgz [INFO] Exclude: **/*.orig [INFO] Exclude: **/8e8ab58dcf39412da19833fcd8f687ac [INFO] Exclude: **/a6a6562b777440fd9c34885428f5cb61.21e75333ada3d5bafb34bb918f29576c [INFO] Exclude: **/0016310 [INFO] Exclude: **/.git/** [INFO] Exclude: **/.idea/** [INFO] Exclude: **/*.iml [INFO] Exclude: **/target/** [INFO] Exclude: **/CHANGES.txt [INFO] Exclude: **/README.md [INFO] Exclude: **/generated/** [INFO] Exclude: **/gen-*/** [INFO] Exclude: **/conf/* [INFO] Exclude: **/*.avpr [INFO] Exclude: **/*.svg [INFO] Exclude: **/META-INF/services/** [INFO] Exclude: **/src/main/asciidoc/hbase.css [INFO] Exclude: **/src/main/asciidoc/asciidoctor.css [INFO] Exclude: **/bootstrap-theme.css [INFO] Exclude: **/bootstrap-theme.min.css [INFO] Exclude: **/jquery.min.js [INFO] Exclude: **/*.vm [INFO] Exclude: **/control [INFO] Exclude: **/conffile [INFO] Exclude: docs/* [INFO] Exclude: logs/* [INFO] Exclude: **/src/main/site/resources/css/freebsd_docbook.css [INFO] Exclude: dev-support/hbase_docker/README.md [INFO] Exclude: .git/** [INFO] Exclude: .svn/** [INFO] Exclude: **/.settings/** [INFO] Exclude: **/patchprocess/** [INFO] 215 resources included (use -debug for more details) Warning: org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property ' http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not recognized. Avertissements de compilateur : WARNING: 'org.apache.xerces.jaxp.SAXParserImpl: Property '
[jira] [Reopened] (HBASE-14034) HBase Backup/Restore Phase 1: Abstract Coordination manager (Zk) operations
[ https://issues.apache.org/jira/browse/HBASE-14034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov reopened HBASE-14034: --- I am reopening this JIRA because there is Zk-related code in distributed log roll procedure which needs to be abstracted. HBase Backup/Restore Phase 1: Abstract Coordination manager (Zk) operations --- Key: HBASE-14034 URL: https://issues.apache.org/jira/browse/HBASE-14034 Project: HBase Issue Type: Task Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Fix For: 2.0.0 Abstract Coordination manager (Zk) operations. See org.apache.hadoop.hbase.coordination package for references. Provide Zookeeper implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-14035) HBase Backup/Restore Phase 1: hbase:backup - backup system table
[ https://issues.apache.org/jira/browse/HBASE-14035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov resolved HBASE-14035. --- Resolution: Fixed The patch is attached to a parent JIRA (HBASE-14030). See v1. HBase Backup/Restore Phase 1: hbase:backup - backup system table Key: HBASE-14035 URL: https://issues.apache.org/jira/browse/HBASE-14035 Project: HBase Issue Type: Task Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Fix For: 2.0.0 *hbase:backup* - move all backup meta info from Zk (coordination manager) to hbase system table. Do not use Zk (coordination manager) as a persistent storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (HBASE-14034) HBase Backup/Restore Phase 1: Abstract Coordination manager (Zk) operations
[ https://issues.apache.org/jira/browse/HBASE-14034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov reopened HBASE-14034: --- I am reopening this JIRA because there is Zk-related code in distributed log roll procedure which needs to be abstracted. HBase Backup/Restore Phase 1: Abstract Coordination manager (Zk) operations --- Key: HBASE-14034 URL: https://issues.apache.org/jira/browse/HBASE-14034 Project: HBase Issue Type: Task Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Fix For: 2.0.0 Abstract Coordination manager (Zk) operations. See org.apache.hadoop.hbase.coordination package for references. Provide Zookeeper implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-14034) HBase Backup/Restore Phase 1: Abstract Coordination manager (Zk) operations
[ https://issues.apache.org/jira/browse/HBASE-14034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov resolved HBASE-14034. --- Resolution: Fixed Patch is attached to master JIRA (HBASE-14030) as v2. HBase Backup/Restore Phase 1: Abstract Coordination manager (Zk) operations --- Key: HBASE-14034 URL: https://issues.apache.org/jira/browse/HBASE-14034 Project: HBase Issue Type: Task Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Fix For: 2.0.0 Abstract Coordination manager (Zk) operations. See org.apache.hadoop.hbase.coordination package for references. Provide Zookeeper implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
