[
https://issues.apache.org/jira/browse/HBASE-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081323#comment-13081323
]
Gary Helmling commented on HBASE-4178:
--------------------------------------
What happens if a region server restarts? Would we be resetting and starting
the AtomicLong over again with numbers that were previously handed out? If so,
it's possible this change would vastly reduce the assignable space effectively
used and increase the probability of collisions.
I'm not sure if there's behavior in the client code that would effectively
invalidate the existing scanner in the case of a server restart -- would have
to check. We could also ensure uniqueness (and side-step the counter
resetting) by checking the server start code either on the client side or
changing scanner id from long to byte[] and prepending the start code with a
separator.
The current random assignment does nicely avoid this potential issue, though.
Yes there _is_ a possibility of collisions. But is this really an issue that
needs fixing? Personally, I'm open to arguments either way.
> Use of Random.nextLong() in HRegionServer.addScanner(...)
> ---------------------------------------------------------
>
> Key: HBASE-4178
> URL: https://issues.apache.org/jira/browse/HBASE-4178
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.3
> Reporter: Lars Hofhansl
> Priority: Minor
>
> ScannerIds are currently assigned by getting a random long. While it would be
> a rare occurrence that two scanners received the same ids on the same region
> server the results would seem to be... Bad.
> A client scanner would get results from a different server scanner, and maybe
> only from some of the region servers.
> A safer approach would be using an AtomicLong. We do not have to worry about
> running of numbers: If we got 10000 scanners per second it'd take > 2.9m
> years to reach 2^63.
> Then again the same reasoning would imply that this collisions would be
> happening too rarely to be of concern (assuming a good random number
> generator). So maybe this is a none-issue.
> AtomicLong would also imply a minor performance hit on multi core machines,
> as it would force a memory barrier.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
