[
https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1750:
--------------------------------
Perhaps it would be simpler to create a new interface {{ExtendedAddress}} and an impl
{{ExtendedUUID}} which contains the UUID and additional data, e.g. {{site_id}},
{{rack_id}} and {{machine_id}} for {{TopologyUUID}}, or a string for {{PayloadUUID}}
etc...
The {{AddressGenerator}} would wrap the base address in an {{ExtendedUUID}} and data could
then be added to that address, e.g. via puts and gets (conceptual hashmap).
This would also allow us to get rid of a number of classes...
RELAY2 : Address formats are not relayed.
-----------------------------------------
Key: JGRP-1750
URL:
https://issues.jboss.org/browse/JGRP-1750
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.4.1
Reporter: Karim AMMOUS
Assignee: Bela Ban
Fix For: 3.5
When defining a relay channel, we haven't the ability to set an AddressGenrator.
Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID.
This is particularly embarrassing in the following case: when we define a customized
address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A
and B, address format is lost by crossing relay. Address type of messages sent by A to B
are seen as SiteUUID at B side.
Suggestions:
- Making address format "relayable" ?
- Using the same (or an extended format) AddressGenerator of site Channel
--
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