ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Artёm Basov <basov.ar...@gmail.com>
Subject Re: Async Service proxy
Date Tue, 11 Jul 2017 12:31:46 GMT
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.

Mime
View raw message