[
https://issues.apache.org/jira/browse/HBASE-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708733#comment-13708733
]
Sergey Shelukhin commented on HBASE-8927:
-----------------------------------------
As I said can we please look at reasons to do this, regardless of what this
clock does... there's not a single good reason to use nano in most places, with
the exception of column timestamp precision, for which a more complex and safer
scheme can be made as suggested by some comments above, and measuring time
taken for short (normally expected to take single seconds or less) operations.
Now, we could do it everywhere anyway just because why not, if it were free of
other consequences, but in this case we want to ignore explicitly missing
guarantees on the interface and rely on internals of particular JVM(s) and
OS(es). If some JVM, OS, or future changes to JVM code change the
implementation (still staying within the interface guarantees), there will be a
fail of epic proportions.
In my mind there isn't even a reason to look at internals and ponder, simply
because we don't stand to gain anything from nano in most places.
> Use nano time instead of mili time everywhere
> ---------------------------------------------
>
> Key: HBASE-8927
> URL: https://issues.apache.org/jira/browse/HBASE-8927
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Attachments: 8927.txt
>
>
> Less collisions and we are paying the price of a long anyways so might as
> well fill it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
