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

Scott,

Comments inline below:

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?

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. ... 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?

Yes, I think this is a solution. Actually, if the callee has its own thread, I think an ordinary Future will be enough. The service implementation will create the Future, register a listener that will wait for the build result, and call get on the Future. This will make it block, which is what we want, since this thread has nothing else to do than wait. Then, when the listener is notified (in a different thread), it will put the result into the Future, thereby releasing that thread and effectively returning the result. If I understand the mechanism, that is.


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.

Yes, this was what I was thinking of. The advantage is that the framework does a bit more for you, and you 'reuse' the async interface that you already defined for the caller. But I agree, it might be worth it, since the 'manual' approach you outline above, should be easy enough (if my understanding is correct, that is).


Hallvard
--
Hallvard Traetteberg, Associate Professor
Dept. of Computer and Information Sciences (IDI)
Norwegian University of Science and Technology (NTNU)