You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hbase.apache.org by el...@apache.org on 2021/02/25 16:55:02 UTC
[hbase] branch branch-1 updated: HBASE-25601 Use ASF-official
mailing list archives
This is an automated email from the ASF dual-hosted git repository.
elserj pushed a commit to branch branch-1
in repository https://gitbox.apache.org/repos/asf/hbase.git
The following commit(s) were added to refs/heads/branch-1 by this push:
new a7574ec HBASE-25601 Use ASF-official mailing list archives
a7574ec is described below
commit a7574ec9a0b22d7999bbb82173cbee58517d2849
Author: Josh Elser <el...@apache.org>
AuthorDate: Wed Feb 24 11:15:30 2021 -0500
HBASE-25601 Use ASF-official mailing list archives
Signed-off-by: Peter Somogyi <ps...@apache.org>
Signed-off-by: Duo Zhang <zh...@apache.org>
Closes #2983
---
pom.xml | 2 --
src/main/asciidoc/_chapters/community.adoc | 8 ++++----
src/main/asciidoc/_chapters/compression.adoc | 4 +---
src/main/asciidoc/_chapters/configuration.adoc | 8 ++++++--
src/main/asciidoc/_chapters/developer.adoc | 14 ++++++--------
src/main/asciidoc/_chapters/ops_mgt.adoc | 1 -
src/main/asciidoc/_chapters/performance.adoc | 3 +--
src/main/asciidoc/_chapters/schema_design.adoc | 4 ++--
src/main/asciidoc/_chapters/troubleshooting.adoc | 16 +++-------------
9 files changed, 23 insertions(+), 37 deletions(-)
diff --git a/pom.xml b/pom.xml
index e896df5..ae4dabe 100644
--- a/pom.xml
+++ b/pom.xml
@@ -119,7 +119,6 @@
<archive>https://mail-archives.apache.org/mod_mbox/hbase-user/</archive>
<otherArchives>
<otherArchive>https://dir.gmane.org/gmane.comp.java.hadoop.hbase.user</otherArchive>
- <otherArchive>https://search-hadoop.com/?q=&fc_project=HBase</otherArchive>
</otherArchives>
</mailingList>
<mailingList>
@@ -130,7 +129,6 @@
<archive>https://mail-archives.apache.org/mod_mbox/hbase-dev/</archive>
<otherArchives>
<otherArchive>https://dir.gmane.org/gmane.comp.java.hadoop.hbase.devel</otherArchive>
- <otherArchive>https://search-hadoop.com/?q=&fc_project=HBase</otherArchive>
</otherArchives>
</mailingList>
<mailingList>
diff --git a/src/main/asciidoc/_chapters/community.adoc b/src/main/asciidoc/_chapters/community.adoc
index 4b91b0d..5739df19 100644
--- a/src/main/asciidoc/_chapters/community.adoc
+++ b/src/main/asciidoc/_chapters/community.adoc
@@ -37,7 +37,7 @@ Just request the name of your branch be added to JIRA up on the developer's mail
Thereafter you can file issues against your feature branch in Apache HBase JIRA.
Your code you keep elsewhere -- it should be public so it can be observed -- and you can update dev mailing list on progress.
When the feature is ready for commit, 3 +1s from committers will get your feature merged.
-See link:http://search-hadoop.com/m/asM982C5FkS1[HBase, mail # dev - Thoughts
+See link:https://lists.apache.org/thread.html/200513c7e7e4df23c8b9134eeee009d61205c79314e77f222d396006%401346870308%40%3Cdev.hbase.apache.org%3E[HBase, mail # dev - Thoughts
about large feature dev branches]
[[patchplusonepolicy]]
@@ -61,7 +61,7 @@ Any -1 on a patch by anyone vetos a patch; it cannot be committed until the just
[[hbase.fix.version.in.jira]]
.How to set fix version in JIRA on issue resolve
-Here is how link:http://search-hadoop.com/m/azemIi5RCJ1[we agreed] to set versions in JIRA when we resolve an issue.
+Here is how we agreed to set versions in JIRA when we resolve an issue.
If trunk is going to be 0.98.0 then:
* Commit only to trunk: Mark with 0.98
@@ -73,7 +73,7 @@ If trunk is going to be 0.98.0 then:
[[hbase.when.to.close.jira]]
.Policy on when to set a RESOLVED JIRA as CLOSED
-We link:http://search-hadoop.com/m/4cIKs1iwXMS1[agreed] that for issues that list multiple releases in their _Fix Version/s_ field, CLOSE the issue on the release of any of the versions listed; subsequent change to the issue must happen in a new JIRA.
+We agreed that for issues that list multiple releases in their _Fix Version/s_ field, CLOSE the issue on the release of any of the versions listed; subsequent change to the issue must happen in a new JIRA.
[[no.permanent.state.in.zk]]
.Only transient state in ZooKeeper!
@@ -103,7 +103,7 @@ Owners do not need to be committers.
[[hbase.commit.msg.format]]
== Commit Message format
-We link:http://search-hadoop.com/m/Gwxwl10cFHa1[agreed] to the following SVN commit message format:
+We agreed to the following Git commit message format:
[source]
----
HBASE-xxxxx <title>. (<contributor>)
diff --git a/src/main/asciidoc/_chapters/compression.adoc b/src/main/asciidoc/_chapters/compression.adoc
index 78fc6a2..e1ed4dc 100644
--- a/src/main/asciidoc/_chapters/compression.adoc
+++ b/src/main/asciidoc/_chapters/compression.adoc
@@ -31,8 +31,6 @@
NOTE: Codecs mentioned in this section are for encoding and decoding data blocks or row keys.
For information about replication codecs, see <<cluster.replication.preserving.tags,cluster.replication.preserving.tags>>.
-Some of the information in this section is pulled from a link:http://search-hadoop.com/m/lL12B1PFVhp1/v=threaded[discussion] on the HBase Development mailing list.
-
HBase supports several different compression algorithms which can be enabled on a ColumnFamily.
Data block encoding attempts to limit duplication of information in keys, taking advantage of some of the fundamental designs and patterns of HBase, such as sorted row keys and the schema of a given table.
Compressors reduce the size of large, opaque byte arrays in cells, and can significantly reduce the storage space needed to store uncompressed data.
@@ -129,7 +127,7 @@ Come and write the dev list if you are interesting in carrying-on this encoding.
The compression or codec type to use depends on the characteristics of your data. Choosing the wrong type could cause your data to take more space rather than less, and can have performance implications.
-In general, you need to weigh your options between smaller size and faster compression/decompression. Following are some general guidelines, expanded from a discussion at link:http://search-hadoop.com/m/lL12B1PFVhp1[Documenting Guidance on compression and codecs].
+In general, you need to weigh your options between smaller size and faster compression/decompression. Following are some general guidelines, expanded from a discussion at link:https://lists.apache.org/thread.html/481e67a61163efaaf4345510447a9244871a8d428244868345a155ff%401378926618%40%3Cdev.hbase.apache.org%3E[Documenting Guidance on compression and codecs].
* If you have long keys (compared to the values) or many columns, use a prefix encoder.
FAST_DIFF is recommended, as more testing is needed for Prefix Tree encoding.
diff --git a/src/main/asciidoc/_chapters/configuration.adoc b/src/main/asciidoc/_chapters/configuration.adoc
index e2013bd..2c64db5 100644
--- a/src/main/asciidoc/_chapters/configuration.adoc
+++ b/src/main/asciidoc/_chapters/configuration.adoc
@@ -877,8 +877,12 @@ If your working set it such that block cache does you no good, at least size the
==== link:http://en.wikipedia.org/wiki/Nagle's_algorithm[Nagle's] or the small package problem
If a big 40ms or so occasional delay is seen in operations against HBase, try the Nagles' setting.
-For example, see the user mailing list thread, link:http://search-hadoop.com/m/pduLg2fydtE/Inconsistent+scan+performance+with+caching+set+&subj=Re+Inconsistent+scan+performance+with+caching+set+to+1[Inconsistent scan performance with caching set to 1] and the issue cited therein where setting `notcpdelay` improved scan speeds.
-You might also see the graphs on the tail of link:https://issues.apache.org/jira/browse/HBASE-7008[HBASE-7008 Set scanner caching to a better default] where our Lars Hofhansl tries various data sizes w/ Nagle's on and off measuring the effect.
+For example, see the user mailing list thread,
+link:https://lists.apache.org/thread.html/3d7ceb41c04a955b1b1c80480cdba95208ca3e97bf6895a40e0c1bbb%401346186127%40%3Cuser.hbase.apache.org%3E[Inconsistent scan performance with caching set to 1]
+and the issue cited therein where setting `notcpdelay` improved scan speeds. You might also see the
+graphs on the tail of
+link:https://issues.apache.org/jira/browse/HBASE-7008[HBASE-7008 Set scanner caching to a better default]
+where our Lars Hofhansl tries various data sizes w/ Nagle's on and off measuring the effect.
[[mttr]]
==== Better Mean Time to Recover (MTTR)
diff --git a/src/main/asciidoc/_chapters/developer.adoc b/src/main/asciidoc/_chapters/developer.adoc
index 9e4e2b5..38e4ab6 100644
--- a/src/main/asciidoc/_chapters/developer.adoc
+++ b/src/main/asciidoc/_chapters/developer.adoc
@@ -35,7 +35,7 @@ Being familiar with these guidelines will help the HBase committers to use your
Apache HBase gets better only when people contribute! If you are looking to contribute to Apache HBase, look for link:https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)[issues in JIRA tagged with the label 'beginner'].
These are issues HBase contributors have deemed worthy but not of immediate priority and a good way to ramp on HBase internals.
-See link:http://search-hadoop.com/m/DHED43re96[What label
+See link:https://lists.apache.org/thread.html/b122265f4e4054cf08f8cd38609fb06af72f398c44f9086b05ef4e21%401407246237%40%3Cdev.hbase.apache.org%3E[What label
is used for issues that are good on ramps for new contributors?] from the dev mailing list for background.
Before you get started submitting code to HBase, please refer to <<developing,developing>>.
@@ -866,7 +866,7 @@ requirements of the ASF policy on releases.
____
Regards the latter, run `mvn apache-rat:check` to verify all files are suitably licensed.
-See link:http://search-hadoop.com/m/DHED4dhFaU[HBase, mail # dev - On recent discussion clarifying ASF release policy]
+See link:https://mail-archives.apache.org/mod_mbox/hbase-dev/201406.mbox/%3CCA%2BRK%3D_B8EP0JMFV%2Bdt-k1g%3DBmedzyq2z1GSqrnMMiH6%3DcdoiAA%40mail.gmail.com%3E[HBase, mail # dev - On recent discussion clarifying ASF release policy]
for how we arrived at this process.
[[documentation]]
@@ -2144,10 +2144,8 @@ We've established the practice of committing to master and then cherry picking b
When there is a minor conflict we can fix it up and just proceed with the commit.
The resulting commit retains the original author.
-When the amending author is different from the original committer, add notice of this at the end of the commit message as: `Amending-Author: Author
- <committer&apache>` See discussion at link:http://search-hadoop.com/m/DHED4wHGYS[HBase, mail # dev
- - [DISCUSSION] Best practice when amending commits cherry picked
- from master to branch].
+When the amending author is different from the original committer, add notice of this at the end of the commit message as:
+`Amending-Author: Author <committer&apache>` See discussion at link:https://lists.apache.org/thread.html/7f514da8b24785a4a64b9f023692ce1b345eba215e1f622820551ca1%401401821274%40%3Cdev.hbase.apache.org%3E[HBase, mail # dev - [DISCUSSION] Best practice when amending commits cherry picked from master to branch].
[[committer.tests]]
====== Committers are responsible for making sure commits do not break the build or tests
@@ -2159,7 +2157,7 @@ A committer should.
[[git.patch.flow]]
====== Patching Etiquette
-In the thread link:http://search-hadoop.com/m/DHED4EiwOz[HBase, mail # dev - ANNOUNCEMENT: Git Migration In Progress (WAS =>
+In the thread link:https://lists.apache.org/thread.html/186fcd5eb71973a7b282ecdba41606d3d221efd505d533bb729e1fad%401400648690%40%3Cdev.hbase.apache.org%3E[HBase, mail # dev - ANNOUNCEMENT: Git Migration In Progress (WAS =>
Re: Git Migration)], it was agreed on the following patch flow
. Develop and commit the patch against master first.
@@ -2181,7 +2179,7 @@ However any substantive discussion (as with any off-list project-related discuss
==== Do not edit JIRA comments
-Misspellings and/or bad grammar is preferable to the disruption a JIRA comment edit causes: See the discussion at link:http://search-hadoop.com/?q=%5BReopened%5D+%28HBASE-451%29+Remove+HTableDescriptor+from+HRegionInfo&fc_project=HBase[Re:(HBASE-451) Remove HTableDescriptor from HRegionInfo]
+Misspellings and/or bad grammar is preferable to the disruption a JIRA comment edit causes.
[[hbase.archetypes.development]]
=== Development of HBase-related Maven archetypes
diff --git a/src/main/asciidoc/_chapters/ops_mgt.adoc b/src/main/asciidoc/_chapters/ops_mgt.adoc
index 5bd60c6..6f60a42 100644
--- a/src/main/asciidoc/_chapters/ops_mgt.adoc
+++ b/src/main/asciidoc/_chapters/ops_mgt.adoc
@@ -2368,7 +2368,6 @@ Physical data size on disk is distinct from logical size of your data and is aff
See <<regions.arch,regions.arch>>.
* Decreased by <<compression,compression>> and data block encoding, depending on data.
- See also link:http://search-hadoop.com/m/lL12B1PFVhp1[this thread].
You might want to test what compression and encoding (if any) make sense for your data.
* Increased by size of region server <<wal,wal>> (usually fixed and negligible - less than half of RS memory size, per RS).
* Increased by HDFS replication - usually x3.
diff --git a/src/main/asciidoc/_chapters/performance.adoc b/src/main/asciidoc/_chapters/performance.adoc
index cec5c5a..c2788d1 100644
--- a/src/main/asciidoc/_chapters/performance.adoc
+++ b/src/main/asciidoc/_chapters/performance.adoc
@@ -572,7 +572,6 @@ See <<precreate.regions>>, as well as <<perf.configurations>>
== Reading from HBase
The mailing list can help if you are having performance issues.
-For example, here is a good general thread on what to look at addressing read-time issues: link:http://search-hadoop.com/m/qOo2yyHtCC1[HBase Random Read latency > 100ms]
[[perf.hbase.client.caching]]
=== Scan Caching
@@ -804,7 +803,7 @@ See the link:https://issues.apache.org/jira/browse/HDFS-1599[Umbrella Jira Ticke
Since Hadoop 1.0.0 (also 0.22.1, 0.23.1, CDH3u3 and HDP 1.0) via link:https://issues.apache.org/jira/browse/HDFS-2246[HDFS-2246], it is possible for the DFSClient to take a "short circuit" and read directly from the disk instead of going through the DataNode when the data is local.
What this means for HBase is that the RegionServers can read directly off their machine's disks instead of having to open a socket to talk to the DataNode, the former being generally much faster.
See JD's link:http://files.meetup.com/1350427/hug_ebay_jdcryans.pdf[Performance Talk].
-Also see link:http://search-hadoop.com/m/zV6dKrLCVh1[HBase, mail # dev - read short circuit] thread for more discussion around short circuit reads.
+Also see link:https://lists.apache.org/thread.html/ce2ce3a3bbd20806d0c017b2e7528e78a46ccb87c063831db051949d%401347548325%40%3Cdev.hbase.apache.org%3E[HBase, mail # dev - read short circuit] thread for more discussion around short circuit reads.
To enable "short circuit" reads, it will depend on your version of Hadoop.
The original shortcircuit read patch was much improved upon in Hadoop 2 in link:https://issues.apache.org/jira/browse/HDFS-347[HDFS-347].
diff --git a/src/main/asciidoc/_chapters/schema_design.adoc b/src/main/asciidoc/_chapters/schema_design.adoc
index 3031397..b496c71 100644
--- a/src/main/asciidoc/_chapters/schema_design.adoc
+++ b/src/main/asciidoc/_chapters/schema_design.adoc
@@ -191,7 +191,7 @@ If your rows and column names are large, especially compared to the size of the
One such is the case described by Marc Limotte at the tail of link:https://issues.apache.org/jira/browse/HBASE-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005272#comment-13005272[HBASE-3551] (recommended!). Therein, the indices that are kept on HBase storefiles (<<hfile>>) to facilitate random access may end up occupying large chunks of the HBase allotted RAM because the cell value coordinates are large.
Mark in the above cited comment suggests upping the block size so entries in the store file index happen at a larger interval or modify the table schema so it makes for smaller rows and column names.
Compression will also make for larger indices.
-See the thread link:http://search-hadoop.com/m/hemBv1LiN4Q1/a+question+storefileIndexSize&subj=a+question+storefileIndexSize[a question storefileIndexSize] up on the user mailing list.
+See the thread link:https://lists.apache.org/thread.html/b158eae5d8888d3530be378298bca90c17f80982fdcdfa01d0844c3d%401306240189%40%3Cuser.hbase.apache.org%3E[a question storefileIndexSize] up on the user mailing list.
Most of the time small inefficiencies don't matter all that much. Unfortunately, this is a case where they do.
Whatever patterns are selected for ColumnFamilies, attributes, and rowkeys they could be repeated several billion times in your data.
@@ -582,7 +582,7 @@ However, HBase scales better at larger data volumes, so this is a feature trade-
Pay attention to <<performance>> when implementing any of these approaches.
-Additionally, see the David Butler response in this dist-list thread link:http://search-hadoop.com/m/nvbiBp2TDP/Stargate%252Bhbase&subj=Stargate+hbase[HBase, mail # user - Stargate+hbase]
+Additionally, see the David Butler response in this dist-list thread link:https://lists.apache.org/thread.html/b0ca33407f010d5b1be67a20d1708e8d8bb1e147770f2cb7182a2e37%401300972712%40%3Cuser.hbase.apache.org%3E[HBase, mail # user - Stargate+hbase]
[[secondary.indexes.filter]]
=== Filter Query
diff --git a/src/main/asciidoc/_chapters/troubleshooting.adoc b/src/main/asciidoc/_chapters/troubleshooting.adoc
index 8ab5ed3..c60054f 100644
--- a/src/main/asciidoc/_chapters/troubleshooting.adoc
+++ b/src/main/asciidoc/_chapters/troubleshooting.adoc
@@ -32,7 +32,7 @@
Always start with the master log (TODO: Which lines?). Normally it's just printing the same lines over and over again.
If not, then there's an issue.
-Google or link:http://search-hadoop.com[search-hadoop.com] should return some hits for those exceptions you're seeing.
+Google should return some hits for those exceptions you're seeing.
An error rarely comes alone in Apache HBase, usually when something gets screwed up what will follow may be hundreds of exceptions and stack traces coming from all over the place.
The best way to approach this type of problem is to walk the log up to where it all began, for example one trick with RegionServers is that they will print some metrics when aborting so grepping for _Dump_ should get you around the start of the problem.
@@ -221,12 +221,6 @@ For more information on GC pauses, see the link:http://www.cloudera.com/blog/201
[[trouble.resources]]
== Resources
-[[trouble.resources.searchhadoop]]
-=== search-hadoop.com
-
-link:http://search-hadoop.com[search-hadoop.com] indexes all the mailing lists and is great for historical searches.
-Search here first when you have an issue as its more than likely someone has already had your problem.
-
[[trouble.resources.lists]]
=== Mailing Lists
@@ -235,7 +229,6 @@ The 'dev' mailing list is aimed at the community of developers actually building
Before going to the mailing list, make sure your question has not already been answered by searching the mailing list
archives first. For those who prefer to communicate in Chinese, they can use the 'user-zh' mailing list instead of the
'user' list.
-Use <<trouble.resources.searchhadoop>>.
Take some time crafting your question.
See link:http://www.mikeash.com/getting_answers.html[Getting Answers] for ideas on crafting good questions.
A quality question that includes all context and exhibits evidence the author has tried to find answers in the manual and out on lists is more likely to get a prompt response.
@@ -616,8 +609,6 @@ The upside is that more data is packed into the same region, but performance is
And smaller StoreFiles become targets for compaction.
Without compression the files are much bigger and don't need as much compaction, however this is at the expense of I/O.
-For additional information, see this thread on link:http://search-hadoop.com/m/WUnLM6ojHm1/Long+client+pauses+with+compression&subj=Long+client+pauses+with+compression[Long client pauses with compression].
-
[[trouble.client.security.rpc.krb]]
=== Secure Client Connect ([Caused by GSSException: No valid credentials provided...])
@@ -670,7 +661,7 @@ The utility <<trouble.tools.builtin.zkcli>> may help investigate ZooKeeper issue
[[trouble.client.oome.directmemory.leak]]
=== Client running out of memory though heap size seems to be stable (but the off-heap/direct heap keeps growing)
-You are likely running into the issue that is described and worked through in the mail thread link:http://search-hadoop.com/m/ubhrX8KvcH/Suspected+memory+leak&subj=Re+Suspected+memory+leak[HBase, mail # user - Suspected memory leak] and continued over in link:http://search-hadoop.com/m/p2Agc1Zy7Va/MaxDirectMemorySize+Was%253A+Suspected+memory+leak&subj=Re+FeedbackRe+Suspected+memory+leak[HBase, mail # dev - FeedbackRe: Suspected memory leak].
+You are likely running into the issue that is described and worked through in the mail thread link:https://lists.apache.org/thread.html/d12bbe56be95cf68478d1528263042730670ff39159a01eaf06d8bc8%401322622090%40%3Cuser.hbase.apache.org%3E[HBase, mail # user - Suspected memory leak] and continued over in link:https://lists.apache.org/thread.html/621dde35479215f0b07b23af93b8fac52ff4729949b5c9af18e3a85b%401322971078%40%3Cuser.hbase.apache.org%3E[HBase, mail # dev - FeedbackRe: Suspected memory leak].
A workaround is passing your client-side JVM a reasonable value for `-XX:MaxDirectMemorySize`.
By default, the `MaxDirectMemorySize` is equal to your `-Xmx` max heapsize setting (if `-Xmx` is set). Try setting it to something smaller (for example, one user had success setting it to `1g` when they had a client-side heap of `12g`). If you set it too small, it will bring on `FullGCs` so keep it a bit hefty.
You want to make this setting client-side only especially if you are running the new experimental server-side off-heap cache since this feature depends on being able to use big direct buffers (You may have to keep separate client-side and server-side config dirs).
@@ -1215,12 +1206,11 @@ Use the internal EC2 host names when configuring the ZooKeeper quorum peer list.
=== Instability on Amazon EC2
Questions on HBase and Amazon EC2 come up frequently on the HBase dist-list.
-Search for old threads using link:http://search-hadoop.com/[Search Hadoop]
[[trouble.ec2.connection]]
=== Remote Java Connection into EC2 Cluster Not Working
-See Andrew's answer here, up on the user list: link:http://search-hadoop.com/m/sPdqNFAwyg2[Remote Java client connection into EC2 instance].
+See Andrew's answer here, up on the user list: link:https://lists.apache.org/thread.html/666bfa863bc2eb2ec7bbe5ecfbee345e0cbf1d58aaa6c1636dfcb527%401269010842%40%3Cuser.hbase.apache.org%3E[Remote Java client connection into EC2 instance].
[[trouble.versions]]
== HBase and Hadoop version issues