[
https://issues.apache.org/jira/browse/HDFS-13443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441217#comment-16441217
]
Íñigo Goiri commented on HDFS-13443:
------------------------------------
Thanks [~arshad.mohammad], do you mind adding a trunk patch too?
Yetus is not very good with branch-2 lately.
Some comments:
* Make the logs use the logger approach, for example in {{Router}}, we should
do: {{LOG.info("{} service is enabled",
MountTableRefreshService.class.getSimpleName());}}
* Make MOUNT_TABLE_CACHE_IMMEDIATE_UPDATE_MAX_TIME use
{{Configuration#getTimeDuration()}} instead of {{getInt()}}.
* Typo in {{MountTableStore}}, "Can not refresh munt table cache as state store
is not available", we can also make it shorter to fit one line, something like:
"Cannot refresh mount table: state store not available""
* {{MountTableStore#updateCache()}} could have a name a little more descriptive
like, {{updateCacheAllRouters()}}.
* As this is a new feature, I would like to have it disabled by default
(MOUNT_TABLE_CACHE_IMMEDIATE_UPDATE_DEFAULT to be false).
For {{MountTableRefreshService}}:
* The javadoc should be a little more descriptive and define the cycle: get the
routers, start updater, waiting...
* We could make {{new HashMap<String, RouterClient>()}} just {{new
HashMap<>()}}.
* The name for {{addressClientMap}} is not very clear; something like
{{routerClientsCache}}?
* Should we make this map a proper cache with expiration and so on? Use some of
the guava caches that create the client if not available and clean them up
after a while.
* Not sure what would happen if we have a client and then the Router goes down;
we should test cases where Routers leave after we setup the addressClientMap.
* Aren't we having a cascading effect that will never stop here? We update,
then we have R1 triggering all the updates, the same for R2 and so on. I would
add a counter for the number of updates and track this in the unit test (it
should have something like 4 routers).
> RBF: Update mount table cache immediately after changing (add/update/remove)
> mount table entries.
> -------------------------------------------------------------------------------------------------
>
> Key: HDFS-13443
> URL: https://issues.apache.org/jira/browse/HDFS-13443
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: fs
> Reporter: Mohammad Arshad
> Priority: Major
> Labels: RBF
> Attachments: HDFS-13443-branch-2.001.patch,
> HDFS-13443-branch-2.002.patch
>
>
> Currently mount table cache is updated periodically, by default cache is
> updated every minute. After change in mount table, user operations may still
> use old mount table. This is bit wrong.
> To update mount table cache, maybe we can do following
> * *Add refresh API in MountTableManager which will update mount table cache.*
> * *When there is a change in mount table entries, router admin server can
> update its cache and ask other routers to update their cache*. For example if
> there are three routers R1,R2,R3 in a cluster then add mount table entry API,
> at admin server side, will perform following sequence of action
> ## user submit add mount table entry request on R1
> ## R1 adds the mount table entry in state store
> ## R1 call refresh API on R2
> ## R1 calls refresh API on R3
> ## R1 directly freshest its cache
> ## Add mount table entry response send back to user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
