[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14311886#comment-14311886 ] zhangduo commented on HBASE-12295: -- Oh, here it is. I would say this is the most important thing if we want to avoid copying. A simple way is using phantom reference, but the disadvantage is also evident, we can not trigger a gc that only scan BucketCacheEntries when BucketCache is full(Actually I only know that System.gc() can trigger a FullGC on hotspot JVM). Another way is maintaining reference counting by ourselves. But this is also hard since we even want to use the BB that fetched from BucketCache in RpcServer. There are too many places we need to decrease reference count because we can drop the BB in many ways(rpc send message over, scanner skip, exception...). What do you guys think? Thanks~ > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14315670#comment-14315670 ] ramkrishna.s.vasudevan commented on HBASE-12295: bq.Another way is maintaining reference counting by ourselves. But this is also hard since we even want to use the BB that fetched from BucketCache in RpcServer Thanks for the ping on this issue. Just seeing that. We are planning to go with ref counting way. As you said to account for the places where all it should be decreased and incremented is quite challenging. Currently the block being referenced is just GC'ed once a new block is loaded. We have tried out a code for this (like POC - may need some clean up ) and verify the correctness for all cases. But it seems to work. We have tested for positive cases. But not for much of the exception cases. We are in the process of reviewing it and improving it. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589720#comment-14589720 ] ramkrishna.s.vasudevan commented on HBASE-12295: Updated patch available in RB. The callback approach is also included in the patch. The callback approach can be a seperate patch too - I think Anoop is planning to upload it seperately. If needed we can commit that seperately. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590051#comment-14590051 ] stack commented on HBASE-12295: --- Chatted w/ [~ram_krish] and [~anoopsamjohn] about cell-based vs scan-based approach doing refcounting. They argued cell-based would involve a finer level of accounting and that it will have to be done in many locations -- e.g. check return from filters -- makes this approach untenable. Another strong objection was that the assumption that we backing BB location zero was start of a block is actually wrong (a block will be made of many fixed sized BBs from bucketcache... location zero could be start of any one of these bucketcache BBs). So, RPC call-backs across the great 'call' divide at the end of a session with the callback going all the ways down the scan stack and into the HFileBlock for it to do ref counting is the way to go. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590079#comment-14590079 ] Anoop Sam John commented on HBASE-12295: Thanks Stack for the discussion. I have raised HBASE-13926 to give a patch for this RpcCallback based change alone.That will make this jira patch to concentrate only on the bucket cache ref counting area. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14597409#comment-14597409
]
Hadoop QA commented on HBASE-12295:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12741247/HBASE-12295_9.patch
against master branch at commit 6a537eb8545c7dd6c01c0d911ad12e789eeab3ae.
ATTACHMENT ID: 12741247
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 45 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1919 checkstyle errors (more than the master's current 1906 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ * read data from such cache, we will make a cell referring to the same
memory and will avoid any copy.
+if (blockCache != null && block != null && block.getMemoryType() !=
MemoryType.NON_SHARED_MEMORY) {
+ ret = new SharedMemorySizeCachedNoTagsKeyValue(blockBuffer.array(),
blockBuffer.arrayOffset()
+// those cells are referring to a shared memory area which if evicted by
the BucketCache would lead
+// readers using this block are aware of this fact and do the necessary
action to prevent eviction
+ public Result internalGet(Get get, boolean withCoprocessor,
ListRegionScannerCloseCallBack closeCallBack,
+// An RpcCallBack that creates a list of scanners that needs to perform
callBack operation on completion of multiGets
+ // HBaseAdmin only waits for regions to appear in hbase:meta we should
wait until they are assigned
+ public void testGetsWithMultiColumnsAndExplicitTracker() throws IOException,
InterruptedException {
+private void slowdownCode(final
ObserverContext e, boolean isGet) {
{color:red}-1 site{color}. The patch appears to cause mvn post-site goal
to fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14527//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14527//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14527//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14527//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf,
> HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616633#comment-14616633
]
Hadoop QA commented on HBASE-12295:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12743926/HBASE-12295_10.patch
against master branch at commit 7acb061e63614ad957da654f920f54ac7a02edd6.
ATTACHMENT ID: 12743926
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 41 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1908 checkstyle errors (more than the master's current 1898 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ ret = new
SharedMemorySizeCachedNoTagsKeyValue(blockBuffer.array(),
blockBuffer.arrayOffset()
+// those cells are referring to a shared memory area which if evicted by
the BucketCache would lead
+// readers using this block are aware of this fact and do the necessary
action to prevent eviction
+// An RpcCallBack that creates a list of scanners that needs to perform
callBack operation on completion of multiGets
+return Result.create(results, get.isCheckExistenceOnly() ?
!results.isEmpty() : null, stale);
+ // HBaseAdmin only waits for regions to appear in hbase:meta we should
wait until they are assigned
+ public void testGetsWithMultiColumnsAndExplicitTracker() throws IOException,
InterruptedException {
+private void slowdownCode(final
ObserverContext e, boolean isGet) {
+// call return twice because for the isCache cased the counter would
have got incremented twice
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14690//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14690//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14690//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14690//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_2.patch, HBASE-12295_4.patch,
> HBASE-12295_4.pdf, HBASE-12295_5.pdf, HBASE-12295_9.patch,
> HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617158#comment-14617158 ] ramkrishna.s.vasudevan commented on HBASE-12295: Will correct the long lines in my next revision based on the comments from RB. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_2.patch, HBASE-12295_4.patch, > HBASE-12295_4.pdf, HBASE-12295_5.pdf, HBASE-12295_9.patch, > HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624575#comment-14624575
]
Hadoop QA commented on HBASE-12295:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12745012/HBASE-12295_12.patch
against master branch at commit 5e708746b8d301c2fb22a85b8756129147012374.
ATTACHMENT ID: 12745012
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 49 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 1
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+return Result.create(results, get.isCheckExistenceOnly() ?
!results.isEmpty() : null, stale);
+ // HBaseAdmin only waits for regions to appear in hbase:meta we should
wait until they are assigned
+// call return twice because for the isCache cased the counter would
have got incremented twice
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14755//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14755//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14755//artifact/patchprocess/checkstyle-aggregate.html
Javadoc warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14755//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14755//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_2.patch,
> HBASE-12295_4.patch, HBASE-12295_4.pdf, HBASE-12295_5.pdf,
> HBASE-12295_9.patch, HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627551#comment-14627551 ] stack commented on HBASE-12295: --- Out of interest, server-side, how many Interfaces and abstract classes might a Cell implementation be implementing now? Nit: SharedMemoryBackedCell should be SharedMemoryCell ? I like your removal of setters from HFileContext Do you want to remove this: //Empty constructor. Go with setters public HFileContext() The below comment is a little soft: "121 * Called when the scanner using the block decides to safely decrement 122* the reference count of the block since the block is no longer in use." Should it be something like YOU MUST RETURN BLOCKS TO BC WHEN DONE OR ELSE Should Type be MemoryType enum? (I think you or Anoop suggested this and it a good idea).. would match the getMemoryType method in Cacheable. I haven't poke aorund but would it make sense passing Cacheable here: T deserialize(ByteBuffer b, boolean reuse, Type memType) throws IOException; Maybe not. Just a thought. Skimmed the rest. Let me come back to this again. Is it up in RB? I think this stuff is starting to come together nicely. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_2.patch, > HBASE-12295_4.patch, HBASE-12295_4.pdf, HBASE-12295_5.pdf, > HBASE-12295_9.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627559#comment-14627559 ] ramkrishna.s.vasudevan commented on HBASE-12295: bq.Let me come back to this again. Is it up in RB? Ya. The patch is in RB. bq.T deserialize(ByteBuffer b, boolean reuse, Type memType) throws IOException; This CacheableDeserializer is the one creating the Cacheable. So we cannot pass a Cacheable there I think. bq.Should Type be MemoryType enum? We can make it MemoryType. bq.Out of interest, server-side, how many Interfaces and abstract classes might a Cell implementation be implementing now? bq.Nit: SharedMemoryBackedCell should be SharedMemoryCell ? Okie. Keyvalue, NoTagsKeyValue, SharedMemoryCell, the different fake keys, Prefix Tree cells, the DBE cells. The last two will have two variants one with byte[] backed and other with BB backed. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_2.patch, > HBASE-12295_4.patch, HBASE-12295_4.pdf, HBASE-12295_5.pdf, > HBASE-12295_9.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627586#comment-14627586 ] Anoop Sam John commented on HBASE-12295: Just adding to what Ram said abt diff Cell impl Write path --- KeyValue and NoTagsKeyValue Read path -- SizeCachedKeyValue, SizeCachedNoTagsKeyValue OffheapCell, OffheapNoTagsCell (this will be having size cached and it will be extending ByteBufferedCell and also will be marked as Shared memory using the new interface) DBE was/is having an impl already (ClonedSeekerState) We will add one more counterpart for this which will be offheap backed - We need a rename. ClonedSeekerState does not look like a Cell at all Prefix tree was/is having an impl already (ClonedPrefixCell) - We will add one more counterpart for this which will be offheap backed - We need a rename? also read path will have KeyOnlyKeyValue stuff as well as the FakeCell impls for FirstOnROw, LastOnRow etc. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_2.patch, > HBASE-12295_4.patch, HBASE-12295_4.pdf, HBASE-12295_5.pdf, > HBASE-12295_9.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628058#comment-14628058
]
Hadoop QA commented on HBASE-12295:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12745431/HBASE-12295_14.patch
against master branch at commit a63e3ac83ffb91948f464e4f62111d29adc02812.
ATTACHMENT ID: 12745431
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 49 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14783//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14783//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14783//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14783//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch,
> HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf,
> HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628061#comment-14628061 ] stack commented on HBASE-12295: --- Can we cut down the number of variants? For example, if serverside-only, can Interfaces include hasTags method rather than have an Interface for tags and another for no tags? New issue? Thanks lads. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628237#comment-14628237 ] Anoop Sam John commented on HBASE-12295: The new method hasTags to go in where? In read path we will deal with Cell type and we can add this to Cell interface. May be we can avoid 2 impls one with out tags and one with. Have a state (boolean) in Cell impl. We have SizeCachedKeyValue abd SizeCachedNoTagsKeyValue now. May be we will only have SizeCachedKeyValue and it will have a boolean state whether it has tags or not. The getTagsLength() can check this state ad return 0 or decode tags length. We have extra 6 bytes per cell in this SizeCachedKeyValue now. Make it 7 is ok? > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631437#comment-14631437
]
Hadoop QA commented on HBASE-12295:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12745808/HBASE-12295_16.patch
against master branch at commit 834f87b23de533783ba5f5b858327a6164f17f55.
ATTACHMENT ID: 12745808
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 49 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1873 checkstyle errors (more than the master's current 1871 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestEndToEndSplitTransaction
org.apache.hadoop.hbase.regionserver.TestRegionReplicas
org.apache.hadoop.hbase.master.TestDistributedLogSplitting
{color:red}-1 core zombie tests{color}. There are 4 zombie test(s):
at
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.testScanWithCompactionInternals(TestBlockEvictionFromClient.java:837)
at
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient.testScanWithCompaction(TestBlockEvictionFromClient.java:799)
at
org.apache.hadoop.hbase.client.TestReplicasClient.testSmallScanWithReplicas(TestReplicasClient.java:606)
at
org.apache.hadoop.hbase.client.TestRestoreSnapshotFromClient.testRestoreSnapshot(TestRestoreSnapshotFromClient.java:162)
at
org.apache.hadoop.hbase.client.TestMetaWithReplicas.testMetaAddressChange(TestMetaWithReplicas.java:392)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14816//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14816//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14816//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14816//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch,
> HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_2.patch,
> HBASE-12295_4.patch, HBASE-12295_4.pdf, HBASE-12295_5.pdf,
> HBASE-12295_9.patch, HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631516#comment-14631516 ] ramkrishna.s.vasudevan commented on HBASE-12295: TestRegionReplica is failing for me. Will correct that. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631568#comment-14631568
]
ramkrishna.s.vasudevan commented on HBASE-12295:
{code}
Running org.apache.hadoop.hbase.client.TestBlockEvictionFromClient
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 59.38 sec - in
org.apache.hadoop.hbase.client.TestBlockEvictionFromClient
Results :
{code}
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch,
> HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch,
> HBASE-12295_17.patch, HBASE-12295_2.patch, HBASE-12295_4.patch,
> HBASE-12295_4.pdf, HBASE-12295_5.pdf, HBASE-12295_9.patch,
> HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631724#comment-14631724
]
Hadoop QA commented on HBASE-12295:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12745832/HBASE-12295_16.patch
against master branch at commit 834f87b23de533783ba5f5b858327a6164f17f55.
ATTACHMENT ID: 12745832
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 49 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestRegionReplicas
org.apache.hadoop.hbase.regionserver.TestEndToEndSplitTransaction
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.flume.channel.kafka.TestKafkaChannel.testSuccessInterleave(TestKafkaChannel.java:86)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14817//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14817//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14817//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14817//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch,
> HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch,
> HBASE-12295_17.patch, HBASE-12295_2.patch, HBASE-12295_4.patch,
> HBASE-12295_4.pdf, HBASE-12295_5.pdf, HBASE-12295_9.patch,
> HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631782#comment-14631782
]
Hadoop QA commented on HBASE-12295:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12745836/HBASE-12295_17.patch
against master branch at commit 834f87b23de533783ba5f5b858327a6164f17f55.
ATTACHMENT ID: 12745836
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 49 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14818//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14818//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14818//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14818//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch,
> HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch,
> HBASE-12295_17.patch, HBASE-12295_2.patch, HBASE-12295_4.patch,
> HBASE-12295_4.pdf, HBASE-12295_5.pdf, HBASE-12295_9.patch,
> HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631844#comment-14631844 ] stack commented on HBASE-12295: --- [~anoop.hbase] Anything to cut down on the combinatorial explosion. bq. In read path we will deal with Cell type and we can add this to Cell interface. Server-side only? "May be we can avoid 2 impls one with out tags and one with. Have a state (boolean) in Cell impl. We have SizeCachedKeyValue abd SizeCachedNoTagsKeyValue now. May be we will only have SizeCachedKeyValue and it will have a boolean state whether it has tags or not. The getTagsLength() can check this state ad return 0 or decode tags length. We have extra 6 bytes per cell in this SizeCachedKeyValue now. Make it 7 is ok IMO" Above seems fine though just one-byte we should profile; stuff might run better if padding -- TBD. More ideal would be the case where if no tags, then no cost but don't know how to do that. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch, > HBASE-12295_17.patch, HBASE-12295_2.patch, HBASE-12295_4.patch, > HBASE-12295_4.pdf, HBASE-12295_5.pdf, HBASE-12295_9.patch, > HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634917#comment-14634917 ] Anoop Sam John commented on HBASE-12295: +1 for latest patch. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch, > HBASE-12295_17.patch, HBASE-12295_18.patch, HBASE-12295_2.patch, > HBASE-12295_21.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14635031#comment-14635031
]
Hadoop QA commented on HBASE-12295:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12746310/HBASE-12295_21.patch
against master branch at commit 3b6db2686380631027975c46b4a73478e299c82f.
ATTACHMENT ID: 12746310
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 53 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1871 checkstyle errors (more than the master's current 1870 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.jboss.arquillian.test.impl.context.SuiteContextImpl.activate(SuiteContextImpl.java:52)
at
org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:72)
at
org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
at
org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14850//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14850//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14850//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14850//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch,
> HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch,
> HBASE-12295_17.patch, HBASE-12295_18.patch, HBASE-12295_2.patch,
> HBASE-12295_21.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf,
> HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14635585#comment-14635585 ] Hudson commented on HBASE-12295: FAILURE: Integrated in HBase-TRUNK #6669 (See [https://builds.apache.org/job/HBase-TRUNK/6669/]) HBASE-12295 Prevent block eviction under us if reads are in progress from (ramkrishna: rev ccb22bd80dfae64ff27f660254afb224dce268f0) * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/bucket/TestByteBufferIOEngine.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestScannerHeartbeatMessages.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockIndex.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CompoundBloomFilter.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderImpl.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHeapMemoryManager.java * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestBlockEvictionFromClient.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/MemcachedBlockCache.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ReversedRegionScannerImpl.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/BucketCache.java * hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/IOEngine.java * hbase-common/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileContextBuilder.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestCacheConfig.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/ByteBufferIOEngine.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CombinedBlockCache.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/CacheTestUtils.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java * hbase-common/src/main/java/org/apache/hadoop/hbase/ShareableMemory.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlock.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlockIndex.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestLruBlockCache.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/BlockCache.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFile.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheableDeserializer.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestCacheOnWrite.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestCachedBlockQueue.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/KeyValueHeap.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/Cacheable.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlock.java * hbase-common/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileContext.java * hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/bucket/TestFileIOEngine.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/FileIOEngine.java > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch, > HBASE-12295_17.patch, HBASE-12295_18.patch, HBASE-12295_2.patch, > HBASE-12295_21.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_final.patch, > HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This messa
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636226#comment-14636226
]
ramkrishna.s.vasudevan commented on HBASE-12295:
The test TestIOFencing runs fine
{code}
T E S T S
---
Running org.apache.hadoop.hbase.TestIOFencing
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 186.111 sec -
in org.apache.hadoop.hbase.TestIOFencing
Results :
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
{code}
I tried on the latest code and it runs fine. Also the same patch when ran in QA
bot it passed. So i think it is flakey and nothing specific to this commit.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch,
> HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch,
> HBASE-12295_17.patch, HBASE-12295_18.patch, HBASE-12295_2.patch,
> HBASE-12295_21.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf,
> HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_final.patch,
> HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638493#comment-14638493 ] Anoop Sam John commented on HBASE-12295: +1 > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch, > HBASE-12295_17.patch, HBASE-12295_18.patch, HBASE-12295_2.patch, > HBASE-12295_21.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_addendum.patch, > HBASE-12295_final.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638713#comment-14638713 ] Hudson commented on HBASE-12295: FAILURE: Integrated in HBase-TRUNK #6675 (See [https://builds.apache.org/job/HBase-TRUNK/6675/]) HBASE-12295 - Addendum for multiGets to add the call back(Ram) (ramkrishna: rev 4ec69ccf3ae8701727299179ac6b5002bbd72c55) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch, > HBASE-12295_17.patch, HBASE-12295_18.patch, HBASE-12295_2.patch, > HBASE-12295_21.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_addendum.patch, > HBASE-12295_final.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14641958#comment-14641958 ] Ashish Singhi commented on HBASE-12295: --- [~ram_krish], this seems to have broke org.apache.hadoop.hbase.coprocessor.TestOpenTableInCoprocessor, do you want to take a look ? > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch, > HBASE-12295_17.patch, HBASE-12295_18.patch, HBASE-12295_2.patch, > HBASE-12295_21.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_addendum.patch, > HBASE-12295_final.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642014#comment-14642014 ] Anoop Sam John commented on HBASE-12295: Yes Ashish. Thanks for digging in. Fix available in HBASE-14156 > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_10.patch, HBASE-12295_12.patch, HBASE-12295_14.patch, > HBASE-12295_15.patch, HBASE-12295_16.patch, HBASE-12295_16.patch, > HBASE-12295_17.patch, HBASE-12295_18.patch, HBASE-12295_2.patch, > HBASE-12295_21.patch, HBASE-12295_4.patch, HBASE-12295_4.pdf, > HBASE-12295_5.pdf, HBASE-12295_9.patch, HBASE-12295_addendum.patch, > HBASE-12295_final.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528311#comment-14528311 ] ramkrishna.s.vasudevan commented on HBASE-12295: Just adding the RB link for reference. We will take this upto completion only after sub jiras of HBASE-11425 are done. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563069#comment-14563069
]
stack commented on HBASE-12295:
---
Thank you for the nice writeup. It helps. It looks great. It is easier
discussing around a doc like this than looking at a ream of code (smile).
returnBlock(BlockCacheKey cacheKey, HFileBlock block)
Do we need to return the block too in the above? Won't the key be enough?
"As mentioned earlier the cellblock creation would ensure that the cells are
copied to an output
stream and thus we are sure that the reference of these cells to the shared
memory area is
removed."
I would say that the creation of the CellBlock in memory is something we would
like to get away from some day. We would like to just put the bytes on the wire
directly. Or, consider that we will want to stream out Cells as they come up
out of the server when we implement a streaming Interface on the server. Just
something to keep in mind.
" To achieve this, we are converting the cells in the result to a Cellblock
buffer (in
Region level itself) and pass it to RpcServer via the Payload of the controller
as opposed to how
it happens currently (currently the cell block is created in RPC layer)."
Hmm... pulling the CellBlock into the Region from the ipc layer? I have thought
that Result should carry CellBlocks This would be an extra copy, right? If
we wanted to get to zero copy, would it be possible if we went this route?
"We have added an overridden API in HRegion which takes RpcController as
parameter. "
HRegion.get(get, RpcController)
Nah. You can't pull an oddball RPC datastructure back into HRegion. Could it be
done in the Result itself?
Ditto here: HRegion.getScanner(scan, RPCController).
Have you seen Jonathan Lawlor's ScanContext? He has added a bunch of accounting
on where scan is at... state, and has scans doing heartbeating, and early
returns. Can you make use of this work of his?
Tell us more about the marking of Cells from L2 with a new Interface and why CP
need special treatment, need Cells copied when read from CP. We have to do this?
{quote}Only the required results are copied.{quote}
This is a good point to make. May be raise it in the design doc higher... A
'benefits' section.
{quote} finalizeScan(boolean finalizeAll). {quote}
Why we need this? Why not close (sorry if I'm being thick).
I don't follow this sentence: "In such a case we don’t evict the block if the
ref count > 0, instead we mark those
blocks with a Boolean."
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563359#comment-14563359 ] ramkrishna.s.vasudevan commented on HBASE-12295: bq.returnBlock(BlockCacheKey cacheKey, HFileBlock block) bq.Do we need to return the block too in the above? Won't the key be enough? Ideally yes. But as per our current impl we have a type of block whether it is from L2 or L1 and hence needed the block there. May be we can only pass the type of the block there? That should be possible. Not a big deal. bq.Or, consider that we will want to stream out Cells as they come up out of the server when we implement a streaming Interface on the server. Okie. When we tried to directly write the cells to the socket as part of the POC things were directly slow. May be a different type of protocol/approach may be needed there. bq.Hmm... pulling the CellBlock into the Region from the ipc layer? I have thought that Result should carry CellBlocks This would be an extra copy, right? If we wanted to get to zero copy, would it be possible if we went this route? Yes, this will be a zero copy. Currently while creating cell block there is no copy we do and directly use the encoder to create it. same here except that it is now in HRegion. Making Result carry it is one option, I think you mean the PB result right? The approach here was to be simple use the existing Payload. When you say Result - will that not be the current way as how we do for non-java clients? bq.Nah. You can't pull an oddball RPC datastructure back into HRegion. Could it be done in the Result itself? Same as above. bq.He has added a bunch of accounting on where scan is at... state, and has scans doing heartbeating, and early returns. Can you make use of this work of his? I had a look at it. Will check once more before commenting back. But in our case we need to handle both scans and gets. Scans have states and gets do not have states as gets operate with in Region. bq.Tell us more about the marking of Cells from L2 with a new Interface and why CP need special treatment, need Cells copied when read from CP. We have to do this? CPs are bit tricky. Take a CP which is trying to implement a postScannerOpen hook by wrapping the original scanner. Now in a non CP approach we have the control on the result and the cellblock creation and we are sure that once the cell block is created we no longer refer to the cells from the hfileblocks. But when you have a CP there is a high chance that those cells are referred for a longer time and the CP tries to use those Cells as its state. In those cases, if we think that the blocks ref count can be decremented just because the results have been fetched, we end up corrupting the states of those CPs. Hence we need to do a copy of the result. bq.finalizeScan(boolean finalizeAll). Though we have completed the implementation, we are still seeing if there is a better way,, but I have done some analysis and I fear that may be very very tricky. I can come up with a write up after some more analysis but overall the problem is that the scanner flow has some optimizaitons where we proactively close some of the scanner from the heap just because they don't return any result (infact we nullify them also). In such cases just calling close will not be enough because already those StoreFileScanners could be closed and we will lose the reference to those scanners. Hence thought of adding an explicit API to do it. And added to that for the scan case the close() call alone won't work because there are going to be set of next() calls for a scan to finish and it makes it better if we clear the references of those cells then and there. And in case of scans the latest block would be needed for the subsequent next() calls as Scans are with States. bq. "In such a case we don’t evict the block if the ref count > 0, instead we mark those blocks with a Boolean." This is a special case. In case of compaction after the files are compacted we know that the compacted files are no longer needed and we forcefully try to evict them from the block cache. But now if there were any parallel scans operating on those files we just cannot evict them. So we use the same ref count mechanism and see if the block can really evicted (even if it is forceful). All such blocks would automatically be evicted once the read operation using that block gets completed. (in the sense on decrementing a 'marked' block to 0 we call evict forcefully). This ensures that the results are not corrupted. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Typ
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563680#comment-14563680 ] stack commented on HBASE-12295: --- bq. May be we can only pass the type of the block there? That should be possible. Not a big deal. You can't figure whether L1 or L2 looking at the key? bq. When we tried to directly write the cells to the socket as part of the POC things were directly slow. We'll have to dig in on why. You'd think w/ less intermediaries that it would be faster. bq. Making Result carry it is one option, I think you mean the PB result right? Ain't sure (smile). I was thinking in both cases. Result would give you a CellScanner... client or server side. Result cuts at a different dimension from CellBlock though, right? You get a Result per Get and per Scan response (could be full row or partial). CellBlock is an RPC primitive. Thought was that CellBlock could go other places in HBase too to save space (encoding/compression): e.g. in hfileblock or backing a Result. bq. The approach here was to be simple use the existing Payload. When you say Result - will that not be the current way as how we do for non-java clients? Understood. But pulling the rpc controller back into HRegion is a little perverse. HRegion should not have any rpc pollution. Also, we already pervert rpc controller to carry the payload across the server/rpc barrier, an unnatural usage. Then, controller itself is not actually doing any 'controlling' of the rpc -- it is just a place holder in rpc that protobuf actually recommends we avoid (i.e. generate own rpc interface rather than use the one protoc generates). bq. Yes, this will be a zero copy. But we are copying Cells into CellBlock in memory and then we put the CellBlock on the wire? Would be nice if we could write the CellBlock directly on the wire (maybe this is not possible). That said, for now at least, the creation of CellBlock is a good place for triggering decrement of backing block reference. bq. Scans have states and gets do not have states as gets operate with in Region. Scans are Gets. If that is not enough, can we mimic scan context in Get? Would that help? Then we could have one means rather than two keeping account. bq. ...and the CP tries to use those Cells as its state. So, as is, we'll make a copy per registered CP? bq. finalizeScan(boolean finalizeAll). You want a delayed close, one that completes only after all outstanding scanners are done? Can we have scanner close set up one of these? So the boolean does what for compacted files? It says, don't evict files that are being read though they have been compacted? (Is this like the finalizeScan case at all? Where you want to do a delayed close until no more references?) One other thought is how you folks thinking of testing this stuff? > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564140#comment-14564140 ] ramkrishna.s.vasudevan commented on HBASE-12295: bq.You can't figure whether L1 or L2 looking at the key? You mean add some different type of keys for the L1 or L2 case? Can check this. bq.We'll have to dig in on why. You'd think w/ less intermediaries that it would be faster. Yes that was the reason. When we were writing every cell to the socket directly things were really slow. bq.But pulling the rpc controller back into HRegion is a little perverse. Okie, we could see if we can make the REsult carry this cellblock. Will check on this once again. bq.(maybe this is not possible). That said, for now at least, the creation of CellBlock is a good place for triggering decrement of backing block reference. Yes. Right. bq. If that is not enough, can we mimic scan context in Get? Will see on this if it is really possible. bq.So, as is, we'll make a copy per registered CP? Yes but only if the scanner returned from the CP hook is not implementing the new interface. But if we allow the REgionScanner itself to use that new interface and the CP tries to use that new API diligently like how close() would be used, then we are safe we don't need to do that copy. Anyway for non-java case we need to do that copy. bq.You want a delayed close, one that completes only after all outstanding scanners are done? Can we have scanner close set up one of these? Ya, I tried out something yesterday. Seems to work. But checking on all the corner cases, the next patch may have this change. However I doubt on how a scan next() can be handled. It needs some explicit way of decrementing the ref count alone. But generally the call to close() would be an logical end to the ongoing read process including decrementing the ref count on the current list of blocks. bq.So the boolean does what for compacted files? It says, don't evict files that are being read though they have been compacted? (Is this like the finalizeScan case at all? Where you want to do a delayed close until no more references?) A kind of. But this would happen purely internally. Nothing like explicitly calling from the compaciton scanners to set this boolean. Just the block block in the Bucket cache itself would know this and do it. bq.One other thought is how you folks thinking of testing this stuff? Ya as a first measure we have written unit tests to test out these scenarios and ensure we are doing the ref counting correctly. We are adding more tests to it so that we cover the basic scenarios. For the cluster testing we are planning to reduce the bucket cache size and ensure we have frequent eviction scenarios and verify whether any of the results are getting corrupted. Any other suggestion you have here? > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564180#comment-14564180 ] stack commented on HBASE-12295: --- bq. You mean add some different type of keys for the L1 or L2 case? Can check this. Yeah. Type or you check L2 and there is no corresponding count associated. It is just odd passing in the actual object when done with it. You going to mark the object as from L2 or something? bq. When we were writing every cell to the socket directly things were really slow. Ok. Would be good to see what is going on at that time. Can do later. bq. ...see if we can make the REsult carry this cellblock. Will check on this once again. Will you want to return many Results in the one go? I'm am wondering if Result operates on a different dimension to what you need. bq. Yes but only if the scanner returned from the CP hook is not implementing the new interface New Interface? I missed that. Let me reread the doc. bq. Ya, I tried out something yesterday. Seems to work. Ok. Good. Better than introducing a new close-like method. Complicated. bq. Just the block block in the Bucket cache itself would know this and do it. Could we not have the special casing here (I don't know what I'm talking about ... this is a totally removed, high-level comment... ignore if nonsense) Sounds good on testing. Where are the refcounts to be kept? In the block key itself? Or in a Map keyed by the block key? Or in the HFileScanner? Or in the HFile reader implementation? What if we had an encoder that could concatenate CellBlocks? Would that help? Cells come up out of HRegion in Results, right? Its like the Result should have a reference to the backing block and when RPC is 'done' with a Result, it calls 'close' or 'done' or 'finally' on the Result and that means the Result and its backing block can be let go. Its like you want to have a 'finally' on Result but you want to call it yourself rather than have the GC do it. For Scan, I think you need to look at the context object that was recently added. It determines when it is time to go back to the client. Again it is returning a Result. When the Result has been copied to the CellBlock, call its 'finally'? For scan you say, "...we return back all the blocks used in the read except the current block (the latest block that was read). The latest block cannot be returned back because it could be used for the scan’s next ‘next()’ call. " Why not just let the current block go? Deprecate its count? It might get evicted before the scanner comes back with a next, but that'd be ok? The block must have been cold? Otherwise, it'll just be in cache next time we come in. For CPs, if Result had a 'finally' or 'release' or 'close' on it, they could let it go when done with it rather than have us do copy? Or, could we have a Result that explicity has all Cells copied into it and another which has reference to backing blocks? We would default passing CPs Results that have had Cells copied into them with all kinds of warning that this is horrid and they need to switch to do reference Results? In non-java cases, is there a barrier like there is in rpc for CellBlocks... so we could do similar for them? Could do the copy for first cut. I think I understand the compaction case. You are setting a flag so that when the refcounts go to zero, instead of leaving the block in the bucketcache, you force it out. Is that it? If so, makes sense. Thanks lads. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564184#comment-14564184 ] Anoop Sam John commented on HBASE-12295: bq.So, as is, we'll make a copy per registered CP? Not really. We will make copy once. Basically the scan/get we have distiguished as 2 path. One in which there is no need for copy and other needs copy. The second case uses the old API itself. Here once we get the cells, we will see whether it is marked using the new Interface, if so we will do copy to a new Cell. And then this new cell is going to be passed to CPs as well as HRS and above layers. Am I making it clear now? > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564194#comment-14564194 ] Anoop Sam John commented on HBASE-12295: bq.Why not just let the current block go? Deprecate its count? It might get evicted before the scanner comes back with a next, but that'd be ok? The block must have been cold? Otherwise, it'll just be in cache next time we come in. Not really we can. Because if we do so, every time next() comes, we have to ask the cache to give me the cached block. This is not happening now. So we would like to avoid this overhead. bq.ts like the Result should have a reference to the backing block and when RPC is 'done' with a Result, it calls 'close' or 'done' or 'finally' on the Result and that means the Result and its backing block can be let go But there can be N results which have the ref to same block(s) no? So it is bit complicated then. Also we did not want the concept of blocks or cache to come to upper layers after the HFileScanner layer. The ref counting is happening within the BC impl. Not even all BCs need this. Say the File based BC, we better copy buckets to a single buffer. This also we try to handle.. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564311#comment-14564311 ] Anoop Sam John commented on HBASE-12295: bq.We'll have to dig in on why. You'd think w/ less intermediaries that it would be faster. It should be the cost at socket layer and we will need N transfers instead of one. This one time transfer was looking better even if we need a temp copy. Regarding knowing whether L1 or L2 looking at key, actually this info of whether L1 or L2 is a state of HFileBlock. We have added this with an enum L1/L2/NOT_CACHED. Based on this type, we decided at the HFileScanner layer (on close) whether to call return on BlockCache. Also within the BlockCache impl, we might need to know the type. This is for CombineBC. If it is L2, then we call the BucketCache return and else call LRU cache return. So if we add the L1/L2 info also to BlockCacheKey, I am not sure whether this looks clean. BlockCacheKey is some thing which we will be creating while fetching the block from BC. While return, we can just pass the info by setting it in BlockCacheKey. It will just act as a carrier then. Or may be we can use HFileBlock object alone in the return API? Using a key we have got an object from a cache and we return *that* object back to the cache. It is always possible to make the BlockCacheKey from HFileBlock. bq. You going to mark the object as from L2 or something Yes. HFileBlock will contain state info whether it is from L1 or L2 or NOT_CACHED one. When it is CombinedBC, HFileReader ask the cache to give block and it returns the HFileBlock. So we are not sure from where it has come L1/L2. So better set it as a state info in HFileBlock carry the cellBlock in Result, am not sure.. At HRegion level, the get() return a Result but the scanner returns a List of Cells. Then in RsRpcServer level, we call in al loop to make those many rows/results as per caching/max size limit. Even if we make it to return a Result in scan area also, it will make overhead of creating smaller sized cellBlock buffer for each of the rows. So finally we will have to deal with more smaller size block buffers. It will be better to collect all rows and then make a single cellBlock at once for the scan case. Making sense? Agree to your point of not passing RPC stuff even to HRegion level. We have to see what else we can do to return this payload. I think I got now what is in your mind on saying finalize/close on Result and handle things that way. Right now, when we get a block from BC, we increase its ref count by 1, means one scanner is working on this. So if we have to do in this suggestion, then whenever we are creating a cell from this block, we have to again increment the ref count. Some thing like java ref counting way. Only Q is Result/Cell is a client side thing and am not sure how we can add server only BlockCache/ HFileBlock... But this would have made max NOT copy to happen.. Thinking more... > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564689#comment-14564689 ] Anoop Sam John commented on HBASE-12295: In CP case also, then we have expectation from user to explicitely call close(). We are copying cell considering the fact that it might get stored and used later (by CP). Those kind of use cases (HIndex for eg:) might not be always the case. So we can say if the CP has such a case then they have to be aware of this SharedMemoryCell and do copy on their own? Just throwing thoughts coming. For non java case, any way we will need a copy. Right now using HBaseZeroCopyByteString we avoid the copy need to make a PBCell from Cell. But all types of ByteString from PB need a byte[] as backing data structure. When the cells are backed by DBB, we have to copy here. So there is not much adv we get. I would say in such a scenario copy the cell at one shot in Region level is better. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564705#comment-14564705 ] ramkrishna.s.vasudevan commented on HBASE-12295: Was not available for some time during the day today. Anyway Anoop had chimed in. bq.Where are the refcounts to be kept? In the block key itself? Or in a Map keyed by the block key? Or in the HFileScanner? Or in the HFile reader implementation? Ref counts purely happens in the L2_CACHE layer alone and the ref count is associated with the bucket entry. None of the above layers know about it. The list of blocks to be used is there in the HFileREader (HfileScanner internally). The current scan case is quite complex and handling the pseudo close call for intermedidate cases seems will have more involved changes - let's see. Scannercontext, I had a look but all cases we have hasMoreValues as true except for NO_MORE_VALUES. I think we just need this information before confirming if we can decrement the blocks ref count. Regarding the result part, your idea is right, but apart from the concerns that Anoop raised as Result is a client side thing, if Result needs to do the 'finally' may be it should be exposed to some more internals of the scans and the scanners? bq.Will you want to return many Results in the one go? I'm am wondering if Result operates on a different dimension to what you need. I think you make that point here. bq.Why not just let the current block go? Deprecate its count? It might get evicted before the scanner comes back with a next, but that'd be ok? The block must have been cold? Otherwise, it'll just be in cache next time we come in Could be done but as Anoop said it has an overhead for then next next() call and logically holding that block is fine - as we really know it is a hot block. If the current next() call would really know that there are no more results to be fetched it would have already ensured that the current block would not be reused. So I feel that maintaining the last block is needed and logically right too. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14566285#comment-14566285 ] stack commented on HBASE-12295: --- [~anoop.hbase] bq. Here once we get the cells, we will see whether it is marked using the new Interface, if so we will do copy to a new Cell. And then this new cell is going to be passed to CPs as well as HRS and above layers. Am I making it clear now? Yes CPs will have means of avoiding copy. Thats good. bq. Because if we do so, every time next() comes, we have to ask the cache to give me the cached block. This is not happening now. So we would like to avoid this overhead. You mean, the scanners are parked at a particular location so when scan comes back in, we just continue? If it makes life easier, maybe we undo this and have each 'next' invocation be a new scan (An old @nicolas liochon issue suggesting we copy an amz db was suggesting this... but some pushback). I understand though now that you want to preserve the old behavior. Makes sense. But if it makes it all more complicated, then we might want to reexamine (scan would be more like a get then?) bq. But there can be N results which have the ref to same block(s) no? So it is bit complicated then. Don't these each have their own ref count? bq. Also we did not want the concept of blocks or cache to come to upper layers after the HFileScanner layer. +1 on this (if my Result suggestion makes us go against this principal, then it is not a good suggestion) > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14566406#comment-14566406 ] Anoop Sam John commented on HBASE-12295: bq.Don't these each have their own ref count? Now in our impl, ref count is incremented per scanner. So it is not like normal java ref count. When we see one HFileBlock's ref count is 2 that means there are 2 active scanners still referring to this. Those refs might be in the read path places like comparators etc and/or by cells created from this block. So if we have to make some thing like cell close() we will maintain the count incremented when a Cell is created also. This creation is at HFileScanner level. Then every cell, when closed has to decrement this count. But the disadv for this wrt perf is we will make the counter incr/decr many times. This has to be an atomic long and so there will be some cost. But more than that , the complications will be in cell filtering area etc. When the Cell is created from Scanner level, we dont know whether this cell will get eliminated. The cell can get ignored at many places (due to version/ttl/acl/visibility/filter etc etc).. All these impl has to handle the close of the cell when it is being ignored. There can be custom filters which is doing this elimination. (by filterCell(Cell) or by filterRowCells(List) ) All these has to handle the close. And filter can transform an incoming cell into another and make that to be used from then on (transformCell(Cell)) Same way CPs also can do this filtering. There is the complication which I was telling. I actually liked that idea so that changes in HRegion level can be avoided.. Then thinking more and more I landed in all these kind of practical issues... Just adding here FYI [~stack] > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568176#comment-14568176 ] stack commented on HBASE-12295: --- bq. ...Regarding knowing whether L1 or L2 looking at key... Do what makes sense. If keeping type in HFileBlock makes more sense, then ok, no problem passing block on close/when done. bq. We have to see what else we can do to return this payload. Yeah, not sure how to encapsulate blockcache blocks while making it so we can delay the copy to cellblock long as possible... as far out as possible in the read path. bq. I think I got now what is in your mind on saying finalize/close on Result and handle things that way. ...I would say this will add more complexity and chances we miss the close. What do you think? Not sure I follow the objection, but ok if you think it might make things more complex. Lets see how we figure getting from blockcache block to cellblock bq. Ref counts purely happens in the L2_CACHE layer alone and the ref count is associated with the bucket entry. None of the above layers know about it That is good. Ignore my suggestions that would go against the above. bq. if Result needs to do the 'finally' may be it should be exposed to some more internals of the scans and the scanners?... Yeah, serverside Result would have to know more about internals so could do release. Seems like Get needs to NOT return Result on serverside ... should be like scan. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569481#comment-14569481 ] Anoop Sam John commented on HBASE-12295: Regarding the complexity in close/finalize on Result/Cell. I think we need to put it in Cell.. Cell is the one available through out the layers. So when a Cell is created at HFileScanner level and its data refers to bucket cache shared memory area, we have to incr the ref count. When cell is closed decr it. So after the usage, some one should call close on Cells. In a normal path assume the cell is getting written in IPC layer, there the call can happen.. All looks ok. The issue is the possible ways via which the cell wont reach that IPC layer and get filtered out. Can be by version expiry, TTL expiry, acl, visibility, filter, cp etc.. All the core places we can make sure to call. But Filter/CP can be custom made also. Even when a Filter converts a Cell using transformCell(Cell) API, we have to make sure the old cell is being closed.. This was the part I was telling .. It looks all complex.. Am I explaining it clearly now? Sorry for not being clear in old comments. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14570334#comment-14570334 ] ramkrishna.s.vasudevan commented on HBASE-12295: Given that we can solve this without using Result we could continue the way we handle with scanners and scanners doing the ref counting part. I would any way think that if we use Result, may be we need not increment every cell coming from that block. Per block used in the result we can increment the count. But doing anything with Result would need to have a Server side result object that may do some extra APIs/methods to handle these return/close stuff. As Stack points out bq.I would say that the creation of the CellBlock in memory is something we would like to get away from some day. If this has to happen then its better we handle things with the Result - but incrementing the ref count for every cell in the block may be we can see if there is another way. For now we are not handling this through Result and handling things using CellBlock and existing scanners. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14572169#comment-14572169 ] ramkrishna.s.vasudevan commented on HBASE-12295: New RB link -https://reviews.apache.org/r/35045/ > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14572232#comment-14572232
]
Hadoop QA commented on HBASE-12295:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12737459/HBASE-12295_1.patch
against master branch at commit bb62d5b2e8db1677568723bb8d0d8ea4fd2c6f46.
ATTACHMENT ID: 12737459
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 53 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 2
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1936 checkstyle errors (more than the master's current 1920 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+cellScanner = IPCUtil.getInstance().createCellScanner(codec,
compressor, bb.array(), 0, bb.limit());
+ * read data from such cache, we will make a cell referring to the same memory
and will avoid any copy.
+ * Cell. This is useful when we want to consume the Cell before even the
block referring to these cells
+ * done with this instance by calling {@link #flipAndReturnBuffer()}. All
this encapsulation violation
+ if (block != null && this.curBlock != null && block.getOffset() ==
this.curBlock.getOffset()) {
+ // Ideally if we can make the scanner to work at this level it is much
easier because this method
+ // surely knows what was fetched from the cache and based on that we
could keep returning the prev
++ " readers. Can not be freed now. Hence will mark this for
evicting at a later point");
+ Triple call(BlockingService service,
MethodDescriptor md, Message param,
+ //((PayloadCarryingRpcController)
controller).setCellScanner(CellUtil.createCellScanner(results));
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestKeyValueHeap
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14279//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14279//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14279//artifact/patchprocess/checkstyle-aggregate.html
Javadoc warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14279//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14279//console
This message is automatically generated.
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574445#comment-14574445 ] ramkrishna.s.vasudevan commented on HBASE-12295: Ping for reviews!!!. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575331#comment-14575331 ] stack commented on HBASE-12295: --- bq. Then thinking more and more I landed in all these kind of practical issues... bq. Am I explaining it clearly now? Ok [~anoop.hbase] A close on Cell won't fly. Agree. Looking at last patch now... > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575732#comment-14575732 ] ramkrishna.s.vasudevan commented on HBASE-12295: [~saint@gmail.com] Thanks for a detailed review. I have responded to your questions in RB. Let us know if they are not clear or need more inputs. Will work on the changes after we discuss things based on the reply. Thanks once again. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583173#comment-14583173 ] ramkrishna.s.vasudevan commented on HBASE-12295: Had some internal discussions on some of the questions raised Thanks for the reviews so far over in RB. We discussed some of your comments and thought of finalizing things and also thought it would help to clarify certain aspects as why it was done. -> CellBlock creation The first area is the cellblock creation. As per the previous mail discussion now we will have now create the cellBlock in the RsRpcServices layer both for scan and gets. The scans already were creating the cellScanner in the RsRpcServices layer - now that we have added the cellBlock creation here. But in order to do this we are creating a new getScanner() API in HRegion - (note that it is not in Region.java) so it is not exposed to CPs. This new API would indicate if the client is java based or not. For java based client we will allow the cellblock creation in the RsRpcServices layer and then the blocks are returned back (ref count decremented). But for the non-java cases we will go with the old getScanner() API only but internally it would set a state in the RegionScanner saying that the results are to be copied then and there as there is no cellblock creation for it. (We don't create cellblock for non-java cases as you may be already knowing it). Once the copying of the results are done we are sure that we can return the blocks back. This new state in the REgionScanner also helps us with the case of CPs wrapping the scanner where though the scan is from java -client the partial results could be used in the CPs and we may not know how the CPs will use the result. Hence it is better to copy those results like we do for non-java client cases. In case of scan() after every next() we make a call to return the blocks so that we don't hold them up till the scanners are done. Now coming to get(), we have now tweaked the logic of get() in RsrpcServices such that what ever was being done in Region.get() is now moved to RsRpcServices included CP hooks and once the result is formed we create the cellblock in RsRpcServices. For the non-java case the old Region.get() API is still used. Just like in scan the results would be copied once it is formed. Remember we need to use it for CP when it needs to do a get() on a region directly. In case of gets() the scanner.close() woudl ensure that the block ref count decrement happens. -> MemType and CacheType First of all we can be sure that none of the blocks coming from L1 cache needs to go through all these shared memory or copying stuff. Because they are just objects referring to the blocks created from HDFS and nothing is serialized and there is no problem of eviction. We need to do this only for Bucketcache. BucketCache again has 3 things -> RamQueue - which is like initially the blocks are added to this queue and then moved to the actual buckets. So there are chances the reads are served from these queue itself. Those cases there is no need for any copying or sharing of memory. (this is similar to L1). -> ByteBufferIOEngine This is the actual case where we need to solve. Here the block is for sure from L2 and also the memory is shared. So if you see in our patch we would have set this L2 and shared_memory only at this layer. -> fileIOEngine Here though it is a bucketcache impl there is no need for having a shared_mem because already there is copy from the file. But who is responsible for setting the memory type-? It should be the engine. The engine knows what type of memory it is creating. The engines just return a BB and we don't know the type of it. so better the engine set the type of the memory also. -> ReturnBlock in between code in HFileREaders This is important. As I earlier commented in the RB, the index or bloom blocks from L1 cache can get demoted to L2 cache. Our code is such that in some case we try to read a block and we iterate till we reach a data block. Those blocks could have been from L1 or L2 - we are not sure. So we have analysed the code and ensured that where ever we read blocks and just throw it away till we end up in a data block- all such blocks have to be returned back. If the block is from L1 it is going to be a noop. I verified it once again and to be safe added some try/finally around it. I can explain more on this if you have some queries. ->IPCUtil singleton IPCUtil singleton was mainly for ease of use. The IPCutil had the code to create Cellblock. So we wanted to reuse that code rather than duplicating it. We could create IPCUTil inside Payload also. But for doing that we need the 'conf' object. Most of the cases Payload is created from RPcControllerfactory where already we have 'conf'. But in case of AbstractRPcClient
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583177#comment-14583177 ] ramkrishna.s.vasudevan commented on HBASE-12295: We had more discussions on the Cache type and memory type Let me try to explain use of each (Part is already said by Ram as well as me in RB. Pardon for the repetition) CacheType is saying whether the block is from which cache or not at all from cache. This is useful while returning back the block. The return back is what is doing the ref count decrement now. But the return block can do any other kind of cleanup. We tried to make it general. So while return back, we have to know to which cache the block has to be returned (L1 or L2). As of today the L1 return is a noop still we are doing it. If we dont have the CacheType in block, we have to return it to both and search in both places. This is an overhead. Also there is another problem with CombinedCache. Consider a block is demoted from L1 to L2. While it was in L1, it was served from it to a scanner. But before it is returned back, it got moved to L2. Then another scanner get this same block and this time from L2. So the ref count for this block (block key) got incremented and now it is 1. (Remember the old scanner got from L1 and so ref count increment at that time).. Now the old scanner returning block and we return it to both L1 and L2. L2 will have an entry and ref count will become zero. Still an active scanner refering this. This can cause issues. Tomorrow if L3 cache also comes, if we mark the block from where it has come, we can do correct return and correct action. The usage of MemType (as of now Shared or NonShared) is for cell creation. We have to make Cells backed by shared cache memory location as SharedMemoryCell marked. Cells which are not coming from shared mem backed blocks, need not be SharedMemoryCell marked. CacheType of L2 does not mean always that the block is backed by shared memory. An eg: is FileIOEngine. Here while reading the blocks, we will have to read the data to a heap memory area (byte[]) from files. May be we can say for SharedMem type only the return is needed as of today. Still we wanted these 2 to be independent general things and f/w. IMHO, this looks cleaner and more extendable for future. To which Stack replied One more Q from Stack was why we need CacheType and MemType 2 enums? Will one be enough? Let me try to explain use of each (Part is already said by Ram as well as me in RB. Pardon for the repetition) CacheType is saying whether the block is from which cache or not at all from cache. This is useful while returning back the block. The return back is what is doing the ref count decrement now. But the return block can do any other kind of cleanup. We tried to make it general. So while return back, we have to know to which cache the block has to be returned (L1 or L2). As of today the L1 return is a noop still we are doing it. If we dont have the CacheType in block, we have to return it to both and search in both places. >>Can you mark the HFileBlock with where it came form when you cache it rather >>than write out the type with the data? This is an overhead. Also there is another problem with CombinedCache. >>CombinedCache is one possible combination. Change it if is making your life >>more difficult. Consider a block is demoted from L1 to L2. For CombinedCache, this would be an index or bloom block only. While it was in L1, it was served from it to a scanner. But before it is returned back, it got moved to L2. Then another scanner get this same block and this time from L2. So the ref count for this block (block key) got incremented and now it is 1. (Remember the old scanner got from L1 and so ref count increment at that time).. Now the old scanner returning block and we return it to both L1 and L2. L2 will have an entry and ref count will become zero. Still an active scanner refering this. This can cause issues. Tomorrow if L3 cache also comes, if we mark the block from where it has come, we can do correct return and correct action. >>They'd be the same HFileBlock instance? The same item in cache? We're >>talking now of moving between caches while something is being used. That'd be >>a no-no, right? If its referenced you can't move it, not unless its L1 where >>it is safe to move it (you'd just scrub refcounts) >>Can keep type specific refcounts if an issue? The usage of MemType (as of now Shared or NonShared) is for cell creation. We have to make Cells backed by shared cache memory location as SharedMemoryCell marked. Cells which are not coming from shared mem backed blocks, need not be SharedMemoryCell marked. CacheType of L2 does not mean always that the block is backed by shared memory. An eg: is FileIOEngine. Here while reading the blocks, we will have to read
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583178#comment-14583178 ] ramkrishna.s.vasudevan commented on HBASE-12295: Based on review comments if callBack mode can be made from the RPcServer - few things are being tried out. Once we finalize on it can post a patch for that part. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583605#comment-14583605 ] stack commented on HBASE-12295: --- Thanks for updating the issue w/ our off-list discussion [~anoop.hbase] and [~ram_krish] In short, we are trying to figure how we can release the offheap blocks when done with them after sending the response. > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584222#comment-14584222
]
stack commented on HBASE-12295:
---
I had a nice chat with [~mbertozzi] on how to figure when we can let go of
offheap bucketcache blocks.
Would the following work?
Add a {{done}} or {{release}} method on serverside Cells. It is called when the
Cell has been used up; i.e. the Cell has been dumped out on the RPC. It is a
noop unless Cell is an instance of RefCountedDBBBackedCell. In this case, we
decrement our refcounter. How we get to our refcounter you say? Well, a
RefCountedDBBBackedCell is backed by a byte array. Let the refcounter be at
location zero in the backing byte array (In the BucketCache case, this would be
offset zero in a bucket I believe -- haven't checked). Changing refcount would
have to be threadsafe so synchronize on the backing DBB doing any access would
be a coarse first cut means of doing this. When we make Cells -- in
HFileScannerImpl -- we'd have to ask the HFileBlock, what type it was... and if
a refcounting block, we'd make RefCountedDBBBackedCell and up the refcount per
one made (could try and do bit increment/decrement so don't have to parse as an
int each time we want to increment).
> Prevent block eviction under us if reads are in progress from the BBs
> -
>
> Key: HBASE-12295
> URL: https://issues.apache.org/jira/browse/HBASE-12295
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf,
> HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache,
> we need to ensure that the blocks does not get evicted under us while
> reading. This JIRA is to discuss and implement a strategy for the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12295) Prevent block eviction under us if reads are in progress from the BBs
[ https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584395#comment-14584395 ] Anoop Sam John commented on HBASE-12295: Bq.call cell.done/release when it is dumped at RPC The issue is there is no guarentee that a cell, created from hfileblock will reach thia rpc layer. What if it was version expired or ttl expired. We can make sure to call it before discarding cell. What if it is filtered by a filter. I would say this will add all complexity and and chances of we missinh this done call > Prevent block eviction under us if reads are in progress from the BBs > - > > Key: HBASE-12295 > URL: https://issues.apache.org/jira/browse/HBASE-12295 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-12295.pdf, HBASE-12295_1.patch, HBASE-12295_1.pdf, > HBASE-12295_2.patch, HBASE-12295_4.patch, HBASE-12295_trunk.patch > > > While we try to serve the reads from the BBs directly from the block cache, > we need to ensure that the blocks does not get evicted under us while > reading. This JIRA is to discuss and implement a strategy for the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
