[
https://issues.apache.org/jira/browse/HBASE-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433304#comment-13433304
]
Roman Shaposhnik commented on HBASE-6567:
-----------------------------------------
It would definitely address the issue that is lurking (mainly the fact that the
proposed variable serves too purposes -- enabling the feature to begin with and
telling the system what is the target user). That said, I feel that
HBASE_REGIONSERVER_MLOCK_USER is also not ideal, since it doesn't really
communicate clearly what is happening. In my initial proposal I was trying to
minimize the # of variables that we would have to introduce but perhaps we
should just bite the bullet and have two:
* HBASE_REGIONSERVER_MLOCK (binary: empty/not set -- disabled, non empty --
enabled)
* HBASE_REGIONSERVER_UID (string: a target user for the running process
regardless of any other feature that is enabled)
> make memory locking configuration of regioservers more flexible
> ---------------------------------------------------------------
>
> Key: HBASE-6567
> URL: https://issues.apache.org/jira/browse/HBASE-6567
> Project: HBase
> Issue Type: Improvement
> Components: scripts
> Affects Versions: 0.96.0
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Fix For: 0.96.0
>
>
> The current implementation of the memory locking feature of regisoservers has
> a downside of not being flexible to configure for permanent use. Sure there
> is a --mlock flag but that needs to be explicitly passed on every invocation
> and thus require extra steps to be configured for permanent use (IOW, there's
> not a single env variable I can set to have a desired effect). The only other
> alternative -- the explicit setting of HBASE_REGIONSERVER_OPTS -- has a
> downside of being pretty cryptic to the novice user and has a killer problem
> of not explicitly telling higher level scripts (like init.d or upstart ones)
> which user the initial hbase process should be executed as.
> I propose a very simple solution (which is essentially making --mlock setting
> into an env. variable): add a variable called HBASE_REGIONSERVER_MLOCK that
> can be set in hbase-env.sh and has the following semantics:
> * [default] not set: mlocking feature is disabled
> * set but empty: mlocking feature is enabled and the target user is hbase
> * set and not empty: mlocking feature is enabled and the target user is
> the value of the variable
> Thoughts?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
