Summary: Explains how to run your processing unit inside your IDE or in unit tests
OverviewAs part of your development process, you may want to run/debug your processing unit within your IDE, or create unit tests (with JUnit for example) to tests in isolation certain aspects of it. The Integrated processing unit container allows you to run a processing unit within such "embedded" environment. It's implementation class is org.openspaces.pu.container.integrated.IntegratedProcessingUnitContainer. The Integrated Processing Unit Container is built around Spring's ApplicationContext with several extensions relevant to GigaSpaces, such as ClusterInfo. The Integrated Processing Unit Container runs directly in your IDE using its main() method, or can be started by another class in your code by using the ProcessingUnitContainerProvider abstraction. Executable IntegratedProcessingUnitContainerThe IntegratedProcessingUnitContainer class provides an executable main() method, allowing the IDE to run it directly via a simple Java application configuration. The main() method uses the IntegratedProcessingUnitContainerProvider class and program arguments in order to create the IntegratedProcessingUnitContainer. The following is a list of all the possible program arguments that can be specified to the IntegratedProcessingUnitContainer:
ExampleTo run a clustered PU with an embedded space with 2 partitions and a backup for each partition , having a separate eclipse configuration (and a hosting JVM) for each cluster member , have 3 run configuration each have the following:
Run Config Primary partition 1
-cluster schema=partitioned-sync2backup total_members=2,1 id=1
Run Config Primary partition 2
-cluster schema=partitioned-sync2backup total_members=2,1 id=2
Run Config Backup partition 1
-cluster schema=partitioned-sync2backup total_members=2,1 backup_id=1 id=1
Run Config Backup partition 2
-cluster schema=partitioned-sync2backup total_members=2,1 backup_id=1 id=2 Start these using the order above. The first 2 will be primary members and the other two will be backup members.
Using IntegratedProcessingUnitContainer in the IDEThe main usage of the IntegratedProcessingUnitContainer is to execute processing units in your IDE. In the screenshot above, we run the data processor module using the integrated processing unit container from within the Eclipse IDE (we simply imported the Eclipse project provided with the example into our Eclipse workspace). There are no arguments provided in this example, which means that the integrated processing unit container will use its defaults. Since our project source includes a META-INF/spring/pu.xml file, it is automatically detected by the IntegratedProcessingUnitContainer class and used as the processing unit's deployment descriptor (since it's part of the processor module's classpath). The processor Eclipse project also has all the required libraries in its project definition. These include all the jars located under the GigaSpaces root>/lib/required directory, namely gs-openspaces.jar, gs-runtime.jar, commons-logging.jar and the Spring framework jars (all start with com.spring*), so the integrated processing unit container is running with these libraries.
The following screenshot shows how to run a data processor instance with a partitioned cluster schema and ID 1, and the arguments that should provided in this configuration:
Starting an IntegratedProcessingUnitContainer ProgrammaticallyThe integrated processing unit container can be created programmatically using the IntegratedProcessingUnitContainerProvider class. This is very useful when writing unit and integration tests (though Spring's own mock library can also be used for testing using pure Spring application context). Here is an example of using a IntegratedProcessingUnitContainerProvider in order to create one: IntegratedProcessingUnitContainerProvider provider = new IntegratedProcessingUnitContainerProvider(); // provide cluster information for the specific PU instance ClusterInfo clusterInfo = new ClusterInfo(); clusterInfo.setSchema("partitioned-sync2backup"); clusterInfo.setNumberOfInstances(2); clusterInfo.setInstanceId(1); provider.setClusterInfo(clusterInfo); // set the config location (override the default one - classpath:/META-INF/spring/pu.xml) provider.addConfigLocation("classpath:/test/my-pu.xml"); // Build the Spring application context and "start" it ProcessingUnitContainer container = provider.createContainer(); // ... container.close();
Remote DebuggingThe Java DebuggerThe Java Debugger (jdb) is a dynamic, controlled, assignment-based debugging tool. It helps find and fix bugs in the Java language programs both locally and on the server. To use jdb in a Java application you must first launch it with debugging enabled and attach to the Java process from the debugger through a JPDA port (Default port is 1044). The default JPDA options for Java applications are as follows: -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 The jdb parameters specify the way the debugger will operate. For instance transport=dt_socket instructs the JVM that the debugger connections will be made through a socket while the address=1044 parameter informs it that the port number will be 1044. Similarly, if you substitute suspend=y , the JVM starts in suspended mode and stays suspended until a debugger is attached to it. This may be helpful if you want to start debugging as soon as the JVM starts. Debugging your applicationDebugging your application running within the GSC is no different than debugging any other Java application. You need to make sure to launch the GSC with the required debugging arguments and attach a debugger. You should use the GSC startup script found within the GigaSpaces root/bin folder to run it in debug mode. 1. Add the following variable IDE_REMOTE_DEBUG and set the GSC_JAVA_OPTIONS to use it:
Linux
export IDE_REMOTE_DEBUG="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y"
export GSC_JAVA_OPTIONS=$IDE_REMOTE_DEBUG
Windows set IDE_REMOTE_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y set GSC_JAVA_OPTIONS=%IDE_REMOTE_DEBUG% If you would like to specify a specific listening port, use the address parameter: set IDE_REMOTE_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 2. Next, start a GSC:
Linux
./gsc.sh Windows gsc.bat Make sure you see the Listening for transport dt_socket at address message: D:\gigaspaces-xap-premium-8.0.1-ga\bin>gsc.bat
Listening for transport dt_socket at address: 8000
3. Open your eclipse and setup a remote debug configuration: Make sure you place the right host name and port. 4. Set a break point. 5. Click the Debug button. |
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |