User Tools

Site Tools


at:tutorial:distribution

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
at:tutorial:distribution [2009/01/29 10:31]
elisag
at:tutorial:distribution [2009/01/30 16:13] (current)
tvcutsem *fixed
Line 19: Line 19:
 </note> </note>
  
-===== Exporting and discovering objects =====+===== Exporting and Discovering Objects =====
  
 AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the ''export:as:'' construct.  The ''export:as:'' construct takes as argument an object that is made remotely accessible and a service type under which the object can be discovered. For example, one exports a printing service as follows: AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the ''export:as:'' construct.  The ''export:as:'' construct takes as argument an object that is made remotely accessible and a service type under which the object can be discovered. For example, one exports a printing service as follows:
Line 72: Line 72:
   - Native data types are always passed by copy.   - Native data types are always passed by copy.
  
-When a remote far reference receives a messages, it flushes the message to the remote object providing that it is connected. If the remote far reference is disconnected, messages are accumulate in its inbox in order to be transmitted once the reference becomes reconnected at a later point in time once the network connection is restored. +When a remote far reference receives a message, it flushes the message to the remote object providing that it is connected. If the remote far reference is disconnected, messages are accumulated in its inbox in order to be transmitted once the reference becomes reconnected at a later point in time, when the network connection is restored. 
  
-Therefore, a remote far reference abstracts a client object from the actual network connection state. However, it is often useful for an application to be informed when a connection to a remote object is lost or reconnected. To this end, AmbientTalk offers language constructs to install observers on a far reference which are triggered whenever the reference becomes disconnected or reconnected. For example, the instant messenger application can notify the user whenever a buddy moves in and out of the communication range as follows:+Therefore, a remote far reference allows its clients to make abstraction from the actual network connection state. However, it is often useful for an application to be informed when a connection to a remote object is lost or restored. To this end, AmbientTalk offers language constructs to install observers on a far reference which are triggered whenever the reference becomes disconnected or reconnected. For example, the instant messenger application can notify the user whenever a buddy moves in or out of the communication range as follows:
  
 <code> <code>
Line 88: Line 88:
 </code> </code>
  
-This code illustrate how the instant messenger application notifies when a buddy goes online or offline. In the above code, ''messenger'' is a remote reference to another remote buddy discovered. Note that installing disconnected observers also allows developers to clean certain resources when a remote reference becomes disconnected. However, when an instant messengers disconnects, the remote object referred to by ''messenger'' remains exported. This implies that remote objects remains pointed by a disconnected remote reference which prevents them from being garbage collected. In fact, ''messenger'' are never garbage unlesss explicit cancelation of the subscription. But other types of objects which are only relevant within the context of an interaction should become eventually candidates for garbage collection. In the next section, we detail how AmbientTalk deals with distributed memory management. +This code illustrates how the instant messenger application gets notified when a buddy goes online or offline. In the above code, ''messenger'' is a remote reference to another remote buddy discovered. Note that by installing observers that trigger upon disconnection, developers can clean certain resources when a remote reference becomes disconnected. However, when an instant messenger disconnects, the remote object referred to by ''messenger'' remains exported. This implies that a disconnected remote reference remains valid (it can reconnect), but also that the remote object remains referred to by a disconnected remote reference. This reference thus prevents the remote object from being garbage collected. In fact, ''messenger'' is never garbage unless its subscription is explicitly cancelled. But other types of objects which are only relevant within the context of an interaction should eventually become candidates for garbage collection. In the next section, we detail how AmbientTalk deals with distributed memory management. 
  
-In order to cope with partial failures, AmbientTalk also allows developers to retract all currently unsent messages from the remote far reference outbox by means of the ''retract'' language construct. This is specially useful in the context of distribution, since developers can have explicit control on the messages that are buffered but have not been sent while the remote far reference is disconnected. Any undelivered messages accumulated by the remote reference can be then for example forwarded to another remote object or simply cancelled. +In order to cope with partial failures, AmbientTalk also allows developers to retract all currently unsent messages from the remote far reference outbox by means of the ''retract'' language construct. This is especially useful in the context of distribution, since developers can have explicit control over the messages that are buffered but have not been sent while the remote far reference was disconnected. Any undelivered messages accumulated by the remote reference can then be e.g. forwarded to another remote object or simply cancelled.
  
-The ''retract'' language construct takes as argument the far reference of which to retract outgoing message send. One can store the unsent messages upon disconnection of a service type ''Service'' as follows:+The ''retract'' language construct takes as argument the far reference of which to retract buffered outgoing messages. One can store the unsent messages upon disconnection of a service type ''Service'' as follows:
  
 <code> <code>
Line 102: Line 102:
 </code> </code>
  
