[
https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15175560#comment-15175560
]
Ashish Singhi commented on HBASE-9393:
--------------------------------------
bq. Are the characteristics of stream something we can determine in a static
initializer from configs, perhaps by instantiating a dummy version?
No we cannot do that way. I checked the code and the same is stated in the
javadoc
{noformat}
/** Two stream handles, one with and one without FS-level checksum.
* HDFS checksum setting is on FS level, not single read level, so you have
to keep two
* FS objects and two handles open to interleave different reads freely,
which is very sad.
* This is what we do:
* 1) First, we need to read the trailer of HFile to determine checksum
parameters.
* We always use FS checksum to do that, so ctor opens {@link #stream}.
* 2.1) After that, if HBase checksum is not used, we'd just always use
{@link #stream};
* 2.2) If HBase checksum can be used, we'll open {@link #streamNoFsChecksum},
* and close {@link #stream}. User MUST call prepareForBlockReader for that
to happen;
* if they don't, (2.1) will be the default.
* 3) The users can call {@link #shouldUseHBaseChecksum()}, and pass its
result to
* {@link #getStream(boolean)} to get stream (if Java had out/pointer params
we could
* return both in one call). This stream is guaranteed to be set.
* 4) The first time HBase checksum fails, one would call {@link
#fallbackToFsChecksum(int)}.
* That will take lock, and open {@link #stream}. While this is going on,
others will
* continue to use the old stream; if they also want to fall back, they'll
also call
* {@link #fallbackToFsChecksum(int)}, and block until {@link #stream} is set.
* 5) After some number of checksumOk() calls, we will go back to using HBase
checksum.
* We will have 2 handles; however we presume checksums fail so rarely that
we don't care.
*/
{noformat}
The value of hbase checksum and stream will be used cannot be determined in a
static initializer. I think unbuffer method type should be a instance variable
and cannot be shared.
> Hbase does not closing a closed socket resulting in many CLOSE_WAIT
> --------------------------------------------------------------------
>
> Key: HBASE-9393
> URL: https://issues.apache.org/jira/browse/HBASE-9393
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.94.2, 0.98.0
> Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node,
> 7279 regions
> Reporter: Avi Zrachya
> Assignee: Ashish Singhi
> Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-9393.patch, HBASE-9393.v1.patch,
> HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v12.patch,
> HBASE-9393.v13.patch, HBASE-9393.v2.patch, HBASE-9393.v3.patch,
> HBASE-9393.v4.patch, HBASE-9393.v5.patch, HBASE-9393.v5.patch,
> HBASE-9393.v5.patch, HBASE-9393.v6.patch, HBASE-9393.v6.patch,
> HBASE-9393.v6.patch, HBASE-9393.v7.patch, HBASE-9393.v8.patch,
> HBASE-9393.v9.patch
>
>
> HBase dose not close a dead connection with the datanode.
> This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect
> to the datanode because too many mapped sockets from one host to another on
> the same port.
> The example below is with low CLOSE_WAIT count because we had to restart
> hbase to solve the porblem, later in time it will incease to 60-100K sockets
> on CLOSE_WAIT
> [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l
> 13156
> [root@hd2-region3 ~]# ps -ef |grep 21592
> root 17255 17219 0 12:26 pts/0 00:00:00 grep 21592
> hbase 21592 1 17 Aug29 ? 03:29:06
> /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m
> -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
> -Dhbase.log.dir=/var/log/hbase
> -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
