I think this is fine - it's still opaque but it's value can be relied upon to
be consistent across the product. I just don't want people relying on what is
in the value.
----- Original Message -----
From: "Geert Bevin" <gbe...@terracottatech.com>
To: tc-dev@lists.terracotta.org
Sent: Tuesday, January 27, 2009 2:47:23 AM GMT -08:00 US/Canada Pacific
Subject: Re: [tc-dev] First public draft of new cluster events design
> 1) I propose that the node id should be completely opaque. I don't
> like making it something people will depend on, as it is then a part
> of the API (at least implicitly)
The design doc current says that the ID available through DsoNode
would tie back to a consistent identifier that is used in the admin
console, logging, debugging, ... While I see the value of making the
DsoNode opaque, I think that the need to be able to tie back into
other information sources is more important.
> 2) Providing a method to obtain the cluster information Iyer has
> asked for makes a lot of sense. I am not sure this is in scope for
> this effort, but I would entertain it presuming the LOE is not too
> great (and Steve agrees). In fact Gary Keim and discussed at some
> point introducing a capability for naming clients just as servers
> can be named. I don't think we should introduce this particular
> feature just yet, but I think that by introducing an API and some
> sort of "cluster node meta information" class, we could encapsulate
> the known data about a particular cluster node and modify it in the
> future to include such a feature.
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();
// ...
}
> 3) After several discussions concering delivering state w/ the event
> vs. state as an API and not w/the event, I am firmly on the side of
> state as an API. My reasoning is thus:
> a) The state that comes with the event is guaranteed to be stale
> by the time of the delivery
> b) The state that comes from an API is guaranteed to be stale by
> the time it is returned to the user
>
> Therefore, a and b are not much different from one another in terms
> of stale or not stale, but a) is a lot more expensive to implement,
> and may simultaneously not be used by the end user.
>
> The programming paradigm for querying after receipt of the event is
> exactly the same as when programming a wait() event loop. When wait
> is woken by a notify, you must always check the state of the system
> (which is why a wait must always be surrounded by a while). The
> same will be true for receiving events from the cluster - they will
> only notify you that something has changed, but due to the fact that
> a cluster is dynamic, you must query the cluster for its state and
> react appropriately.
You're the one with the most knowledge of the use cases. It just seems
very useful to me to be able to get access to the exact cluster
topology at the time of an event. Ie. a consistent view of the system
at a known time. However, I can't come up with a use case for it ;-)
--
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
