Reloading Business Logic

The service reloading feature allows you to reload business logic (Spring beans) without shutting down the application or undeploying a Processing Unit This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity.. In order to do this, any reloadable business logic needs to be defined in a special Spring XML file. The Spring XML file is then referenced very similar to the Space Mode Context Loader from inside the pu This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity..xml.

Configuring Reloadable Business Logic

Lets assume we have business logic that we would like to reload at some point in time after our Processing Unit has been deployed. Here is an example of such business logic:

public class RefreshableBean implements InitializingBean, DisposableBean {

    @GigaSpaceContext(name = "gigaSpace")
    private GigaSpace gigaSpace;

    public void afterPropertiesSet() throws Exception {
        System.out.println("BEAN LOADED, SPACE [" + gigaSpace + "]");
    }

    public void destroy() throws Exception {
        System.out.println("BEAN DESTROYED, SPACE [" + gigaSpace + "]");
    }
}

We then need to define it in a specific Spring XML file (lets assume it is named refreshable-beans.xml):

<beans>
    <os-core:giga-space-context />
    <bean id="refreshableBean" class="org.openspaces.example.data.processor.RefreshableBean"/>
</beans>

To enable service reloading, in our processing unit pu.xml file, we reference the refreshable-beans.xml file in the following manner:

<beans>
    <os-core:refreshable-context-loader id="refreshableExample" location="classpath:/META-INF/spring/refreshable-beans.xml"/>
</beans>

Above configuration will let you refresh the code defined in the refreshable context. Actual execution of this reloading of context can be done using OpenSpaces sync remoting, which allows you to broadcast the reload operation to all active cluster members. Here is how this is configured:

<beans>
    <os-remoting:service-exporter id="remotingServiceExporter">
        <os-remoting:service ref="refreshableExample"/>
    </os-remoting:service-exporter>

</beans>

Reloading Business Logic

When there is a change in business logic for any beans defined in the refreshable context and these changes are ready to be applied to the cluster, copy the new classes into the GigaSpaces deploy folder of GSM Grid Service Manager. This is is a service grid component that manages a set of Grid Service Containers (GSCs). A GSM has an API for deploying/undeploying Processing Units. When a GSM is instructed to deploy a Processing Unit, it finds an appropriate, available GSC and tells that GSC to run an instance of that Processing Unit. It then continuously monitors that Processing Unit instance to verify that it is alive, and that the SLA is not breached. machine(s) and work folder of each cluster node (default location, <GigaSpacesRoot>/work/processing-units/<puInstance>) and execute the reload command as below:

java -cp [list of jar files, including JSpace, openspaces and spring] RefreshContextLoaderExecutor jini://*/*/space

As a result of the above command, all the beans defined in the refreshable context are destroyed and fresh copies of these beans are re-created using the new class definitions in the work folder. Your new version of business logic is now ready without brining down the cluster.

Other Considerations

• Refreshable context works only for business logic changes. You cannot modify the data model using this approach.
• Any beans defined in the refreshable context should be designed to properly exit without leaving any threads in unreachable state. Implementing Spring InitializingBean and DisposableBean interface (or equivalent annotation) is a good design practice and any initializing code and clean up should be invoked from the afterPropertiesSet and destroy methods.