Re: [ecf-dev] Remote service question

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Halvard,

On 10/20/2014 12:41 AM, Hallvard Trætteberg wrote:
> Hi,
>
> 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)
V
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)
V
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.

Thanks,

Scott