Async Service proxy

[Artёm Basov <ba...@gmail.com>]

Hi guys!

Is there any ways to keep asynchronous nature of ignite Service proxy
implementation?

The main reason for us to use Services over plain Compute is that we need to
spread logic in separate JVM or else we would have to do tedious refactoring
in order to avoid dll hell (we use JNI extensively).

It looks like under the hood it uses IgniteFuture but"blocks for us". Is
there are particular reason for blocking on future.get() ?



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Async-Service-proxy-tp14478.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Async Service proxy

[vkulichenko <va...@gmail.com>]

I think creating your own pool on client side is the easiest way to support
you case.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Async-Service-proxy-tp14478p15022.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Async Service proxy

[Artёm Basov <ba...@gmail.com>]

Thank again, Val

I have got the answer, but will write more info about our use-case, since it
might be useful for someone in the future.

We need to return value, but it will take some time (seconds, minutes) to
process those requests. The IgniteServices gives us decoupling from
knowledge about concrete implementations of MyService (see below). Here is
how we currently use it:

private void service(Job job) {
        List<Response> responses = ignite.services().serviceDescriptors()
                .stream()
                .filter(sd ->
MyService.class.isAssignableFrom(sd.serviceClass()))
                .map(sd ->
ignite.services().<MyService>serviceProxy(sd.name(), MyService.class,
false))
                .map(service -> service.service(job))
                .collect(Collectors.toList());
    // processing of request
}

Response, MyService just common interfaces which any new Plugin might
implement and start it's own ignite node.
Is it valid usage of the API ?

In this example, we pretty much blocked in service.service(job) for whole
duration of processing. This means. that we should decouple that code from
producer of the jobs. So it's either our own ThreadPool or Ignite's services
pool. Since there is no way to utilize Ignite pool, we either should
introduce our own or use IgniteCompute.

With IgniteCompute we will have to somehow reproduce the ServiceDeployments
thing, since broadcast() is too much (we want only 1 service instance to be
processing this job).

Thanks for your time!



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Async-Service-proxy-tp14478p14627.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Async Service proxy

[vkulichenko <va...@gmail.com>]

Artem,

The whole point of service proxy is to allow remote execution via API that
*you* created. Therefore, if this API returns some result, this can be done
only synchronously. In case there is no result, you can trigger async
execution within the service itself and return right away. Another option is
to use Compute Grid APIs directly.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Async-Service-proxy-tp14478p14494.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.