Regarding client names, I was considering trying to unify the approach used for
server naming, e.g. somehow allow the user to pass in a name like the "-n"
approach used for the server (of course, the server takes a command line
argument, but maybe it should instead be a property - e.g. tc.node) that is the
same for the client or server. For convenience, the start server script can
translate the -n parameter to the tc.property.
----- Original Message -----
From: "Geert Bevin" <gbe...@terracottatech.com>
To: tc-dev@lists.terracotta.org
Sent: Tuesday, January 27, 2009 2:19:48 PM GMT -08:00 US/Canada Pacific
Subject: Re: [tc-dev] First public draft of new cluster events design
> Yeah - IDs will need some string or identifying information to be
> useful. I would much rather reuse an existing identifier that is
> visible at other parts of the system than make up some new
> identifier. I don't think it's feasible to rely solely on a
> completely opaque object based on object identity.
I agree, the current cluster events already use a string node ID. I
suggest to just reuse that as the result of the DsoNode.getId() method.
>>> The LOE doesn't seem high to me and it would be cached locally on
>>> each
>> node. I would provide this through DsoNode:
>>
>> interface DsoNode {
>> String getId();
>> String getIp();
>> String getHostname();
>> String getDsoPort();
>> // ...
>> }
>>
>> Getting some sort of user-specified node information seems like it
>> would be extremely useful in this API. Seems like there are lots of
>> cases where a user wants to mark a node in some way, by name,
>> category, role, etc.
That could be handy indeed. The question is how to set that up. This
can't really be done through tc-config.xml since it's shared for all
nodes and the nodes are dynamical. The only option I can currently
think of is a JVM property, but that's a bit icky.
>> As long as we don't have to eagerly look up this information just to
>> send events, I think having it on the node class is fine. Otherwise
>> we might be introducing unnecessary network I/O.
I was thinking of sending this once and only once when nodes connect
and the event arrives at the other nodes. From that time onwards it
would be cached locally.
>> What is the DSO port? Does that make sense to track and expose for
>> an
>> L1?
Probably not :-)
--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Flytecase Band - http://flytecase.be
Music and words - http://gbevin.com
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
