[
https://issues.apache.org/jira/browse/HBASE-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081448#comment-13081448
]
stack commented on HBASE-4178:
------------------------------
IIUC, if a regionserver restarted, then it'd start scannerids over at zero
again. Any scanners that had been running against the server when it died will
have to go get new ids for the regions they had been scanning over in their new
locations (Scanner ids are scoped to a region scan; client sets up new scanner
id every time it crosses into new region)
> 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
