...
Currently when service implementation or configuration changes, you can't make existing instances be redeployed without manual undeployment. GridServiceProcessor
has access to the serialized representation of services only, so it can't tell, if anything have changed since previous deployment.
This section contains a description of the proposed service deployment protocol.
...
Once all deployment results are collected, coordinator sends another discovery message, notifying all nodes about successful deployment. This is the moment, when deployment futures are completed and the control is returned from IgniteServices#deploy*
methods. Also Service#execute()
method starts its work on successful deployment message arrival.
After that all nodes persist service configurations to the meta-space, so deployed services will live through cluster restarts.
...
...
When a new node connects to the existing cluster, all needed services are deployed and initialised on it by the time it is accepted to the topology.
This is what happens, when a new node joins the cluster:
Nodes also store deployment counter for each service in meta-space. It shows, how many times a service has been undeployed or redeployed. It will help in situations, when a joining node has some persisted services, that are missing on other nodes. This way undeployed services won't be brought back by the nodes, that were killed before the undeployment happened.
It should be possible to update service implementation or configuration without downtime. Introduction of a service version Employment of Deployment SPI should solve this problem.
ServiceConfiguration
class should contain integer version
parameter, that will increase monotonically between deployments.
When a node is processing a service deployment request, it performs deployment only if it doesn't have a deployed service of the same or a newer version.
Service version update implies classes redeployment. So, user is responsible for configuring a proper DeploymentSpi to be able to replace service classes at runtime. Service processor should unregister and re-register a service class, when version update happens.
[In progress]
TBD
Service processor should subscribe to class deployments and restart corresponding services, when their classes change.
The basic usage scenario involves enabling UriDeploymentSpi and updating the JAR files, containing implementation classes. It will lead to existing services cancellation and reployment. It implies, that services should be ready to sudden cancellations. Documentation should contain explanation of this fact with examples.
These changes will break compatibility with previous versions of Apache Ignite completely.
There is another flaw in current service grid design. Suppose, we have one server node, and we deploy several cluster-singleton services on it.
If you add more nodes to it, then service instances won't be moved to them, so the only node will be serving all the requests. This situation should be solved by proper service rebalancing.
Changes, described in current IEP don't interfere with service rebalancing in any way, so we can do it as a separate task after the proposed changes are implemented.
Service grid redesign: http://apache-ignite-developers.2346864.n4.nabble.com/Service-grid-redesign-td28521.html
...
Jira | ||||||
---|---|---|---|---|---|---|
| ||||||
Jira | ||||||
server | ASF JIRA | |||||
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b | key | IGNITE-975
,