-The construct returns a table containing copies of all messenges that were sent to this far reference, but not yet transmitted by the far reference to the remote object pointed to. Note that this has the side effect that the returned messages will not be sent automatically anymore; the programmer is thus responsible to explicitly resend all messages that were retracted but still need to be sent. +The ''retract:'' call returns a table containing copies of all messenges that were sent to this far reference, but not yet transmitted by the far reference to the remote object pointed to. Note that this has the side effect that the returned messages will not be sent automatically anymore; the programmer is thus responsible to explicitly resend all messages that were retracted but still need to be sent. 
  
 The function ''when:disconnected:'' behaves like the previously discussed function ''whenever:disconnected:'', except it triggers the associated closure at most once, not upon //every// disconnect. The function ''when:disconnected:'' behaves like the previously discussed function ''whenever:disconnected:'', except it triggers the associated closure at most once, not upon //every// disconnect.
Line 108: Line 108:
 ===== Dealing with Permanent Failures ===== ===== Dealing with Permanent Failures =====
  
-As explained in the previous section, remote far references have been designed to be resilient to intermittent disconnections by default. This behaviour is desirable because it can be expected that many partial failures in mobile ad hoc networks are the result of transient network partitions. However, not all network partitions are transient. For example, a remote device has crashed or has moved out of the wireless communication range and does not return. Such permanent failures should also be dealt by means of compensating actions, e.g. application-level failure handling code.+As explained in the previous section, remote far references have been designed to be resilient to intermittent disconnections by default. This behaviour is desirable because it can be expected that many partial failures in mobile ad hoc networks are the result of transient network partitions. However, not all network partitions are transient. For example, a remote device has crashed or has moved out of the wireless communication range and does not return. Such permanent failures should also be dealt with by means of compensating actions, e.g. application-level failure handling code.
  
-To deal with permanent failures, AmbientTalk uses the concept of leasing. A lease denotes the right to access a resource for a specific duration that is negotiated by the owner of a resource and a resource claimant (called the lease grantor and lease holder, respectively) when the access is first requested.  At the discretion of the lease grantor a lease can be renewed, prolonging access to the resource. In AmbientTalk, we represent leases as a special kind of remote far references, which we call //leased object references//+To deal with permanent failures, AmbientTalk uses the concept of leasing. A lease denotes the right to access a resource for a specific duration that is negotiated by the owner of a resource and a resource claimant (called the lease grantor and lease holder, respectively) when the access is first requested. At the discretion of the lease grantor a lease can be renewed, prolonging access to the resource. In AmbientTalk, we represent leases as a special kind of remote far references, which we call //leased object references//.
  
 ====Leased Object References==== ====Leased Object References====
  
-A leased object reference is a remote far reference that grants access to a remote object for a limited period of time. When the time period has elapsed, the access to the remote object is terminated and the leased reference is said to //expire//. Similarly to remote far references, a leased reference abstracts client objects from the actual network connection state. Client objects can send a message to the remote object even if a leased references is disconnected at that time. Message are accumulated in order to be transmitted when the reference becomes reconnected. When the leased reference expires it, messages are discarded since an expired leased reference behaves as a //permanently// disconnected remote far reference. The figure below shows a diagram of the different states of a leased reference.+A leased object reference is a remote far reference that grants access to a remote object for a limited period of time. When the time period has elapsed, the access to the remote object is terminated and the leased reference is said to //expire//. Similarly to remote far references, a leased reference abstracts client objects from the actual network connection state. Client objects can send a message to the remote object even if a leased reference is disconnected at that time. Message are accumulated in order to be transmitted when the reference becomes reconnected. When the leased reference expires it, messages are discarded since an expired leased reference behaves as a //permanently// disconnected remote far reference. The figure below shows a diagram of the different states of a leased reference.
  
-{{ :at:tutorial:leasedref-state.png |:at:tutorial:leasedref-state.png}}+{{ :at:tutorial:leasedref-state.png |:at:tutorial:leasedref-state.png?160x30}}
  
 ====Working with leased object references==== ====Working with leased object references====
Line 221: Line 221:
 ====Importing leased object references==== ====Importing leased object references====
  
-Similar to futures, leased object references have been built reflectively on top of AmbientTalk.  The system library shipped with AmbientTalk contains the reflective implemention that adds leased references to the language kernel. This implementation can be found in the file at/lang/leasedrefs.at. +Similar to futures, leased object references have been built reflectively on top of AmbientTalk.  The system library shipped with AmbientTalk contains the reflective implemention that adds leased references to the language kernel. This implementation can be found in the file at/lang/leasedrefs.at and /at/lang/leasedrefstrait.at. 
  
 To use the language constructs for leased references, you should import the leasedref module as follows: To use the language constructs for leased references, you should import the leasedref module as follows:
