[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Remote service question

Hi Halvard,

On 10/20/2014 12:41 AM, Hallvard Trætteberg wrote:

A comment on async remote calls: There are two sides to this, the caller side and callee side. The caller side is nicely handled with the CompletableFuture, since it allows you to register a one-time callback. But what if the callee side also needs to be async?

In my case, the service is implemented on a server side Eclipse, and its task is to update one or more Eclipse resources and return the problem markers that appear after the build. The method is something like the following:
Collection<Problems> updateResources(Collection<ResourceUpdates)).
The service implementation needs to update the resources and then wait for a listener to be notified about the changes to the problem markers attached to the same resources. Hence, the service implementation is also async, since it needs to wait for a value that will later be made available from a different thread. I can use wait and notify to handle this, but would rather use a CompletableFuture. I.e. the service method would be changed to CompletableFuture<Collection<Problems>> updateResources(Collection<ResourceUpdates)) and then the service implementation could immediately return a CompletableFuture and later call complete. My question is, can the callee end of a remote service handle this, i.e. receive a CompletableFuture from a service implementation method and wait for the value to appear?

On the callee side (aka remote service host), typically what happens (i.e. for most remote service distribution providers) is that a new thread is created to synchronously call the remote service method. So, for example

(again on the callee/RS host side)

RS consumer/client/caller
| (network)
Remote Call arguments are unmarshalled
A thread is created
New thread calls the remote service method...e.g:
Collection<Problems> updateResources(Collection<ResourceUpdates))
The return value is marshalled
|  (network)
RS consumer/client/caller

The use of a new thread (or rather a thread pool in most cases)to implement the actual service method call means that call may block for as long as desired to produce a Collection<Problems> for delivery back to the RS consumer, without affecting/blocking other calls or anything else that the host process is doing.

Unless I'm misunderstanding you, the implementation of the service method can/could create a CompletableFuture, wait for any asynchronous operations to complete, create the associated Collection<Problems> and then simply return the Collection<Problems> to the distribution system for marshalling and delivery back to the caller. Since the distribution system creates a thread to execute the callee service method, this is already asynchronous. Would this give you want you want?

It's also possible with ECF's implementation to create a new distribution provider (or just customize an existing one) such that the *distribution system* uses CompletableFuture as you describe to do things asynchronously on the RS host/callee, rather than create a new thread as the existing providers do/described above. That's perhaps a little more work though, so before we talk about that I should make sure that I'm interpreting correctly what you are wanting to do.