at:tutorial:distribution
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
at:tutorial:distribution [2009/01/28 11:25] – elisag | at:tutorial:distribution [2009/01/29 15:10] – revision elisag | ||
---|---|---|---|
Line 3: | Line 3: | ||
Building on the actor-based concurrency model explained in the [[actors|previous chapter]], this chapter discusses the distribution provisions of AmbientTalk. For actors to communicate across the boundaries of a single device, actors need to be capable of discovering one another' | Building on the actor-based concurrency model explained in the [[actors|previous chapter]], this chapter discusses the distribution provisions of AmbientTalk. For actors to communicate across the boundaries of a single device, actors need to be capable of discovering one another' | ||
- | These requirements correspond to the cornerstones of the Ambient-Oriented Programming paradigm. The seamless integration of language support for dealing with partial failures and performing service discovery, hinge on AmbientTalk' | + | These requirements correspond to the cornerstones of the Ambient-Oriented Programming paradigm. The seamless integration of language support for dealing with partial failures and performing service discovery, hinge on AmbientTalk' |
Before delving in these topics, we illustrate how to activate the network facilities of AmbientTalk in the next section. | Before delving in these topics, we illustrate how to activate the network facilities of AmbientTalk in the next section. | ||
Line 63: | Line 63: | ||
As '' | As '' | ||
- | ===== Partial Failure Handling | + | ===== Dealing with Transient Failures |
- | Let us consider again the example instant messenger application described in previous section to further explain the semantics of AmbientTalk' | + | Let us consider again the example instant messenger application described in previous section to further explain the semantics of AmbientTalk' |
When an object discovers a service type, the '' | When an object discovers a service type, the '' | ||
Line 106: | Line 106: | ||
The function '' | The function '' | ||
- | ===== Garbage collecting | + | ===== Dealing with Permanent Failures ===== |
+ | |||
+ | As explained in the previous section, | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ====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 // | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | ====Working with leased object references==== | ||
+ | |||
+ | The code snippet below illustrates a leased far reference in the context of an online shopping application. In the example, a client object can ask a server to start a shopping session by sending it the '' | ||
+ | |||
+ | < | ||
+ | def openSession() { | ||
+ | def shoppingCart := Cart.new(); // to store purchased items | ||
+ | def session := object: { | ||
+ | def addItemToCart(anItem) { ... } | ||
+ | def checkOutCart() { ... } | ||
+ | }; | ||
+ | def leasedSession := lease: minutes(5) for: session; | ||
+ | leasedSession; | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | The '' | ||
< | < | ||
- | This is an advanced topic and probably does not belong in the tutorial. Moreover, it discusses features | + | We assume |
</ | </ | ||
- | As explained in the previous section, AmbientTalk' | + | At client side, a customer can ask a server |
< | < | ||
- | takeOffline: object | + | def mySession |
+ | ... | ||
+ | mySession< | ||
</ | </ | ||
- | The construct removes from the export table of the actor where the code is executed | + | The future attached to the '' |
+ | |||
+ | < | ||
+ | renew: mySession for: minutes(5); | ||
+ | revoke: mySession; | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | When no renewal is performed due to a network partition outlasting | ||
+ | |||
+ | < | ||
+ | when: mySession expired: { | ||
+ | ... // free up resources used by this session e.g. the cart | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | The construct takes as parameters a leased reference | ||
+ | |||
+ | ====Leasing patterns==== | ||
+ | As is the case in other leasing mechanisms, determining the proper lease renewal period is not straightforward and may even depend on system parameters such as the number | ||
+ | |||
+ | The first variant is a // | ||
+ | by the remote object. In other words, as long as the client uses the remote object, the leased reference is transparently renewed by the interpreter. | ||
+ | |||
+ | < | ||
+ | def openSession() { | ||
+ | def shoppingCart := Cart.new(); // to store purchased items | ||
+ | def session := object: { | ||
+ | def addItemToCart(anItem) { ... } | ||
+ | def checkOutCart() { ... } | ||
+ | }; | ||
+ | def leasedSession := renewOnCallLease: | ||
+ | leasedSession; | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | Similar to '' | ||
+ | |||
+ | The second variant is a // | ||
+ | |||
+ | < | ||
+ | def myObject: = object:{ | ||
+ | ... | ||
+ | }; | ||
+ | def leasedObject := singleCallLease: | ||
+ | </ | ||
+ | |||
+ | Similar to the other two constructs, '' | ||
+ | |||
+ | ====Integrating leasing with future-type message passing==== | ||
+ | |||
+ | Single-call leases are useful for objects adhering to a single call pattern, such as callback objects. Callback objects are often used in asynchronous message passing schemes in order for remote object to be able to return values. These callback objects are typically remotely accessed only once by remote objects with the computed return value. In AmbientTalk, | ||
+ | |||
+ | We have integrated leasing into futures by parameter-passing a future attached to an asynchronous message via a singe-call lease which either expires due to a timeout or upon the reception of the computed return value. The timeout for the implicit single-call lease on a future can be set by annotating the asynchronous message with a '' | ||
+ | |||
+ | < | ||
+ | def sessionFuture := server< | ||
+ | when: sessionFuture becomes: { |session| | ||
+ | // open session with server | ||
+ | }catch: TimeoutException using: { |e| | ||
+ | // unable to open a session, do some clean-up if necessary | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | If the future is resolved, the session variable stores a leased object reference to the remote session object. | ||
< | < | ||
- | As you may have noticed, | + | Note that specifying a '' |
</ | </ | ||
- | On the client side, taking offline an object | + | ====Importing leased |
+ | Similar to futures, leased object references have been built reflectively on top of AmbientTalk. | ||
+ | |||
+ | To use the language constructs for leased references, you should import the leasedref module as follows: | ||
< | < | ||
+ | import / | ||
+ | </ | ||
+ | < | ||
+ | leasedrefs module exports support primitives to manipulate time intervals (i.e. '' | ||
+ | </ | ||
+ | |||
+ | More information pertaining to the API of the leased references language module can be found in the appendix. | ||
+ | |||
+ | ===== Taking offline remote objects ===== | ||
+ | |||
+ | AmbientTalk distributed memory management scheme has been based on reference listing and network objects. Similar to these techniques, remote far references are implemented by means of a proxy at client-side, | ||
+ | |||
+ | As previously explained, in order to deal with volatile connections, | ||
+ | |||
+ | < | ||
+ | takeOffline: | ||
+ | </ | ||
+ | |||
+ | 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's 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, the remote far references is invalid. | ||
+ | |||
+ | < | ||
+ | Leased object references make use of the takeOffline: | ||
+ | </ | ||
+ | |||
+ | ====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 '' | ||
+ | |||
+ | Additionally, | ||
+ | |||
when: messenger takenOffline: | when: messenger takenOffline: | ||
system.println(" | system.println(" | ||
//clean certain resources associated to the buddy | //clean certain resources associated to the buddy | ||
}; | }; | ||
- | </ | ||
- | 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 collector. As a result, the disconnected and reconnected observers will be no longer trigger for such remote reference. | ||
- | Note that disconnection, | + | 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. '' |
+ | |||
+ | < | ||
+ | Disconnection, reconnection and takenOffline observers can be also installed for the inter-actor far references. Such inter-actor far references are local to a virtual machine and as such, network failures cannot happen. In that case, the disconnected | ||
+ | </ | ||
+ | |||
+ | ====Distributed unit testing and '' | ||
+ | |||
+ | As previously mentioned, the '' | ||
+ | This semantics are useful for unit test purposes. The unit testing framework shipped with AmbinentTalk has support to perform asynchronous invocations which can be used to perform concurrent or distributed unit tests. However, distributed unit tests couldn' | ||
< | < | ||
The complete implementation of the instant messenger application explained along this chapter can be found in the file '' | The complete implementation of the instant messenger application explained along this chapter can be found in the file '' | ||
</ | </ |
at/tutorial/distribution.txt · Last modified: 2009/01/30 16:13 by tvcutsem