Package org.cometd.oort

Class OortObject<T>

java.lang.Object
org.eclipse.jetty.util.component.AbstractLifeCycle
org.cometd.oort.OortObject<T>
Type Parameters:
T - the type of value object stored in this oort object
All Implemented Interfaces:
Iterable<OortObject.Info<T>>, EventListener, ConfigurableServerChannel.Initializer, Oort.CometListener, org.eclipse.jetty.util.component.LifeCycle
Direct Known Subclasses:
OortContainer
public class OortObject<T>
extends org.eclipse.jetty.util.component.AbstractLifeCycle
implements ConfigurableServerChannel.Initializer, Oort.CometListener, Iterable<OortObject.Info<T>>

An OortObject represents a named composite entity that is distributed in an Oort cluster.

A typical example is an oort object that stores the number of users connected to an Oort node. The entity in this case is a long value representing the number of connected users. Such oort object may be named 'user_count', and there will be an oort object instance with this name in each node. Each oort object instance will have a different local value, along with all the values from the other nodes.

A particular OortObject has a unique name across the node and is made of N parts, where N is the number of active nodes. A part is represented by OortObject.Info instances. Each OortObject.Info instance represents the contribution of that node to the whole OortObject and stores the Oort URL of the node it represents along with the entity in that node.

     +------------+
     | user_count |
 +---+---+----+---+--------------------+
 | part1 | 13 | local - http://oort1/  |
 +-------+----+------------------------+
 | part2 | 19 | remote - http://oort2/ |
 +-------+----+------------------------+
 | part3 | 29 | remote - http://oort3/ |
 +-------+----+------------------------+

An OortObject must be created and then started:

 Oort oort1 = ...;
 OortObject userCount1 = new OortObject(oort1, "user_count", OortObjectFactories.forLong());
 userCount1.start();

Once started, it connects via Oort facilities to the other nodes and communicates with the oort object instances that have the same name that live in the other nodes. The communication is performed on a channel constructed from the oort object's name and returned by getChannelName().

Oort objects work best when the entity they hold is an immutable, value-type object: OortObject<Long> works better than OortObject<AtomicLong> because AtomicLong is mutable and its APIs (for example, AtomicLong.compareAndSet(long, long)) are not exposed by OortObject.

Objects stored by an oort object are created using a OortObject.Factory. This is necessary to recreate objects that may be serialized differently when transmitted via JSON, without forcing a global JSON serializer. A number of factories are available in OortObjectFactories, and applications can write their own.

Applications can change the entity value of the oort object and broadcast the change to other nodes via setAndShare(Object, Result). The other nodes will receive a message on the oort object's channel and set the new entity value in the part that corresponds to the node that changed the entity. The diagram below shows one oort object with name "user_count" in two nodes. On the left of the arrow (A), the situation before calling:

 userCount1.setAndShare(17);

and on the right of the arrow (A) the situation afterwards, that shows how the value is first changed (1) locally on node_1, then a message (2) is broadcast on the cluster, reaches node_2, where it updates (3) the part corresponding to node_1 to the new value.

 +-------------+  +-------------+         +-----------------+       +-----------------+
 |   node_1    |  |   node_2    |         |     node_1      |       |     node_2      |
 +-------------+  +-------------+         +-----------------+  (2)  +-----------------+
 | user_count  |  | user_count  |   (A)   |   user_count    | ----> |   user_count    |
 +--------+----+  +--------+----+  ---->  +--------+--------+       +--------+--------+
 | local  | 13 |  | local  | 19 |         | local  | 17 (1) |       | local  | 19     |
 +--------+----+  +--------+----+         +--------+--------+       +--------+--------+
 | remote | 19 |  | remote | 13 |         | remote | 19     |       | remote | 17 (3) |
 +--------+----+  +-------+----+          +--------+--------+       +-------+---------+

When an entity is updated, either locally or remotely, an event is fired to registered OortObject.Listeners.

Oort objects can only update the entity they own; in the example above, node_1 can only update the "local" value 13 to 17, but cannot modify the "remote" value 19, which is owned by node_2. Only update messages from node_1 can update the "remote" value on node_2. Every node has a part that belongs to a particular node, and only that particular node can update it.

Values of oort objects may be merged using a OortObject.Merger via merge(Merger). A number of mergers are available in OortObjectMergers, and applications can write their own. For example:

 long totalUsersOnAllNodes = userCount1.merge(OortObjectMergers.longSum()); // yields 17+19=36

Oort objects implement a strategy where value objects are replicated in each node, trading increased memory usage for reduced latency accessing the data. An alternative strategy that trades reduced memory usage for increased latency is implemented by OortService.