I'm interested in using Ignite services as microservices and have seen Denis'
blog posts on the topic. In my case, I also have a requirement to perform
computations with data affinity. My idea is to call a node singleton service
locally from a distributed compute task.
The advantage of using the service is that it can spring-wire itself at
deployment time. A task may then result in the collaboration of a number of
local services to generate a result.
I have tried this and it seems to work well. My question is about updating
and versioning of services. In particular - is it possible to use the
DeploymentSpi with a specified classloader to deploy two different versions
of the same service - presumably registered with different service names? Or
is this designed only to work for tasks?
Thanks for this. I'll keep an eye on that ticket - it seems to be exactly
what we are looking for.
In the meantime, we think we have a work-around. Does the following sound
viable, or do you think it might it cause problems?
* Create a custom intercepting ClassLoader
* Start Ignite by directly calling IgnitionEx.start(URL springCfgUrl,
@Nullable ClassLoader ldr)
* Create the service instance using the new ClassLoader and deploy the
service as a node singleton.
* Ignite re-instantiates the service - but this is now handled by our
intercepting ClassLoader too. The ClassLoader ensures that the correct
version of the service class is loaded from the appropriate jar.
For the moment, we will use the service name to distinguish between versions
- though, as per the jira ticket, an explicit version number would be