Hi Hedera people,
Emmanuel Cecchet wrote:
Hi Karl,
I found a more elegant way of dealing with non-unique (groupid, node)
running on the same server (see my previous post) : the local member is
identified with the localhost ip, the group identifier and a unique id
set
in the configuration properties file as the port.
Yes, this is probably the easiest way. Each controller has a unique id
that it could use but we would have to modify the Hedera API to allow
the setting of this unique id. It is prably better to let this off the API.
Just a minor remark about member identification in Hedera.
With the current naming schema (node + port + groupId) we cannot
distinguish between two members of the same group hosted by the same
controller (i.e. same JVM). This is of course not a problem while using
Hedera in Sequoia: we do not host two instances of a single distributed
virtual database on the same controller!
However if Hedera is to be used as a generic group communication layer
within a different context these naming issue may arise. To be
completely transparent we should be able to create and manage several
members of the same group inside a single JVM.
In such a setting, the "dummy" random number proposed by Karl in a
previous message as a complementary identifier starts making sense.
Having a separate properties file (specifying a unique id) per member
would probably bee too cumbersome.
Cheers,
Damián
_______________________________________________
Hedera mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/hedera
