[
https://issues.apache.org/jira/browse/HTRACE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14647304#comment-14647304
]
stack commented on HTRACE-209:
------------------------------
bq. The problem is this would break our Hadoop / HBase wire compatibility,
since right now we have Hadoop RPC passing through 128 bits.
https://en.wikipedia.org/wiki/Robustness_principle On receipt, we don't care it
a UUID or not.
bq. I also think giving up bits is kind of questionable in general.
You have to give up some to mark it apart from pure random. The probability of
a clash when 122 bits is low. See this helpful exposition:
https://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates
(Might have to look into how we are generating the ids in particular with our
use of two Random longs...)
If it is not a UUID, we should not format in a manner that would have people
think it a UUID
bq. For example, if the span has 10 parents, and you add a new parent, are you
going to iterate through every existing parent to ensure that the new parent
doesn't duplicate an existing one?
Yes (smile). Won't you have to anyways when someone calls 'set' with 10
parents? Won't you have to check them anyways? OK to punt on this to a new
issue.
> Make span ID 128 bit to avoid collisions
> ----------------------------------------
>
> Key: HTRACE-209
> URL: https://issues.apache.org/jira/browse/HTRACE-209
> Project: HTrace
> Issue Type: Sub-task
> Affects Versions: 4.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HTRACE-209.001.patch, HTRACE-209.002.patch,
> HTRACE-209.004.patch, HTRACE-209.005.patch
>
>
> Make span ID 128 bit to avoid collisions in htrace 4.x
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
