[ 
https://issues.apache.org/jira/browse/HDDS-1926?focusedWorklogId=290729&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-290729
 ]

ASF GitHub Bot logged work on HDDS-1926:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 07/Aug/19 19:47
            Start Date: 07/Aug/19 19:47
    Worklog Time Spent: 10m 
      Work Description: hadoop-yetus commented on issue #1247: HDDS-1926. The 
new caching layer is used for old OM requests but not updated.
URL: https://github.com/apache/hadoop/pull/1247#issuecomment-519243330
 
 
   :broken_heart: **-1 overall**
   
   
   
   
   
   
   | Vote | Subsystem | Runtime | Comment |
   |:----:|----------:|--------:|:--------|
   | 0 | reexec | 79 | Docker mode activated. |
   ||| _ Prechecks _ |
   | +1 | dupname | 0 | No case conflicting files found. |
   | +1 | @author | 0 | The patch does not contain any @author tags. |
   | -1 | test4tests | 0 | The patch doesn't appear to include any new or 
modified tests.  Please justify why no new tests are needed for this patch. 
Also please list what manual steps were performed to verify this patch. |
   ||| _ trunk Compile Tests _ |
   | +1 | mvninstall | 627 | trunk passed |
   | +1 | compile | 368 | trunk passed |
   | +1 | checkstyle | 72 | trunk passed |
   | +1 | mvnsite | 0 | trunk passed |
   | +1 | shadedclient | 968 | branch has no errors when building and testing 
our client artifacts. |
   | +1 | javadoc | 172 | trunk passed |
   | 0 | spotbugs | 479 | Used deprecated FindBugs config; considering 
switching to SpotBugs. |
   | +1 | findbugs | 695 | trunk passed |
   ||| _ Patch Compile Tests _ |
   | +1 | mvninstall | 564 | the patch passed |
   | +1 | compile | 385 | the patch passed |
   | +1 | javac | 385 | the patch passed |
   | +1 | checkstyle | 84 | the patch passed |
   | +1 | mvnsite | 0 | the patch passed |
   | +1 | whitespace | 0 | The patch has no whitespace issues. |
   | +1 | shadedclient | 765 | patch has no errors when building and testing 
our client artifacts. |
   | +1 | javadoc | 171 | the patch passed |
   | +1 | findbugs | 718 | the patch passed |
   ||| _ Other Tests _ |
   | +1 | unit | 358 | hadoop-hdds in the patch passed. |
   | -1 | unit | 2156 | hadoop-ozone in the patch failed. |
   | +1 | asflicense | 41 | The patch does not generate ASF License warnings. |
   | | | 8391 | |
   
   
   | Reason | Tests |
   |-------:|:------|
   | Failed junit tests | hadoop.ozone.client.rpc.TestSecureOzoneRpcClient |
   |   | hadoop.ozone.om.TestScmSafeMode |
   |   | hadoop.ozone.client.rpc.TestOzoneAtRestEncryption |
   |   | hadoop.ozone.client.rpc.TestBlockOutputStreamWithFailures |
   |   | hadoop.ozone.client.rpc.TestOzoneRpcClient |
   |   | hadoop.hdds.scm.pipeline.TestRatisPipelineCreateAndDestory |
   |   | hadoop.ozone.client.rpc.TestMultiBlockWritesWithDnFailures |
   
   
   | Subsystem | Report/Notes |
   |----------:|:-------------|
   | Docker | Client=19.03.1 Server=19.03.1 base: 
https://builds.apache.org/job/hadoop-multibranch/job/PR-1247/1/artifact/out/Dockerfile
 |
   | GITHUB PR | https://github.com/apache/hadoop/pull/1247 |
   | Optional Tests | dupname asflicense compile javac javadoc mvninstall 
mvnsite unit shadedclient findbugs checkstyle |
   | uname | Linux 4ae2dd5a127b 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
   | Build tool | maven |
   | Personality | personality/hadoop.sh |
   | git revision | trunk / 827dbb1 |
   | Default Java | 1.8.0_222 |
   | unit | 
https://builds.apache.org/job/hadoop-multibranch/job/PR-1247/1/artifact/out/patch-unit-hadoop-ozone.txt
 |
   |  Test Results | 
