Summary: Service reloading allows you to reload business logic without bringing down the Processing Unit.

Overview

The service reloading feature allows you to reload business logic (Spring beans) without bringing down the deployed Processing Unit. 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 in a very similar manner as the Space Mode Context Loader.

Service Reloading only works when downloading the processing unit to the GSC is disabled (pu.download deploy property should be set to false). For more information on how to do it, see here

Reloading 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 SpaceModeContextBean implements InitializingBean, DisposableBean {

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

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

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

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

<beans ... >

    <os-core:giga-space-context />

    <bean id="spaceModeContextBean" class="org.openspaces.example.data.processor.SpaceModeContextBean"/>
</beans>

This Spring XML file is a fully functional Spring definition and can hold several bean definitions, as well as other OpenSpaces components.

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

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

mode.xml has its parent application context set to the pu.xml, allowing it to access any bean defined in its parent pu.xml. Also, the refreshable-context-loader only starts if the space is in primary mode (when working with a remote space, it is always in primary mode).

Once this has been set, we need to execute the refresh operation on the modeExample bean. This can be done, for eample, with JMX. Built in the service reloading support is the ability to issue reloading using OpenSpaces sync remoting. This allows you to broadcast the reload operation to all active cluster members. Here is how this is configured:

<beans ...>

	<os-core:space id="space" url="/./space">
        <os-core:filter-provider ref="remotingServiceExporter"/>
    </os-core:space>

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

</beans>

Then, executing the reload command is as simple as:

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

As a result, the services are reloaded, and use new JAR definitions. In order to "install" the new JAR definitions, copy the changed JAR files to the Processing Unit deploy directory.

GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence