[
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)