https://builds.apache.org/job/hadoop-multibranch/job/PR-1247/1/testReport/ |
   | Max. process+thread count | 4666 (vs. ulimit of 5500) |
   | modules | C: hadoop-ozone/ozone-manager U: hadoop-ozone/ozone-manager |
   | Console output | 
https://builds.apache.org/job/hadoop-multibranch/job/PR-1247/1/console |
   | versions | git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1 |
   | Powered by | Apache Yetus 0.10.0 http://yetus.apache.org |
   
   
   This message was automatically generated.
   
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 290729)
    Time Spent: 0.5h  (was: 20m)

> The new caching layer is used for old OM requests but not updated
> -----------------------------------------------------------------
>
>                 Key: HDDS-1926
>                 URL: https://issues.apache.org/jira/browse/HDDS-1926
>             Project: Hadoop Distributed Data Store
>          Issue Type: Bug
>          Components: om
>            Reporter: Elek, Marton
>            Assignee: Bharat Viswanadham
>            Priority: Blocker
>              Labels: pull-request-available
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> HDDS-1499 introduced a new caching layer together with a double-buffer based 
> db writer to support OM HA.
> TLDR: I think the caching layer is not updated for new volume creation. And 
> (slightly related to this problem) I suggest to separated the TypedTable and 
> the caching layer.
> ## How to reproduce the problem?
> 1. Start a docker compose cluster
> 2. Create one volume (let's say `/vol1`)
> 3. Restart the om (!)
> 4. Try to create an _other_ volume twice!
> ```
> bash-4.2$ ozone sh volume create /vol2
> 2019-08-07 12:29:47 INFO  RpcClient:288 - Creating Volume: vol2, with hadoop 
> as owner.
> bash-4.2$ ozone sh volume create /vol2
> 2019-08-07 12:29:50 INFO  RpcClient:288 - Creating Volume: vol2, with hadoop 
> as owner.
> ```
> Expected behavior is an error:
> {code}
> bash-4.2$ ozone sh volume create /vol1
> 2019-08-07 09:48:39 INFO  RpcClient:288 - Creating Volume: vol1, with hadoop 
> as owner.
> bash-4.2$ ozone sh volume create /vol1
> 2019-08-07 09:48:42 INFO  RpcClient:288 - Creating Volume: vol1, with hadoop 
> as owner.
> VOLUME_ALREADY_EXISTS 
> {code}
> The problem is that the new cache is used even for the old code path 
> (TypedTable):
> {code}
>  @Override
>   public VALUE get(KEY key) throws IOException {
>     // Here the metadata lock will guarantee that cache is not updated for 
> same
>     // key during get key.
>     CacheResult<CacheValue<VALUE>> cacheResult =
>         cache.lookup(new CacheKey<>(key));
>     if (cacheResult.getCacheStatus() == EXISTS) {
>       return cacheResult.getValue().getCacheValue();
>     } else if (cacheResult.getCacheStatus() == NOT_EXIST) {
>       return null;
>     } else {
>       return getFromTable(key);
>     }
>   }
> {code}
> For volume table after the FIRST start it always returns with 
> `getFromTable(key)` due to the condition in the `TableCacheImpl.lookup`:
> {code}
>   public CacheResult<CACHEVALUE> lookup(CACHEKEY cachekey) {
>     if (cache.size() == 0) {
>       return new CacheResult<>(CacheResult.CacheStatus.MAY_EXIST,
>           null);
>     }
> {code}
> But after a restart the cache is pre-loaded by the TypedTable.constructor. 
> After the restart, the real caching logic will be used (as cache.size()>0), 
> which cause a problem as the cache is NOT updated from the old code path.
> An additional problem is that the cache is turned on for all the metadata 
> table even if the cache is not required... 
> ## Proposed solution
> As I commented at HDDS-1499 this caching layer is not a "traditional cache". 
> It's not updated during the typedTable.put() call but updated by a separated 
> component during double-buffer flash.
> I would suggest to remove the cache related methods from TypedTable (move to 
> a separated implementation). I think this kind of caching can be independent 
> from the TypedTable implementation. We can continue to use the simple 
> TypedTable everywhere where we don't need to use any kind of caching.
> For caching we can use a separated object. It would make it more visible that 
> the cache should always be updated manually all the time. This separated 
> caching utility may include a reference to the original TypedTable/Table. 
> With this approach we can separate the different responsibilities but provide 
> the same functionality.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to