October 20th, Q&A session: Get you issues solved and questions answered!

GitHub logo
Edit

Services

Overview

A service is a piece of functionality that can be deployed to an Ignite cluster and execute specific operations. You can have multiple instances of a service on one or multiple nodes.

Ignite services have the following features:

Load balancing

In all cases, other than singleton service deployment, Ignite automatically makes sure that about an equal number of services are deployed on each node within the cluster. Whenever the cluster topology changes, Ignite re-evaluates service deployments and may re-deploy an already deployed service to another node for better load balancing.

Fault tolerance

Ignite always guarantees that services are continuously available, and are deployed according to the specified configuration, regardless of any topology changes or node crashes.

Hot Redeployment

You can use Ignite’s DeploymentSpi configuration to re-deploy services without restarting the cluster. See Re-deploying Services.

Ignite services can be used as a backbone of a micro-services based solution or application. Learn more about this use case from the following series of articles:

Refer to a service example implementation in the Apache Ignite code base.

Implementing a Service

A service implements the Service interface. The Service interface has three methods:

  • init(ServiceContext): this method is called by Ignite before the service is deployed (and before the execute() method is called)

  • execute(ServiceContext): starts execution of the service

  • cancel(ServiceContext): cancels service execution

Deploying Services

You can deploy your service either programmatically at runtime, or by providing a service configuration as part of the node configuration. In the latter case, the service is deployed when the cluster starts.

Deploying Services at Runtime

You can deploy services at runtime via the instance of IgniteServices, which can be obtained from an instance of Ignite by calling the Ignite.services() method.

The IgniteServices interface has a number of methods for deploying services:

  • deploy(ServiceConfiguration) deploys a service defined by a given configuration.

  • deployNodeSingleton(…​) ensures that an instance of the service is running on each server node.

  • deployClusterSingleton(…​) deploys a single instance of the service per cluster. If the cluster node on which the service is deployed stops, Ignite automatically redeploys the service on another node.

  • deployKeyAffinitySingleton(…​) deploys a single instance of the service on the primary node for a given cache key.

  • deployMultiple(…​) deploys the given number of instances of the service.

This is an example of cluster singleton deployment:

Ignite ignite = Ignition.start();

//get the services interface associated with all server nodes
IgniteServices services = ignite.services();

//start a node singleton
services.deployClusterSingleton("myCounterService", new MyCounterServiceImpl());

And here is how to deploy a cluster singleton using ServiceConfiguration:

Ignite ignite = Ignition.start();

ServiceConfiguration serviceCfg = new ServiceConfiguration();

serviceCfg.setName("myCounterService");
serviceCfg.setMaxPerNodeCount(1);
serviceCfg.setTotalCount(1);
serviceCfg.setService(new MyCounterServiceImpl());

ignite.services().deploy(serviceCfg);

Deploying Services at Node Startup

You can specify your service as part of the node configuration and start the service together with the node. If your service is a node singleton, the service is started on each node of the cluster. If the service is a cluster singleton, it is started in the first cluster node, and is redeployed to one of the other nodes if the first node terminates. The service must be available on the classpath of each node.

Below is an example of configuring a cluster singleton service:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">

    <property name="serviceConfiguration">
        <list>
            <bean class="org.apache.ignite.services.ServiceConfiguration">
                <property name="name" value="myCounterService"/>
                <property name="maxPerNodeCount" value="1"/>
                <property name="totalCount" value="1"/>
                <property name="service">
                    <bean class="org.apache.ignite.snippets.services.MyCounterServiceImpl"/>
                </property>
            </bean>
        </list>
    </property>

</bean>
ServiceConfiguration serviceCfg = new ServiceConfiguration();

serviceCfg.setName("myCounterService");
serviceCfg.setMaxPerNodeCount(1);
serviceCfg.setTotalCount(1);
serviceCfg.setService(new MyCounterServiceImpl());

IgniteConfiguration igniteCfg = new IgniteConfiguration()
        .setServiceConfiguration(serviceCfg);

// Start the node.
Ignite ignite = Ignition.start(igniteCfg);

Deploying to a Subset of Nodes

When you obtain the IgniteServices interface by calling ignite.services(), the IgniteServices instance is associated with all server nodes. It means that Ignite chooses where to deploy the service from the set of all server nodes. You can change the set of nodes considered for service deployment by using various approaches describe below.

Cluster Singleton

A cluster singleton is a deployment strategy where there is only one instance of the service in the cluster, and Ignite guarantees that the instance is always available. In case the cluster node on which the service is deployed crashes or stops, Ignite automatically redeploys the instance to another node.

ClusterGroup

You can use the ClusterGroup interface to deploy services to a subset of nodes. If the service is a node singleton, the service is deployed on all nodes from the subset. If the service is a cluster singleton, it is deployed on one of the nodes from the subset.

Ignite ignite = Ignition.start();

//deploy the service to the nodes that host the cache named "myCache"
ignite.services(ignite.cluster().forCacheNodes("myCache"));

Node Filter

You can use node attributes to define the subset of nodes meant for service deployment. This is achieved by using a node filter. A node filter is an IgnitePredicate<ClusterNode> that Ignite calls for each node associated with the IgniteService interface. If the predicate returns true for a given node, the node is included.

Caution
The class of the node filter must be present in the classpath of all nodes.

Here is an example of a node filter. The filter includes the server nodes that have the "west.coast.node" attribute.

public static class ServiceFilter implements IgnitePredicate<ClusterNode> {
    @Override
    public boolean apply(ClusterNode node) {
        // The service will be deployed on the server nodes
        // that have the 'west.coast.node' attribute.
        return !node.isClient() && node.attributes().containsKey("west.coast.node");
    }
}

Deploy the service using the node filter:

Ignite ignite = Ignition.start();

ServiceConfiguration serviceCfg = new ServiceConfiguration();

// Setting service instance to deploy.
serviceCfg.setService(new MyCounterServiceImpl());
serviceCfg.setName("serviceName");
serviceCfg.setMaxPerNodeCount(1);

// Setting the nodes filter.
serviceCfg.setNodeFilter(new ServiceFilter());

// Getting an instance of IgniteService.
IgniteServices services = ignite.services();

// Deploying the service.
services.deploy(serviceCfg);

Cache Key

Affinity-based deployment allows you to deploy a service to the primary node for a specific key in a specific cache. Refer to the Affinity Colocation section for details. For an affinity-base deployment, specify the desired cache and key in the service configuration. The cache does not have to contain the key. The node is determined by the affinity function. If the cluster topology changes in a way that the key is re-assigned to another node, the service is redeployed to that node as well.

Ignite ignite = Ignition.start();

//making sure the cache exists
ignite.getOrCreateCache("orgCache");

ServiceConfiguration serviceCfg = new ServiceConfiguration();

// Setting service instance to deploy.
serviceCfg.setService(new MyCounterServiceImpl());

// Setting service name.
serviceCfg.setName("serviceName");
serviceCfg.setTotalCount(1);

// Specifying the cache name and key for the affinity based deployment.
serviceCfg.setCacheName("orgCache");
serviceCfg.setAffinityKey(123);

IgniteServices services = ignite.services();

// Deploying the service.
services.deploy(serviceCfg);

Accessing Services

You can access the service at runtime via a service proxy. Proxies can be either sticky or non-sticky. A sticky proxy always connects to the same cluster node to access a remotely deployed service. A non-sticky proxy load-balances remote service invocations among all cluster nodes on which the service is deployed.

The following code snippet obtains a non-sticky proxy to the service and calls a service method:

//access the service by name
MyCounterService counterService = ignite.services().serviceProxy("myCounterService",
        MyCounterService.class, false); //non-sticky proxy

//call a service method
counterService.increment();

Un-deploying Services

To undeploy a service, use the IgniteServices.cancel(serviceName) or IgniteServices.cancelAll() methods.

services.cancel("myCounterService");

Re-deploying Services

If you want to update the implementation of a service without stopping the cluster, you can do it if you use the Ignite’s DeploymentSPI configuration.

Use the following procedure to redeploy the service:

  1. Update the JAR file(s) in the location where the service is stored (pointed to by your UriDeploymentSpi.uriList property). Ignite will reload the new classes after the configured update period.

  2. Add the service implementation to the classpass of a client node and start the client.

  3. Call the Ignite.services().cancel() method on the client node to stop the service.

  4. Deploy the service from the client node.

  5. Stop the client node.

In this way, you don’t have to stop the server nodes, so you don’t interrupt the operation of your cluster.