-import /.at.lang.leasedref+<code> 
- +import /.at.lang.leasedrefs
-<note> +</code> 
-leasedref module exports support primitives to manipulate time intervals (i.e. minutes, seconds, millisecs) so that you do not need to explicitly import the timer module. Remember to exclude those methods from the leasedref import statement if some other module has already imported them, e.g. if futures are enabled.+<note warning
 +leasedrefs module exports support primitives to manipulate time intervals (i.e. ''minutes''''seconds''''millisecs'') so that you do not need to explicitly import the timer module. Remember to exclude those methods from the leasedrefs import statement if some other module has already imported them, e.g. if futures are enabled.
 </note> </note>
  
-More information pertaining to the API of the leased references language module can be found in the appendix.+More information pertaining to the API of the leased references language module can be found in the [[appendix|appendix]].
  
-===== Garbage collecting remote references =====+===== Taking Offline Remote Objects =====
  
-<note> +AmbientTalk distributed memory management scheme has been based on [[http://en.wikipedia.org/wiki/Reference_counting#Variants_of_reference_counting|reference listing]] and network objects. Similar to these techniques, remote far references are implemented by means of a proxy at client-side, which encapsulates a wire representation of the exported object and whose methods are stubs that transform local message sends into distributed message sends. Messages sent to the server include method invocation information, as well as the wire representation of the receiver. Each actor maintains an export object table which maps wire representations onto local references to exported objects. This table is used by the interpreter to resolve remote far references into local object references. Objects in the export table are considered as root objects for the [[http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)|local garbage collector]]. When an object is removed from the export table, it is no longer accessible remotely and, importantly, it no longer belongs to the set of root objects and as such, it becomes subject to garbage collection once it is no longer locally referenced.
-Under Construction: +
-Update this section to explain takeOffline in the contest of unitesting to unexport remotely accessible objects. +
-</note>+
  
-As explained in the previous sectionAmbientTalk'remote references are by default resilient to disconnectionsThis has significant repercussions at a distributed memory management level. The main impact is that an exported object cannot be reclaimed when all of its clients are disconnected since the remote references remain pointing to the server object. In other words, servers objects are kept alive even though there are only remotely accessible by disconnected remote reference. AmbientTalk provides built-in support to unexport explicitly remotely accessible objects by means of the ''takeOffline'' language constructThe construct look as follows:+As previously explainedin order to deal with volatile connections, remote far references tolerate network disconnections by default.  To enforce this, objects pointed by remote far references are not automatically taken offline when all their remote far references become disconnected, as traditionally happens in the above mentioned techniques. Rather, the object is kept in the export table since disconnected remote far references remain valid and still refer to the server object while disconnectedThis implies a remote object is never reclaimed. AmbientTalk provides the ''takeOffline:'' primitive that takes a remote object offline, enabling the object to be eventually locally garbage collection.
  
 <code> <code>
Line 245: Line 243:
 </code> </code>
  
-The construct removes from the export table of the actor where the code is executed the object passed as argument. When the object is removed from the export table, it no longer belongs to the set of root objects and as such, it can be reclaimed by the local garbage collector once when it is no longer locally referenced. Although the actual reclamation of an unexported object may be trigger at a later point in time, any attempt to access it via a far reference will result in a ''XObjectOffline'' exception.  +The primitive takes as parameter an object which is removed from the export table of the actor where the code is executed. When the object is removed from the export table, all remote far reference to the object become invalidated and the object no longer belongs to the set of root objects and as such, it can be eventually reclaimed by Java'local garbage collector once it is no longer locally referenced. Although the actual reclamation of an unexported object may be triggered at a later point in time, any attempt to access via a remote far reference results in an ObjectOffline exception notifying the client object that the object was taken offline and thus, its remote far references is invalid
- +  
-<note> +<note tip
-As you may have noticed, the ''takeOffline'' language construct is reminiscent to the so-called //delete// operation provided by some languages without built-in local garbage collection. It is indeed a design decision providing the minimal set of language constructs for distributed memory management. Rather than defining one specific distributed garbage collector directly in the interpreterwe have opted to enable the experimentation of distributed garbage collection techniques from within AmbientTalk itself. Thanks to AmbientTalk reflective infrastructure, it has been possible to build more sophisticated distributed garbage collection techniques to avoid the extra burden that takeOffline places on developers. More specifically, AmbientTalk integrates leasing techniques with the notion of a remote object reference, and provides the resulting //leased object references//. The system library shipped with AmbientTalk contains a reflective implementation of leased object references together with a set of language constructs to manipulate them.+[[distribution#dealing_with_permanent_failures|Leased object references]] make use of the ''takeOffline:'' primitive to terminate the access to a remote object once the lease time elapses. Note that the ''takeOffline'' primitive can be considered the equivalent to the so-called [[http://en.wikipedia.org/wiki/Manual_memory_management|''delete'' operation]] provided by some sequential languages without built-in local garbage collection.  Rather than using this primitive for garbage collection purposesregular AmbientTalk developers are encouraged to make use of the high-level language constructs for leasing explained [[distribution#dealing_with_permanent_failures|in the previous section]] which aids them to deal with both transient and permanent disconnections and properly reclaim their remote objects.
 </note> </note>
  
-On the client side, taking offline an object results in a permanent disconnection of the remote references pointing to it. In other words, despite having network connection, unexporting an object renders remote far references permanently disconnected. This implies that client have to deal explicitly with unexported objects. To this end, ''when:takenOffline'' has been implemented in order for developers to be able to install observers on an far reference which are notified when the object pointed to is taken offline. The construct takes as parameter far reference and a block of code that is executed when the taken offline event is notifiedAs an example, the instant messenger application can clean certain resources when a buddy shuts down its instant messenger application as follows:+====Working with objects taken offline==== 
 + 
 +On the client side, taking offline an object results in a permanent disconnection of the remote far references pointing to it. In other words, despite having network connection, unexporting an object renders remote far references permanently disconnected. This implies that client have to deal explicitly with unexported objects.  
 + 
 +Clients can get notified when an object is taken offline by means of ''when:disconnected:'' observers. Disconnected observers get triggered since the taking offline event is considered as a logical disconnection between two devices. However, once an object taken offline is removed from the export table, it cannot go online anymoreAs result, the disconnected and reconnected observers will be no longer trigger for that remote far reference.  
 + 
 +Additionally, AmbientTalk provides dedicated takenOffline observers which get triggered only once when the object is taken offline. They are installed similarly to when:disconnected observers as follows:
  
 <code> <code>
Line 260: Line 264:
 </code> </code>
  
-Be aware that unexporting a object will not only trigger the takenOffline observers but also the disconnected observers since the taking offline event is also considered as a logical disconnection between two devices. Unlike the network observers, the block of code of a takenOffline observer will be triggered only once. The remote object becomes then subject to be eventually reclaimed by the garbage collectorAs a result, the disconnected and reconnected observers will be no longer trigger for such remote reference.  +The construct takes as parameter a far reference and a block of code that is executed when the taken offline event is notified to the virtual machine''when:takenOffline'' observers can be considered as special kind of ''when:disconnected'' observers which are triggered only in case of "logical" disconnection, but not in cases of network disconnections.
- +
-Note that disconnection, reconnection and takenOffline observers can be also installed for the inter-actor far references. Such inter-actor far references are local to virtual machine and as such, network failures cannot happen. In that case, the disconnection and takenOffline observers are triggered when the object pointed to by the far reference is taken offline. But the reconnected observers won't be never triggered since an unexported object cannot be exported again+
  
 <note> <note>
-The complete implementation of the instant messenger application explained along this chapter can be found in the file ''at/demo/InstantMessenger.at''.+Disconnection, reconnection and takenOffline observers can be also installed for the inter-actor far referencesSuch inter-actor far references are local to a virtual machine and as such, network failures cannot happen. In that case, the disconnected and takenOffline observers are triggered when the object pointed to by the far reference is taken offline. Reconnected observers won't be ever triggered
 </note> </note>
 +
 +====Distributed unit testing and takeOffline====
 +
 +As previously mentioned, the ''takeOffline'' primitive notifies connected virtual machines when taking an object offline. Since AmbientTalk 2.12, the primitive not only notifies remote virtual machines, but it also notifies the local virtual machine where the ''takeOffline'' was executed so that if any inner actor has local far references to that object, it will also get notified. In other words, if an object is taken offline, all actors holding (local or remote) far references to it get notified. 
 +
 +These semantics is useful for unit test purposes. The [[appendix#unit_testing_framework|unit testing framework]] shipped with AmbientTalk has support for asynchronous test invocations which can be used to perform concurrent or distributed unit tests. In fact, distributed unit tests are simulated by means of concurrency, i.e. using different actors in your unit test which make use of the network facilities. However, distributed unit tests cannot simulate network disconnections by means of ''network.offline'' since the construct works at virtual machine level. In other words, ''network.offline'' simulates a network disconnection of a complete virtual machine, but what those tests need is to simulate the disconnection of a particular actor inside the virtual machine where they are running.
 +
 +By means of the ''takeOffline'' primitive, the intra-actor access to an object can be cut (independently if the actor is located within the same virtual machine or in a remote one),  enabling the simulation of the disconnection of an actor inside a virtual machine.
at/tutorial/distribution.1233221494.txt.gz · Last modified: 2009/01/29 10:33 (external edit)