See the event ordering diagram for when and how a user is allowed to receive
messages and what they mean.
A node joined event is always delivered during start, as is an operations
disabled (assuming the client connected properly). After an operations
disabled event you may or may not receive operations enabled. You may or may
not receive node left.
Node joined and left events are final. Once joined, you are a part of the
cluster. Once left, you are permanently out (for whatever reasons the
underlying comms layers have decided).
Operations enabled and disabled are informational - and mean exactly what they
say - after a disabled is sent it means that the underlying system has
determined that for some reason, cluster progress will not be made.
So, the point of the two kinds of messages is to abstract away the physical
events going on in the underlying system from the programmer. Operations
disabled for example can happen because of a temporary network disconnect, but
it can also happen if for example running with active active stripe groups and
one group is temporarily down. An operations disabled could be triggered if
for example in the future we implemented a "cluster node pause" feature in
which an operator could pause a cluster node and then unpause it. This is just
a theoretical example I making (I don't think we intend to build such a thing)
but I use it as a point to illustrate how the operations enabled/disabled are
abstracted to the point which the application developer should not know or care
what caused the actual operations disabled event, just that they now know that
for some reason, the attached node is prevented from making progress.
----- Original Message -----
From: "Sreenivasan Iyer" <si...@terracottatech.com>
To: tc-dev@lists.terracotta.org
Sent: Monday, January 26, 2009 4:19:39 PM GMT -08:00 US/Canada Pacific
Subject: Re: [tc-dev] First public draft of new cluster events design
Thanks for the responses…
1. Node-id can be opaque – all’s I am saying is that the API-user
typically needs to translate the Terracotta-node-id to a more
well-known-node-id and it would be good if we gave them the translation in the
API (in the interests of keeping application code around the API minimal).
2. With regards to point 3 to which Geert mentioned: “ I'm sorry, I'm
having trouble to compute this sentence. Would you mind rephrasing it or to
give more context? “ … never mind – I was just referring to Page-2, Use Cases
#1 – where the design doc presumably says that after implementation – Use-Case
#1 will work – where in clients will kill themselves or resume operations
locally, if the cluster is no longer able to service operations. Related
questions here are:
a. Are we implicitly saying that the API will indicate to the user: when
a Node-has-disconnected and Has-Operations-Disabled and HAS-NO-POSSIBILITY of
getting to an Operations-Enabled state ? – as against being in the
Operations-Disabled-state for a temporary period of time. Only in the former
case, does the node need to commit seppuku…
b. Also will the API expose visibility into various possible enumerations
of the state machine – e.g. a Node that has Disconnected but is in the process
of Connecting Back as per the rules of engagement laid down by the
heart-beating configuration…
Thanks
From: tc-dev-boun...@lists.terracotta.org
[mailto:tc-dev-boun...@lists.terracotta.org] On Behalf Of Taylor Gautier
Sent: Monday, January 26, 2009 3:24 PM
To: tc-dev@lists.terracotta.org
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)
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.
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.
----- Original Message -----
From: "Geert Bevin" <gbe...@terracottatech.com>
To: tc-dev@lists.terracotta.org
Sent: Monday, January 26, 2009 9:40:53 AM GMT -08:00 US/Canada Pacific
Subject: Re: [tc-dev] First public draft of new cluster events design
> Another alternative is to make the ID simple but allow some way to
> lookup metadata related to the ID (such as IP, hostname, a user-
> specified node name, or whatever makes sense).
Sounds like a good idea!
This could even be included as additional methods on the DsoNode class
and the information can be cached locally.
>>> 2. Another problem several customers have had to solve is
>>> identifying a delta between a "specification of expected cluster
>>> Topology" and "current cluster Topology".
>>> e.g. I expect the following 10IPs to be present in the cluster. Any
>>> delta vis-à-vis the topology requires some programmatic action. Is
>>> there any treatment to make that easy...
>>>
>> We initially wanted to send along the whole cluster topology with
>> each
>> event, and I still think that this might make the life of customers
>> easier. They wouldn't have to try to determine what the difference is
>> between the current cluster state and the cluster state at the event
>> time. In the latest version of the spec, we don't send the cluster
>> topology state along with the events anymore. Do you think that we
>> should?
>
> Again, this kind of sounds like a need for accessing configuration
> information that would tell you the expected cluster state?
The problem here is "expected"? Would this be the cluster state at the
time of the event trigger? Making sure that this is accessible without
including it in the event would require some kind of repository of
cluster states that people can query to find out which one corresponds
to an event. Then we get also into the whole problem of having to
maintain that. Including it with an event seems much simpler imho. It
wouldn't need to be large at all, this cluster state can internally be
send using a simple number for each node and send an array of shorts
around (a max of 65k nodes seems sufficient ;-)). This could then
locally be expanded to actual node IDs.
--
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
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
