[jboss-jira] [JBoss JIRA] Commented: (JGRP-931) Logical addresses: canonicalize UUIDs with IDs (shorts)
[
https://jira.jboss.org/browse/JGRP-931?page=com.atlassian.jira.plugin.sys...
]
Bela Ban commented on JGRP-931:
-------------------------------
The ID might be returned as part of the JOIN response, by the coordinator. If we create a
regular address using a UUID first, after reception of the JOIN response, we could simply
trash the UUID and use the ID instead. This of course requires that UUIDs and IDs can
compare to each other, and we can flush the ID cache and fall back to UUIDs at any time.
The coordinator could simply increment the current ID, but it must also be shared with
other members: if the coord crashes, the next coord must pick up where the old left off.
Maybe the current ID could be part of a View, as additional data ?
Logical addresses: canonicalize UUIDs with IDs (shorts)
-------------------------------------------------------
Key: JGRP-931
URL: https://jira.jboss.org/browse/JGRP-931
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.11
Instead of using UUIDs as addresses, the cluster members should agree on shorts, e.g. 1
for A, 2 for B and so on, and use these instead of UUIDs.
This happens after a certain warmup time. E.g. the coord could assign these IDs, so
they're unique.
IdAddress and UUID have to be able to do equals() or compareTo() with each other !
Advantage:
- we send a short (2 bytes) instead of a UUID (16 bytes)
- we use an IdAddress (class with a short) instead of a UUID. This is 6 bytes less per
instance
- IdAddress might be faster with equals() and hashCode() than UUID
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira