Are there any plans to make peer class loading work for deployed services?
When I try to deploy a service WITHOUT copying the service's jar file to every node, I get an exception from the nodes saying that it can't find the service class. The documentation says peer class loading works for compute tasks, which I verified, but why not for service classes as well?
The use case I have is for updating the implementation of a running service to improve its performance without having to restart any nodes, thereby allowing clients to continue processing and gain efficiencies at runtime.
If this is not possible, then the only way to deploy an updated implementation is to shut all the nodes down, copy the updated jar, and start the cluster up again? Perhaps I could make the service execute as a compute task where the efficiency logic can exist in the compute task.... Any thoughts?
So I tried to make my service call a compute task in hopes of the Peer class loading of compute tasks to automatically download an updated version of the implementation, but it didn't work. Seems like the class loader used for Services is completely different than the one for ComputeTasks.
So there really is no way to update a service implementation, or even to "deploy" a new service without having to shut the entire cluster down, manually copy over jar files to every node, and then restart the cluster? Is there at least a quick way to do this through an Ignite shell command?
Currently peer-deployment is not supported for services. But we have this feature on the roadmap: https://issues.apache.org/jira/browse/IGNITE-1160. It will allow to dynamically deploy new classes on remote nodes before executing services, starting caches, etc.
Now you will have to stop the nodes and deploy manually. I would recommend to take a look at Visor command-line utility, which has the following commands that can be helpful in your case:
- start - starts or restarts the nodes locally or on remote hosts via SSH
- kill - stops existing nodes
- deploy - copies files (JARs, etc.) to remote nodes
Ok thanks Val. Btw, during testing I noticed that because of this issue, if I had a node in my cluster that did not have the proper jar file deployed to, and the current node the service was running on went down, if Ignite tried to re-instantiate the cluster singleton service on the node that didn't have the right jar, it would throw exception and hang, thereby never being able to re-instantiate that service on another node. This behavior breaks the guarantee that Ignite will always have an instance of the service running despite topology changes. For now it may be enough to make special note in the documentation that this service up guarantee is only valid if all dependent jars have been manually deployed to each node in the cluster.