hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17874) Limiting of read request response size based on block size may go wrong when blocks are read from onheap or off heap bucket cache
Date Tue, 02 May 2017 10:04:04 GMT

    [ https://issues.apache.org/jira/browse/HBASE-17874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992666#comment-15992666
] 

Hadoop QA commented on HBASE-17874:
-----------------------------------

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 24s {color} | {color:blue}
Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 0s {color} |
{color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s {color} | {color:green}
The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s {color} | {color:red}
The patch doesn't appear to include any new or modified tests. Please justify why no new tests
are needed for this patch. Also please list what manual steps were performed to verify this
patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 26s {color}
| {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 19s {color} |
{color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 28s {color}
| {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 26s {color}
| {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 28s {color} |
{color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 56s {color} |
{color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 32s {color}
| {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 24s {color} |
{color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 24s {color} | {color:green}
the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 32s {color}
| {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 29s {color}
| {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s {color}
| {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 60m 46s {color}
| {color:green} Patch does not cause any errors with Hadoop 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5
2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 2s {color} |
{color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 58s {color} |
{color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 115m 52s {color} | {color:red}
hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m 45s {color}
| {color:green} The patch does not generate ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 205m 24s {color} | {color:black}
{color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestAcidGuarantees |
| Timed out junit tests | org.apache.hadoop.hbase.snapshot.TestMobSecureExportSnapshot |
|   | org.apache.hadoop.hbase.snapshot.TestMobExportSnapshot |
|   | org.apache.hadoop.hbase.snapshot.TestMobRestoreFlushSnapshotFromClient |
|   | org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient |
|   | org.apache.hadoop.hbase.snapshot.TestFlushSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12865882/HBASE-17874.patch
|
| JIRA Issue | HBASE-17874 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  hbaseanti  checkstyle
 compile  |
| uname | Linux bbe8cfc7d2db 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 UTC 2016 x86_64 x86_64
x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / c8a7e80 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| unit | https://builds.apache.org/job/PreCommit-HBASE-Build/6656/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |  https://builds.apache.org/job/PreCommit-HBASE-Build/6656/artifact/patchprocess/patch-unit-hbase-server.txt
|
|  Test Results | https://builds.apache.org/job/PreCommit-HBASE-Build/6656/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/6656/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> Limiting of read request response size based on block size may go wrong when blocks are
read from onheap or off heap bucket cache
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-17874
>                 URL: https://issues.apache.org/jira/browse/HBASE-17874
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>            Priority: Blocker
>             Fix For: 2.0.0
>
>         Attachments: HBASE-17874.patch
>
>
> HBASE-14978 added this size limiting so as to make sure the multi read requests do not
retain two many blocks. This works well when the blocks are obtained from any where other
than memory mode BucketCache. In case of on heap or off heap Bucket Cache, the entire cache
area is split into N ByteBuffers each of size 4 MB. When we hit a block in this cache, we
no longer do copy data into temp array. We use the same shared memory (BB).  Its  capacity
is 4 MB.
> The block size accounting logic is RSRpcServices is like below
> {code}
>  if (c instanceof ByteBufferCell) {
>           ByteBufferCell bbCell = (ByteBufferCell) c;
>           ByteBuffer bb = bbCell.getValueByteBuffer();
>           if (bb != lastBlock) {
>             context.incrementResponseBlockSize(bb.capacity());
>             lastBlock = bb;
>           }
>         } else {
>           // We're using the last block being the same as the current block as
>           // a proxy for pointing to a new block. This won't be exact.
>           // If there are multiple gets that bounce back and forth
>           // Then it's possible that this will over count the size of
>           // referenced blocks. However it's better to over count and
>           // use two rpcs than to OOME the regionserver.
>           byte[] valueArray = c.getValueArray();
>           if (valueArray != lastBlock) {
>             context.incrementResponseBlockSize(valueArray.length);
>             lastBlock = valueArray;
>           }
>         }
> 		{code}
> We take the BBCell's value buffer and takes its capacity. The cell is backed by the same
BB that backs the HFileBlock. When the HFileBlock is created from the BC, we do as below duplicating
and proper positioning and limiting the BB
> {code}
>  ByteBuffer bb = buffers[i].duplicate();
>       if (i == startBuffer) {
>         cnt = bufferSize - startBufferOffset;
>         if (cnt > len) cnt = len;
>         bb.limit(startBufferOffset + cnt).position(startBufferOffset);
> 		{code}
> Still this BB's capacity is 4 MB.
> This will make the size limit breach to happen too soon. What we expect is block size
defaults to 64 KB and so we here by allow cells from different blocks to appear in response.
We have a way to check whether we move from one block to next.
> {code}
> if (bb != lastBlock) {
> ...
>             lastBlock = bb;
> }
> {code}
> But already just by considering the 1st cell, we added 4 MB size!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message