ActiveEon » Integration http://www.activeeon.com ActiveEon is your dedicated technology partner for accelerating and scaling up your enterprise applications. Mon, 16 Jan 2012 14:37:20 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 Sunflow distributed rendering with ProActive Scheduler http://www.activeeon.com/blog/all/integration/sunflow-distributed-rendering-with-proactive-scheduler http://www.activeeon.com/blog/all/integration/sunflow-distributed-rendering-with-proactive-scheduler#comments Fri, 14 Aug 2009 16:34:44 +0000 admin http://exp.activeeon.com/?p=411 sunflow-logoSunflow is an open source rendering engine for photo-realistic image synthesis. Its integration with the ProActive Scheduler system enables an easy-to-use distributed rendering of 3D models.

Main Features

  • Fully Java Open Source
  • Easy installation and minimal configuration
  • Direct integration into the Sunflow GUI
  • Automatic file-transfer management
  • Fault-Tolerance

Description

This integration makes the installation and usage as simple as possible but here is a little explanation for minimal understanding. If you are already familiar with the ProActive Scheduler concepts skip this section.

Executions of parallel tasks on distributed resources (what we call ‘nodes’), such as networks of desktops or clusters, require a main system for managing resources and handling task executions. The ProActive Scheduler is connected to a Resource Manager providing the resource abstraction and enables users to submit jobs, containing one or several tasks that will be executed on available resources. A job is the entity to be submitted to the scheduler. It is composed of one or more tasks. The task is the smallest schedulable entity, it is included in a job and will be executed in accordance with the scheduling policy on the available resources. For more information you can consult the official ProActive Scheduler documentation.

For the management and advanced control of the Scheduler a remotely connectable GUI is available that offers additional interactions and statistics (a console admin client is also available). Please refer to the Scheduler GUI documentation. Same kind of GUI is available for the Resource Manager, please refer to the Resource Manager GUI documentation.

distributed-rendering-architecture_medium

Figure 1: Distributed rendering architecture

The Sunflow scene is decomposed into a fixed number of buckets, then each bucket can be rendered independently from the others. A single bucket rendering process is formulated as a task, therefore the whole scene can be seen as a job. However, the user can increase the number of buckets to be rendered per a single task.

Once a remote task is finished, it is sended back through the Scheduler to the Sunflow engine and appears on main screen immediately.

scene_decomposition

Figure 2: Example of 6 buckets per task decomposition

If you look at the figure 2 you can see that the scene is roughly decomposed into 60 buckets, with 6 buckets per task the job will have 10 tasks. This is almost the perfect decomposition if there are 10 computing nodes, since it will require only 10 communications because by default the Scheduler will try to use all available resources. However, if you would like to watch intermediate results in real time and this way be able to quickly detect obvious incorrectness and to cancel the on-going rendering process, simply decrease the number of buckets per task. Depending on the complexity of the scene and resources availaibility, the user can change the bucket/task ratio directly from the Sunflow GUI.

Detailed Features

  • The source code is included in the modified sunflow.jar archive.
  • The user can submit/cancel a job and change the number of buckets per task directly from the Sunflow GUI.
  • The user doesn’t need to specify required files (textures, bump maps, images etc.) manually, the rendering tasks will dowload missing files automatically.
  • The ProActive Scheduler offers resource fault-tolerance by using a database to store activities. For example, if a resource shuts down during a rendering process the rendering task will be executed elsewhere.

Be sure to have at least Java SE 5 installed on any computer you want to use. The JDK is required, because the Scheduler uses the database only available in the JDK bundle. You can get the latest release of Java SE from the official Java web site.

Downloads

Installation, Configuration and Execution for Windows Users

  • From the command-line, go to the Scheduler bin\windows directory and run the startScheduler_newDB.bat script to start the Scheduler with an embedded Resource Manager once started it will print its URL
  • There are 2 way to create computing nodes on remote computers:
    • First way is to install the ProActive Agent on each computer that you want to use for computation and configure it (double-click on agent tray icon and click on GUI Edit button), you can save the configuration and load it on another computer:
      1. In the General tab set the ProActive Location field to the Scheduler directory
      2. In the Connection tab select Resource Manager Registration as Enabled Connection
      3. Fill the Resource Manager URL field with the url of the Resource Manager like rmi://HOSTNAME_OR_IP_ADDRESS:1099/
      4. Fill the Node Name field with for example “workerNode”
      5. Use “demo” for both Username and Password fields
      6. Save the configuration, close it and start the agent
    • Second way is to start a computing node from command-line from Scheduler bin\windows directory by running the startNode.bat <NODE_NAME> then adding the url of the node to the Resource Manager through the Resource Manager GUI or the admin client.
  • Start the modified version of Sunflow from command-line by running the run_sunflow.bat <SCHEDULER_HOME> the parameter must be the absolute path of the Scheduler, from the Sunflow GUI select an example scene then in case of distributed rendering enter the URL of the Scheduler and use “demo” for both username and password.

Installation, Configuration and Execution for Linux Users

  • From the command-line go to the Scheduler bin\unix directory and run the startScheduler_newDB.sh script to start the Scheduler with an embedded Resource Manager
  • There are 2 ways to create computing nodes on remote computers:
    • Start a computing node from command-line by running $SCHEDULER_HOME/bin/unix/startNode.sh <NODE_NAME> then add the url of the node to the Resource Manager through the Resource Manager GUI
    • Deploy several computing nodes by using a GCM Deployement Descriptor

Example

rendered-julia

Figure 3: The rendered julia.sc scene

For example the distributed rendering of the julia.sc (see figure 3) scene using a completely heterogeneous infrastructure composed of 1 qual-core Windows XP (4 computing nodes) , 1 dual-core Windows Vista (2 computing nodes), 1 dual-core MacBook (2 computing nodes) and 1 dual-core Linux (2 computing nodes) is enough to significantly reduce the computing time.

rendering_times_classic_vs_distributed_-_julia_sc

]]> http://www.activeeon.com/blog/all/integration/sunflow-distributed-rendering-with-proactive-scheduler/feed 0 Distribute a Spring Batch job on the Proactive Scheduler http://www.activeeon.com/blog/all/integration/distribute-a-spring-batch-job-on-the-proactive-scheduler http://www.activeeon.com/blog/all/integration/distribute-a-spring-batch-job-on-the-proactive-scheduler#comments Mon, 25 May 2009 10:06:50 +0000 emil salageanu http://exp.activeeon.com/?p=429 partitionning_scheduler1

As its name states, this article describes the steps to perform in order to have the execution of Spring Batch job processed remotely on an infrastructure managed by the ProActive Scheduling platform.
The solution presented is based on Spring Batch Partitioning; you should take a look at section 7.4. Partitioning in the Spring Batch Documentation.

Here’s the schema from the spring batch documentation:

Spring BatchPartitioning Overview
Spring BatchPartitioning Overview
If you have not already done it, you should download spring batch from http://www.springsource.org/download and ProActive Scheduling from http://www.activeeon.com (you should download the Scheduling Project and eclipse RCPs (the Graphical clients).
This article is based on spring batch 2.0.0 Release and the Scheduling 1.1 release.

Part 1 – Implementation

Start Point

The job I have used for this purpose, as a start point, is the job defined in
org.springframework.batch-2.0.0.RELEASE/sources/org.springframework.batch.core/ src/test/resources/org/springframework/batch/core/partition/launch-context.xml

This spring-batch example job is composed by:

  • simple hello world ItemReader and ItemWriter
    (org.springframework.batch.core.partition.ExampleItemReader
    and org.springframework.batch.core.partition.ExampleItemWriter)
  • a Simple Job implementation (org.springframework.batch.core.job.SimpleJob)
  • a partition step (org.springframework.batch.core.partition.support.PartitionStep) – this is used as implementation for the master step
  • a step execution splitter, used by the partition step (org.springframework.batch.core.partition.support.SimpleStepExecutionSplitter)
  • A PartitionHandler, also used by the Partition Step (org.springframework.batch.core.partition.support.TaskExecutorPartitionHandler)

Bellow, the xml file which defines this job, taken from

org.springframework.batch-2.0.0.RELEASE/sources/org.springframework.batch.core/ src/test/resources/org/springframework/batch/core/partition/launch-context.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:p="http://www.springframework.org/schema/p" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd">
<import resource="classpath:/org/springframework/batch/core/repository/dao/data-source-context.xml" />
<bean id="job1" parent="simpleJob">
<property name="steps">
<bean name="step1:master">
<property name="partitionHandler">
<bean>
<property name="taskExecutor">
<bean />
</property>
<property name="step" ref="step1" />
<property name="gridSize" value="2" />
</bean>
</property>
<property name="stepExecutionSplitter">
<bean>
<constructor-arg ref="jobRepository" />
<constructor-arg ref="step1" />
</bean>
</property>
<property name="jobRepository" ref="jobRepository" />
</bean>
</property>
</bean>
<bean id="step1" parent="simpleStep">
<property name="itemReader">
<bean scope="step"></bean>
</property>
<property name="itemWriter">
<bean />
</property>
</bean>
<bean id="simpleJob" abstract="true">
<property name="jobRepository" ref="jobRepository" />
<property name="restartable" value="true" />
</bean>
<bean id="simpleStep" abstract="true">
<property name="transactionManager" ref="transactionManager" />
<property name="jobRepository" ref="jobRepository" />
<property name="startLimit" value="100" />
<property name="commitInterval" value="1" />
</bean>
<bean id="jobLauncher">
<property name="jobRepository" ref="jobRepository" />
</bean>
<bean id="jobRepository" p:databaseType="hsql" p:dataSource-ref="dataSource" p:transactionManager-ref="transactionManager" />
<bean />
</beans>

Modify the example partition job to distribute it on the ProActive Scheduler

The ProActive Scheduler offers a java API in order to allow users to create, submit jobs on the scheduler and gather the results. See full documentation and tutorial at http://proactive.inria.fr/release-doc/scheduler/multiple_html/index.html

In order to run a job on the Proactive Scheduler we have to create a specific PartitionHandler.
I’ll call this class ProactiveSchedulerPartitionHandler.

In odrer to implement this class, I took the org.springframework.batch.core.partition.support.TaskExecutorPartitionHandler implementation, changed the handle method and add some properties.
Let’s take a look at the handle method which creates a ProActive Scheduler job, iterates over the step executions returned by the Stpet Execution Splitter and creates a ProActive Scheduling task for each step execution. The created job encapsulates these tasks. The Scheduler will execute them remotely on the available resources.
Bellow, the code of the handle method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

public Collection handle(
            StepExecutionSplitter stepExecutionSplitter,
            StepExecution masterStepExecution) throws Exception {
 
        Collection result = new ArrayList();
 
        // A job to be scheduled on the ProactiveScheduler
        TaskFlowJob proactiveSchedulerJob = new TaskFlowJob();
        proactiveSchedulerJob.setName("Master Step: "
                + masterStepExecution.toString());
 
        // the step executions
        Set stepExecutions = stepExecutionSplitter.split(
                masterStepExecution, gridSize);
 
        for (StepExecution stepExecution : stepExecutions) {
            String jobExecutionId = stepExecution.getJobExecution().getId()
                    .toString();
            String stepExecutionId = stepExecution.getId().toString();
            String stepName = step.getName();
 
            JavaTask jt = new JavaTask();
            jt.setName(stepExecutionId);
            jt.setExecutableClassName(StepExecutable.class.getName());
            jt.addArgument(StepExecutable.JOB_EXECUTION_ID, jobExecutionId);
            jt.addArgument(StepExecutable.STEP_EXECUTION_ID, stepExecutionId);
            jt.addArgument(StepExecutable.STEP_NAME, stepName);
            jt.addArgument(StepExecutable.JOB_CONFIG_FILE,
                    "/launch-context.xml");
            proactiveSchedulerJob.addTask(jt);
 
        }// for all StepExecution
 
        this.setJobClasPath(proactiveSchedulerJob);
 
        SchedulerAuthenticationInterface auth = SchedulerConnection
                .join(proactiveSchedulerUrl);
        UserSchedulerInterface uischeduler = auth.logAsUser(
                proactiveSchedulerUserName, proactiveSchedulerPassword);
        JobId id = uischeduler.submit(proactiveSchedulerJob);
 
        // blocking loop until we have the result:
 
        JobResult jr = null;
        while (jr == null) {
            Thread.sleep(3000);
            jr = uischeduler.getJobResult(id);
 
        }
 
        Map jobResults = jr.getAllResults();
        // the jobresults map contains entries of type:
        // and the task_name is the same as the corresponding step execution id
        // Therefore we iterate over the stepExecutions list and get the result
        // for each stepExecution
        // This will allow us to manage exceptions on the remote tasks
 
        for (StepExecution stepExecution : stepExecutions) {
            TaskResult taskResult = jobResults.get(stepExecution.getId()
                    .toString());
            try {
                StepExecution se = (StepExecution) taskResult.value();
                result.add(se);
            } catch (Throwable t) {
                // an exception has been thrown during the launch of the task on
                // the remote node
                // we will mark the local step execution as FAILED, attach the
                // exception to it and addd it to the results
 
                ExitStatus exitStatus = ExitStatus.FAILED
                        .addExitDescription("TaskExecutor rejected the task for this step.");
                stepExecution.setStatus(BatchStatus.FAILED);
                stepExecution.setExitStatus(exitStatus);
                stepExecution.addFailureException(t);
                result.add(stepExecution);
 
                // we print the stacktrace:
                System.out.println("an error occured while executing the step "
                        + stepExecution.getId().toString() + ":");
                t.printStackTrace();
 
            }
        }
        return result;
    }

First we create a TaskFlowJob (a job containing a set of tasks that may have dependencies between them).
This job will be sent to the Scheduler for distributed execution.
Then we obtain a list of step execution from the stepExecutionSplitter. We iterate over this list and, for each step execution, we create a task for our job. The java code for the task is defined by the StepExecutable class. Each task will receive in argument the job execution id, the step execution id and the initial job configuration file so the respective step execution could be retrieved from an application context on the remote node.
Next thing to notice is the job classpath: we add to our job a job environment containing the classes of our application so they could be found on the remote node.
Finally we connect to the Scheduler, send the job and wait for the results.
See the full code of the class below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197

package com.activeeon.sandbox.spring;
 
import java.io.File;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Map;
import java.util.Set;
 
import org.ow2.proactive.scheduler.common.SchedulerAuthenticationInterface;
import org.ow2.proactive.scheduler.common.SchedulerConnection;
import org.ow2.proactive.scheduler.common.UserSchedulerInterface;
import org.ow2.proactive.scheduler.common.job.JobEnvironment;
import org.ow2.proactive.scheduler.common.job.JobId;
import org.ow2.proactive.scheduler.common.job.JobResult;
import org.ow2.proactive.scheduler.common.job.TaskFlowJob;
import org.ow2.proactive.scheduler.common.task.JavaTask;
import org.ow2.proactive.scheduler.common.task.TaskResult;
import org.springframework.batch.core.BatchStatus;
import org.springframework.batch.core.ExitStatus;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.StepExecution;
import org.springframework.batch.core.partition.PartitionHandler;
import org.springframework.batch.core.partition.StepExecutionSplitter;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.util.Assert;
 
/**
 * A {@link PartitionHandler} that creates and submit a job on the ProActive
 * Scheduler
 *
 * @author Emil Salageanu
 *
 */
public class ProactiveSchedulerPartitionHandler implements PartitionHandler,
        InitializingBean {
 
    private int gridSize = 1;
 
    private String proactiveSchedulerUrl;
    private String proactiveSchedulerUserName;
    private String proactiveSchedulerPassword;
 
    private Step step;
 
    public void afterPropertiesSet() throws Exception {
        Assert.notNull(step, "A Step must be provided.");
    }
 
    /**
     * Passed to the {@link StepExecutionSplitter} in the
     * {@link #handle(StepExecutionSplitter, StepExecution)} method, instructing
     * it how many {@link StepExecution} instances are required, ideally. The
     * {@link StepExecutionSplitter} is allowed to ignore the grid size in the
     * case of a restart, since the input data partitions must be preserved.
     *
     * @param gridSize
     *            the number of step executions that will be created
     */
    public void setGridSize(int gridSize) {
        this.gridSize = gridSize;
    }
 
    /**
     * Setter for the {@link Step} that will be used to execute the partitioned
     * {@link StepExecution}. This is a regular Spring Batch step, with all the
     * business logic required to complete an execution based on the input
     * parameters in its {@link StepExecution} context.
     *
     * @param step
     *            the {@link Step} instance to use to execute business logic
     */
    public void setStep(Step step) {
        this.step = step;
    }
 
    /**
     * @see PartitionHandler#handle(StepExecutionSplitter, StepExecution)
     */
    public Collection handle(
            StepExecutionSplitter stepExecutionSplitter,
            StepExecution masterStepExecution) throws Exception {
 
        Collection result = new ArrayList();
 
        // A job to be scheduled on the ProactiveScheduler
        TaskFlowJob proactiveSchedulerJob = new TaskFlowJob();
        proactiveSchedulerJob.setName("Master Step: "
                + masterStepExecution.toString());
 
        // the step executions
        Set stepExecutions = stepExecutionSplitter.split(
                masterStepExecution, gridSize);
 
        for (StepExecution stepExecution : stepExecutions) {
            String jobExecutionId = stepExecution.getJobExecution().getId()
                    .toString();
            String stepExecutionId = stepExecution.getId().toString();
            String stepName = step.getName();
 
            JavaTask jt = new JavaTask();
            jt.setName(stepExecutionId);
            jt.setExecutableClassName(StepExecutable.class.getName());
            jt.addArgument(StepExecutable.JOB_EXECUTION_ID, jobExecutionId);
            jt.addArgument(StepExecutable.STEP_EXECUTION_ID, stepExecutionId);
            jt.addArgument(StepExecutable.STEP_NAME, stepName);
            jt.addArgument(StepExecutable.JOB_CONFIG_FILE,
                    "/launch-context.xml");
            proactiveSchedulerJob.addTask(jt);
 
        }// for all StepExecution
 
        this.setJobClasPath(proactiveSchedulerJob);
 
        SchedulerAuthenticationInterface auth = SchedulerConnection
                .join(proactiveSchedulerUrl);
        UserSchedulerInterface uischeduler = auth.logAsUser(
                proactiveSchedulerUserName, proactiveSchedulerPassword);
        JobId id = uischeduler.submit(proactiveSchedulerJob);
 
        // blocking loop until we have the result:
 
        JobResult jr = null;
        while (jr == null) {
            Thread.sleep(3000);
            jr = uischeduler.getJobResult(id);
 
        }
 
        Map jobResults = jr.getAllResults();
        // the jobresults map contains entries of type:
        // and the task_name is the same as the corresponding step execution id
        // Therefore we iterate over the stepExecutions list and get the result
        // for each stepExecution
        // This will allow us to manage exceptions on the remote tasks
 
        for (StepExecution stepExecution : stepExecutions) {
            TaskResult taskResult = jobResults.get(stepExecution.getId()
                    .toString());
            try {
                StepExecution se = (StepExecution) taskResult.value();
                result.add(se);
            } catch (Throwable t) {
                // an exception has been thrown during the launch of the task on
                // the remote node
                // we will mark the local step execution as FAILED, attach the
                // exception to it and addd it to the results
 
                ExitStatus exitStatus = ExitStatus.FAILED
                        .addExitDescription("TaskExecutor rejected the task for this step.");
                stepExecution.setStatus(BatchStatus.FAILED);
                stepExecution.setExitStatus(exitStatus);
                stepExecution.addFailureException(t);
                result.add(stepExecution);
 
                // we print the stacktrace:
                System.out.println("an error occured while executing the step "
                        + stepExecution.getId().toString() + ":");
                t.printStackTrace();
 
            }
        }
        return result;
    }
 
    public void setProactiveSchedulerUrl(String proactiveSchedulerUrl) {
        this.proactiveSchedulerUrl = proactiveSchedulerUrl;
    }
 
    public void setProactiveSchedulerUserName(String proactiveSchedulerUserName) {
        this.proactiveSchedulerUserName = proactiveSchedulerUserName;
    }
 
    public void setProactiveSchedulerPassword(String proactiveSchedulerPassword) {
        this.proactiveSchedulerPassword = proactiveSchedulerPassword;
    }
 
    protected void setJobClasPath(org.ow2.proactive.scheduler.common.job.Job job) {
 
        String appClassPath = "";
        try {
            File appMainFolder = new File(this.getClass().getProtectionDomain()
                    .getCodeSource().getLocation().toURI());
            appClassPath = appMainFolder.getAbsolutePath();
        } catch (java.net.URISyntaxException e1) {
            e1.printStackTrace();
        }
        JobEnvironment je = new JobEnvironment();
        try {
            je.setJobClasspath(new String[] { appClassPath });
            System.out.println("job classpath: " + appClassPath);
        } catch (java.io.IOException e) {
            e.printStackTrace();
        }
        job.setEnvironment(je);
    }
 
  }

Note that I have removed the taskExecutor property from the bean (we don’t need a task executroanymore), and added 3 properties for the connection to the Scheduler (scheduler url, username, password).

The second and last class we need to implement is the StepExecutable class which defines the code to be executed on the remote node. It defines an execute method which does nothing more than creating a spring application context, gathering the step execution and executing it. See the code bellow:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

package com.activeeon.sandbox.spring;
 
import java.io.Serializable;
import java.util.Map;
 
import org.ow2.proactive.scheduler.common.task.TaskResult;
import org.ow2.proactive.scheduler.common.task.executable.JavaExecutable;
import org.springframework.batch.core.JobInterruptedException;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.StepExecution;
import org.springframework.batch.core.explore.JobExplorer;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
 
public class StepExecutable extends JavaExecutable {
 
    public static final String JOB_EXECUTION_ID = "jobExecutionId";
    public static final String STEP_EXECUTION_ID = "stepExecutionId";
    public static final String STEP_NAME = "stepName";
    public static final String JOB_CONFIG_FILE = "JobConfigFile";
 
    private Long jobExecutionId;
    private Long stepExecutionId;
    private String stepName;
    private String configFile;
 
    @Override
    public void init(Map args) throws Exception {
        jobExecutionId = Long.parseLong(args.get(JOB_EXECUTION_ID));
        stepExecutionId = Long.parseLong(args.get(STEP_EXECUTION_ID));
        stepName = args.get(STEP_NAME);
        configFile = args.get(JOB_CONFIG_FILE);
    }
 
    @Override
    public Serializable execute(TaskResult... arg0) throws Throwable {
 
        ApplicationContext context = new ClassPathXmlApplicationContext(
                configFile, this.getClass());
 
        System.out.println("ApplicationContext ClassLoader:"
                + context.getClass().getClassLoader());
 
        BeanFactory factory = context;
        Step step = (Step) factory.getBean(stepName);
        JobExplorer je = (JobExplorer) factory.getBean("jobExplorer");
        StepExecution stepExecution = (StepExecution) je.getStepExecution(
                jobExecutionId, stepExecutionId);
 
        try {
            step.execute(stepExecution);
        } catch (JobInterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
            stepExecution.addFailureException(e);
        }
        return stepExecution;
    }
 
}

Part 2 – Configuration and run

Configuration files

The job configuration xml file is the shown bellow:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

<?xml version="1.0" encoding="UTF-8">
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:p="http://www.springframework.org/schema/p" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd"> <import resource="my-data-source-context.xml" />
	<bean id="PAJOB" parent="simpleJob"> <property name="name" value ="myJob44"/>
		<property name="steps">
			<bean name="step1:master">
				<property name="partitionHandler">
					<bean>
						<property name="step" ref="step1" />
						<property name="gridSize" value="2" />
						<property name = "proactiveSchedulerUrl" value = "rmi://192.168.1.10:1099"/>
						<property name = "proactiveSchedulerUserName" value = "admin"/>
						<property name = "proactiveSchedulerPassword" value = "admin"/>
					</bean>
				</property>
				<property name="stepExecutionSplitter">
					<bean>
						<constructor-arg ref="jobRepository" />
						<constructor-arg ref="step1" />
					</bean>
				</property>
				<property name="jobRepository" ref="jobRepository" />
			</bean>
		</property>
	</bean>
	<bean id="step1" parent="simpleStep">
		<property name="itemReader">
			<bean scope="step">
			</bean>
		</property>
		<property name="itemWriter">
			<bean />
		</property>
	</bean>
	<bean id="simpleJob" abstract="false">
		<property name="jobRepository" ref="jobRepository" />
		<property name="restartable" value="true" />
	</bean>
	<bean id="simpleStep" abstract="false">
		<property name="transactionManager" ref="transactionManager" />
		<property name="jobRepository" ref="jobRepository" />
		<property name="startLimit" value="100" />
		<property name="commitInterval" value="1" />
	</bean>
	<bean id="jobLauncher">
		<property name="jobRepository" ref="jobRepository" />
	</bean>
	<bean id="jobRepository" p:databaseType="mysql" p:dataSource-ref="dataSource" p:transactionManager-ref="transactionManager" />
	<bean id="jobExplorer" p:dataSource-ref="dataSource" p:tablePrefix="BATCH_" />
	<bean />
</beans>

I use a mysql database as datasource, defined in the my-data-source-context.xml file, bellow:

1
2
3
4
5

<property name="initScripts">
    <list>
        <value>schema-mysql.sql</value>
    </list>
</property>

Now, we still need two configuration files for the Proactive managed infrastructure … well, you didn’t expect to finish this tutorial in 15 minutes, did you? We’re almost finished …

We will use ProActive Resource Manager in order to deploy a set of remote resources (start remote JVMs and use them to perform computation): A GCMApplication file and a GCMDeployment file.
GCMApplication
By default, the remote jvm’s classpath is defined in the file Scheduler1_0/config/deployment/GCMNodeSourceApplication.xml (we’re talking about the JVMs deployed by the Resource Manager). You should either modify this file or create a new one, in order to add spring jars in the classpath of remote nodes.
My GCMNodeSourceApplication.xml is :

1
2
3
4
5
6
7
8
9
10
11
12

<!-- this variable will be replaced by a path of a GCMD to deploy, by RMAdmin -->
<!-- Commented dependencies are referenced through the Jar-Index of Scheduler jars -->
<!-- Script engines must be explicitly in application classpath -->
<!-- Needed explicitly by VFS (file transfer in pre/post script -->
<!--
<pathElement base="proactive" relpath="/dist/lib/script-api.jar" />
<pathElement base="proactive" relpath="/dist/lib/js.jar" />
<pathElement base="proactive" relpath="/dist/lib/jruby.jar" />
<pathElement base="proactive" relpath="/dist/lib/jython.jar" /> -->
 
<!-- Spring jars  -->
<!-- MySQL JDBC Driver -->

I have added, in this GCMApplication file the spring-batch jars I need, the jar for the java mysql driver and a folder containing my context-xml file accessible on the remote node.

NOTE: We hope that, in the next version of Scheduling, you will not have to specify the folder containing the spring job’s definition xml file – this should be
automatically transfered by proactive.

GCMDeployment

Choose a GCMDeployment file in [Scheduler_Home]/config/deployment and modify it accoring to your infrastructure or just use
[Scheduler_Home]/config/deployment/Local4JVMDeployment.xml to specify that you want 4 jvms deployed on localhost.

Run the Application

Here we are …
First of all, start the Resource Manager and the Scheduler Servers:

Start Resource Manager:
go to [Scheduing_Home]/bin/unix and type

./startRM.sh –deploy [Scheduler_Home]/config/deployment/Local4JVMDeployment.xml

Note: if you have not modified the GCMNodeSourceApplication.xml (to add spinrg jars, remember?) but created a different file, you have to modify the startRM.sh file and add this option to the JAVACMD:

  -Dpa.rm.gcm.template.application.file=path/to/my/GCMNodeSourceApplication.xml

Note: you can also start the RM without the deploy option and deploy later from the RM User Interface.
Start the Scheduler:

go to [Scheduing_Home]/bin/unix and type:

  ./startScheduler_newDB.sh

Now you can start the Graphical User Interfaces (RCP’s) for the Resource Manager and the Scheduler and connect them to the respective servers.

And finally, start your application.
You can use org.springframework.batch.core.launch.support.CommandLineJobRunner with arguments launch-context.xml PAJOB (do not forget to add spring jars for your application).
You can download source and configuration files here SpringBatchAndSchedulerSRC

Hope it works, if it doesn’t, leave a message.

]]> http://www.activeeon.com/blog/all/integration/distribute-a-spring-batch-job-on-the-proactive-scheduler/feed 0 Performing Grid Computing from an Application Server http://www.activeeon.com/blog/all/integration/performing-grid-computing-from-an-application-server http://www.activeeon.com/blog/all/integration/performing-grid-computing-from-an-application-server#comments Fri, 22 May 2009 15:07:28 +0000 emil salageanu http://exp.activeeon.com/?p=431 The goal of this Article is to show a use case of delegating the computation performed within a J2EE Application Server (Jboss is used in this article) by connecting an EJB3 application to a grid computing open source technology (ProActive Scheduler). This is very useful in case of applications that require computational intensive algorithms for responding to a user request. See the picture bellow.

schema_scheduler_jboss

Organization of The Article/Tutorial

Part ONE: Write a very simple EJB application

In the first part, we will create a simple EJB application composed by one single session bean that exposes e method for counting the number of divisors of a number n.

Part TWO: Use ProActive Scheduler to perform the computation on a grid

In this part we will show how to connect to the ProActive Scheduler, split input data and create tasks, create a job wich contains the tasks and submit it to the scheduler, merge the results of the computation and send the final result to the user.

The tutorial includes the installation steps of the required (open source) software (Jboss server, ProActive Scheduler, Eclipse ).
Sounds nice, I wanna read this ...

The Target Application

We will implement a simple application that computes the number of divisors of a (big) integer number.

Install and Configuration

  1. Download Eclipse Ganymede (the package “Eclipse IDE for Java EE Developers”) from http://www.eclipse.org/downloads/packages/ and extract it into a local folder. Lets call it ECLIPSE_HOME
  2. Download JBOSS Server (I used the version 4.2.3 GA) from http://www.jboss.org/jbossas/downloads and extract into a local folder (lets call it JBOSS_HOME)
  3. Download the ProActive Scheduler product from http://www.activeeon.com/community-downloads (I used the 4.0 version) and put it in a folder (lets call it SCHEDULER_HOME)

Note: It is recommended that folders that contain JBoss and ProActive do not contain spaces.

Note: If you want to start the JBoss server from eclipse, into Eclipse Workbench go to “Servers View” → right click → New→ Server; Choose Jboss → the version your are using (v.4.2 for me) → Next → Provide application server directory (browse to your JBOSS_HOME folder) → Finish

Part ONE: Write a very simple EJB3 application

We will now write a simple EJB3 application (compound of only one session bean), deploy it on the server and use a client application to send a request to the bean. Let’s write an application that counts the number of divisors of a number n. In the Eclipse workspace, create a new simple java project called DivisorCounterEJB

Import jars from Jboss

Go to Project → Properties → Java Build Path → Libraries and click on Add External Jars. Navigate to JBOSSS_HOME/server/default/lib and import the jars:

  • ejb3-persistence.jar
  • jboss-ejb3x.jar

Creation of the interface

Create a new interface in your project

  • Package: com.activeeon.demos.ejb.divisors
  • Interface Name: DivisorCounter

We will annotate the interface with the @javax.ejb.Remote annotation and define our business method countDivisors(BigInteger n)

The code of the interface is:

package com.activeeon.demos.ejb.divisors;
import java.math.BigInteger;
import javax.ejb.ApplicationException;
  @javax.ejb.Remote
  public interface DivisorCounter {
 
    public long countDivisors(BigInteger n);
 }

Creation of the Bean

Create a new class:

  • package: com.activeeon.demos.ejb.divisors
  • class name: DivisorCounterBean

The class implements the interface DivisorCounter We will annotate the class with @Stateleful. (Stateless version works as well, see notes at the end of the article) We have to implement the method countDivisors. For now we will compute the number of divisors sequentially, in this method. In the second part of this article, we will perform the computation on a grid. The code we obtain is:

       package com.activeeon.demos.ejb.divisors;
       import java.math.BigInteger;
       import javax.ejb.Stateful;
       @Stateful
       public class DivisorCounterBean implements DivisorCounter{
      	@Override
        public long countDivisors(BigInteger n) {
	  long divisors = 0;
	  System.out.println("New request received for counting divisor for number "+n.toString());
        	for (BigInteger i = new BigInteger("1"); i.compareTo(n.divide(new BigInteger("2")))&lt;=0; i=i.add(new BigInteger("1")))
	         {
		        if (n.remainder(i).equals(BigInteger.ZERO))
		            	divisors++;
           		}
	       //we add the last divisor which is n itself
         		divisors+=1;
      	      return divisors;
         	}
          }

Generating the JAR file and deploying the Bean on the JBoss Server:

We will have to generate the jar file of our application and deploy it on the application server. In the Eclipse Workbench, go to File → Export → Java→ Jar File Choose the project DivisorCounterEJB. Choose the name of the jar file DivisorCounter.jar and the location JBOSS_HOME/servers/default/deploy If your jboss server is not yet running, you can start it (from Eclipse go to Java EE perspective, Servers View, start server). You should see on the output of the JBoss Serever the lines:

12:58:16,702 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=DivisorCounter.jar,name=DivisorCounterBean,service=EJB3 with dependencies:
12:58:16,732 INFO  [EJBContainer] STARTED EJB: com.activeeon.demos.ejb.divisors.DivisorCounterBean ejbName: DivisorCounterBean
12:58:16,779 INFO  [EJB3Deployer] Deployed: file:/home/esalagea/ActiveEon/articles/SchedulerAndJboss/jboss-4.2.3.GA/server/default/deploy/DivisorCounter.jar

Your bean is deployed on the server and ready to be used.

Creating a client Application:

  • Create a new Java Project called DivisorCounterClient.
  • Add the external jars Jnp-client.jar and Jbossall-client.jar from JBOSS_HOME/client (go to Properties, Java Build Path → Add External Jars → …)
  • We also need to add the jar file of the previous (EJB) application. Go to Add External Jars and navigate to JBOSS_HOME/server/default/deploy/DivisorCounter.jar
  • Now add a JNDI file to your client project. Create a (text) file callled jndi.properties. At running time this file should be found in the root of the bin folder of your project (you could put the file in the root of the src folder in order to be copied, at compile time, in the bin folder) The content of the file is:
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=localhost

Now, let’s write the client class. The client should connect to the
bean application and send a request in order to obtain the number of
divisors of a number n. The content of the class is:

package  com.activeeon.demos.ejb.divisors.client;
   import java.math.BigInteger;
   import javax.naming.InitialContext;
   import javax.naming.NamingException;
   import com.activeeon.demos.ejb.divisors.DivisorCounter;
     public class DivisorCounterTester {
     public static BigInteger bi = new BigInteger("123456789");
     public static void main (String args[]) throws NamingException
	{
	 InitialContext ctx = new InitialContext();
	 DivisorCounter calculator = (DivisorCounter) ctx.lookup("DivisorCounterBean/remote");
	 System.out.println("Beginning computation in sequential version");
	 long beginTime = System.currentTimeMillis();
	 long d= calculator.countDivisors(bi);
	 long endTime = System.currentTimeMillis();
	 System.out.println(d+" divisors have been found");
	 System.out.println("Answer have been received after "+(endTime-beginTime)+ " milliseconds. ");
	 System.out.println("*****************\n");
	}
 }

Run the client application

On my machine, the output of the client is:

 Beginning computation.
 12 divisors have been found
 Answer have been received after 33570 milliseconds.

Part TWO: Use ProActive Scheduler to perform the computation on a grid.

Note: We will start by performing the computation on several JVMs on localhost. Then, if you have some available machines, you can use those ones in order to perform the computation.

I assume you have downloaded the last version of the ProActive Scheduler in the SCHEDULER_HOME folder. (for me this folder is “/home/ProActiveScheduler” )

Note: we will go on with the implementation and start the scheduler server later.

Add ProActive jars

Lets go back to our DivisorCounterEJB project and modify our bean to make it delegate the computation on the grid. First, we add jars for the ProActive Scheduler. As we want to deploy these jars on the JBoss server we will copy them in a lib folder of our project. Create a new Folder called “lib” in the DivisorCounterEJB project. Use your system navigator to navigate to the SCHEDULER_HOME/dist/lib folder. Select and copy the files: bouncycastle.jar,fractal-adl.jar,fractal.jar,javassist.jar, log4j.jar, ProActive_resource-manager.jar, ProActive_scheduler.jar, ProActive.jar. Then go back to the Eclipse Workbench and paste these files into the previously created “lib” folder. Now import these jars into the project (Properties → Java Build Path → Add Jars and select all the jars from the “lib” folder)

Modify the class DivisorCounterBean

First, we have to establish a connection to the Scheduler. Note that the Scheduler will accept one connection per Thread (this is due to the ProActive ActiveObjects programming pattern). As JBoss will reuse the threads we will have to keep a static variable that contain a mapping between the threads and the connections to the Scheduler. We also add three static variables containing the url of the scheduler, username and password. Lets add the next lines to the DivisorCounterBean class:

public final static String schedulerURL ="//192.168.1.10";
public final static String schedulerUserName = "user1";
public final static String userPassword="pwd1";
private static int numberOfTasks = 4;
public UserSchedulerInterface schedulerUI=null;
public SchedulerAuthenticationInterface schedulerAuth=null;
public static HashMap&lt;Long, UserSchedulerInterface&gt; connections=new HashMap&lt;Long, UserSchedulerInterface&gt;();

We will use the schedulerUI and schedulerAuth objects in order to connect to the Scheduler and submit a job.

Connect to the scheduler

We will start by writing a private method to connect to the scheduler.

Important Note: This is is the trickiest thing in this tutorial. First, we need to keep in mind that we need to connect to the ProActive Scheduler and therefore we are now in a ProActive programming model context. the ProActive Scheduler accepts only one connection per caller Thread (this is because the Scheduler accepts one connection per ActiveObject caller, plase see the ProActive programming model if you want to have a deeper understanding of all this). On the other hand, JBoss uses a thread pool in order to serve user requests. So, if at one point, I want to know if my session bean is connected to the Scheduler, I actually need to check if the current Thread has a connection to the Scheduler. I know it sounds complicated but it isn’t ..

As we need to keep one connection per Thread we will start by verifying if the current thread already has a connection attached, and, if not, create one and ad an entry in the connections HashMap. The method we obtain is:

private void connectToScheduler() throws SchedulerException, LoginException
{
      	long threadId = Thread.currentThread().getId();
	schedulerUI = DivisorCounterBean.connections.get(new Long(threadId));
	if (schedulerUI!=null)
	{
		System.out.println("already logged in");
		return;
	}
	else
	{
	 schedulerAuth = SchedulerConnection.join(schedulerURL);
	 schedulerUI = schedulerAuth.logAsUser(schedulerUserName, userPassword);
	 DivisorCounterBean.connections.put(new Long(threadId), schedulerUI);
	 System.out.println("new Connection to the schdeuler has been created. Nb of connections: "+connections.size());
	}
}

Add ejbCreate() method

We want to connect to the scheduler when the bean is created. We’ll just add a method called ejbCreate() that we annotate with @javax.ejb.Init in which we call the connectToScheduler() method. The method looks like this:

@javax.ejb.Init
      public void ejbCreate()
	{
		System.out.println("Creation of DivicorCounterBean. ");
		try{
			connectToScheduler();
		   }
		catch (Exception e)
		{
		  e.printStackTrace();
		}
	}

We have connected our bean to the scheduler, we only need now to split
the data, create the Tasks which count the number of divisors, send
them to the Scheduler and addition the results.

Implement the Task class

Lets start by implementing the Task code. A task will take in argument the number n for which we are counting divisors and interval in which we are looking for divisors, given by its lower and upper bounds. A Scheduler Task will have its input data in a HashMap of arguments. The execute method can take as input a list of results of the Tasks on which this task depends on, but, as our tasks don’t have dependencies, this list will always be empty. Furthermore, the code for the Task class it is easy to understand. Here it is:

package com.activeeon.demos.ejb.divisors;
  import java.math.BigInteger;
  import org.objectweb.proactive.core.util.wrapper.StringWrapper;
  import org.ow2.proactive.scheduler.common.task.TaskResult;
  public class DivisorsTask extends org.ow2.proactive.scheduler.common.task.executable.JavaExecutable{
  @Override
  public Serializable execute(TaskResult... arg0) throws Throwable {
	String lowerBoundString = this.getArgs().get("LowerBound");
	BigInteger lowerBound = new BigInteger(lowerBoundString);
	//BigInteger fromNumbber = new BigInteger(from);
	String upperBoundString = this.getArgs().get("UpperBound");
	BigInteger upperBound = new BigInteger(upperBoundString);
	String n = this.getArgs().get("n");
	BigInteger nNumber = new BigInteger(n);
	long divisors = 0;
	for (BigInteger i = lowerBound; i.compareTo(upperBound)&lt;=0; i=i.add(new BigInteger("1")))
	{
		if (nNumber.remainder(i).equals(BigInteger.ZERO))
			divisors++;
	}
	String s = (new Long(divisors)).toString();
	StringWrapper sw = new StringWrapper(s);
	return sw;
      }
 }

Our bean is almost finished. We only need to create a job (which is formed of tasks) and submit it to the Scheduler.

Lets first add to our com.activeeon.demos.ejb.divisors.DivisorCounter interface a method

public long distributedCountDivisors(BigInteger n);

We will create a TaskFlowJob (which is a job that can contain one or more task(s) ), will add tasks to this job and then submit it to the scheduler.

Implement the distributedCountDivisors method

  • job creation
TaskFlowJob job = new TaskFlowJob();
job.setName("DivisorCounter");
      //if error occur on one task, should we cancel the job?
      job.setCancelOnError(true);
     job.setDescription("Job sent from an EJB application deployed on JBoss v4.2 AS");
  • classpath

As we need to execute the code in the DivisorTask class that we
previously wrote, we need to have this class on the remote machines (on
the nodes). We need so, either to provide a classpath containing the
DivisorTask class when starting the nodes, either to provide this
classpath to the job by using a JobEnvironment object. This is done by
these lines:

		String appClassPath = "";
		try {
			File appMainFolder = new File(DivisorCounterBean.class
					.getProtectionDomain().getCodeSource().getLocation()
					.toURI());
			appClassPath = appMainFolder.getAbsolutePath();
		} catch (URISyntaxException e1) {
			System.out
					.println("An exception has occured while setting the job classpath.");
			e1.printStackTrace();
		}
		JobEnvironment je = new JobEnvironment();
		je.setJobClasspath(new String[] { appClassPath });
		job.setEnv(je);
  • creation of the tasks

We will create m intervals in which we will be counting the divisors of the number n. To do so, we will split the interval (2, n/2+1) into m intervals (where m = numberOfTasks, statically defined), and provide one interval to each Task. An interval is defined by its lower bound and its upper bound. Our tasks will receive then 3 arguments: lower bound, upper bound and the number n. For two values lower bound and upper bound already computed, the code which creates the task is:

JavaTask jt = new JavaTask();
jt.setName("Divisors Task "+i);
jt.setDescription("Count divisors of number "+n.toString()+" within the interval ("+lowerBound.toString()+" , "+upperBound.toString()+")");
jt.addArgument("LowerBound",lowerBound.toString());
jt.addArgument("UpperBound", upperBound.toString());
jt.addArgument("n", n.toString());
jt.setPreciousResult(true);
jt.setExecutableClassName(DivisorsTask.class.getName());
job.addTask(jt);
  • submit the job to the scheduler and wait for the results

Once the job is submitted, we only have to wait for the results, addition them when arrived and send the final result to the client.
Note: In this implementation we will just keep waiting (perform a Thread sleep) and ask the scheduler every n milliseconds if the result is available. A better solution would be to subscribe a listener to the Scheduler in order to be notified, by the Scheduler, when the result is available. See the Advanced section at the end of this article.

The code of the method is:

public long distributedCountDivisors(BigInteger n) {
	if (schedulerUI == null) {
		try {
			connectToScheduler();
		} catch (LoginException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
			return 0;
		} catch (SchedulerException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
			return 0;
		}
	}
	long nbOfDivisors = 0;
	try {
		TaskFlowJob job = new TaskFlowJob();
		job.setName("DivisorCounter");
		// if error occur on one task, should we cancel the job?
		job.setCancelOnError(true);
		job
				.setDescription("Job sent from an EJB application deployed on JBoss v4.2 AS");
		// handle classpath
		String appClassPath = "";
		try {
			File appMainFolder = new File(DivisorCounterBean.class
					.getProtectionDomain().getCodeSource().getLocation()
					.toURI());
			appClassPath = appMainFolder.getAbsolutePath();
		} catch (URISyntaxException e1) {
			System.out
					.println("An exception has occured while setting the job classpath.");
			e1.printStackTrace();
		}
		JobEnvironment je = new JobEnvironment();
		je.setJobClasspath(new String[] { appClassPath });
		job.setEnv(je);
		BigInteger halfN = n.divide(new BigInteger("2"))
				.add(BigInteger.ONE);
		BigInteger intervalSize = halfN.divide(new BigInteger(new Integer(
				DivisorCounterBean.numberOfTasks - 1).toString()));
		BigInteger lowerBound;
		BigInteger upperBound;
		for (int i = 0; i &lt; DivisorCounterBean.numberOfTasks; i++) {
			lowerBound = intervalSize.multiply(
					new BigInteger(new Integer(i).toString())).add(
					BigInteger.ONE);
			upperBound = lowerBound.add(intervalSize
					.subtract(BigInteger.ONE));
			// for the last interval
			if (upperBound.compareTo(halfN) &gt; 0) {
				upperBound = halfN;
			}
			// Creating the Divisors Task for the interval (upperBound,
			// lowerBound)
			JavaTask jt = new JavaTask();
			jt.setName("Divisors Task " + i);
			jt.setDescription("Count divisors of number " + n.toString()
					+ " within the interval (" + lowerBound.toString()
					+ " , " + upperBound.toString() + ")");
			jt.addArgument("LowerBound", lowerBound.toString());
			jt.addArgument("UpperBound", upperBound.toString());
			jt.addArgument("n", n.toString());
			jt.setPreciousResult(true);
			jt.setExecutableClassName(DivisorsTask.class.getName());
			job.addTask(jt);
		}
		JobId jobId = schedulerUI.submit(job);
		System.out.println("The Job has been submited to the scheduler.");
		JobResult jResult = null;
		boolean keepWaiting = true;
		while (keepWaiting &amp;&amp; (jResult == null)) {
			try {
				Thread.sleep(500);
				jResult = schedulerUI.getJobResult(jobId);
			} catch (SchedulerException se) {
				keepWaiting = false;
				se.printStackTrace();
				return 0;
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
		System.out.println("The results of the job are: " + jResult);
		HashMap&lt;String, TaskResult&gt; results = jResult.getAllResults();
		for (TaskResult t : results.values()) {
			String rs = ((StringWrapper) t.value()).toString();
			int r = new Integer(rs).intValue();
			nbOfDivisors += r;
		}
		// we add n as divisor of n
		nbOfDivisors++;
	} catch (Exception e) {
		e.printStackTrace();
	} catch (Throwable e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
	return nbOfDivisors;
}

Call the distributed method from the client

Lets call, from the client, the 2 methods (the sequential one and distributed one, in order to compare the computation times) Add the next lines to the main method oof the DivisorCounterTester class in the DivisorCounterClient project:

	System.out.println("Begining computation in distributed version");
	beginTime = System.currentTimeMillis();
	d= calculator.distributedCountDivisors(bi);
	endTime = System.currentTimeMillis();
	System.out.println(d+" divisors have been found");
	System.out.println("Answer have been received after "+(endTime-beginTime)+ " milliseconds. ");
	System.out.println("*****************/n");

Note: your client might not compile now because it does not now the distributedCountDivisors method. Just export again the DivisorCounterEJB project as a jar and import it again in the client project.

Start the scheduler and run your application

Important Note: before you do this, you should change the Proactive default rmi port in order not to have a conflict with JBoss port.

In your root folder you should have a folder called “.proactive” . Go inside and edit the file called ProActiveConfiguration.xml. Look for the line which defines the property “proactive.rmi.port” and change its value (1099 by default). In my case I put it to 1605 (it’s my credit card pin code :) )
Proactive Scheduler relies on a Resource Manager server.

  • Start the Resource manager:

Open a command console and navigate to SCHEDULER_HOME/bin/unix (../windows if you are working on a windows system). Type ./startRM.sh (startRM.bat for windows) The Resource Manager will start and will deploy, by default, 4 nodes (jvm’s) on the localhost.

  • Start the scheduler

Open a new command console and navigate to SCHEDULER_HOME/bin/unix (../windows) Only for the first time your are launching the scheduler, you have to create its database (which contains information about jobs, their tasks, results, etc..) Type: startScheduler_newDB.sh (.. bat for windows) This will create the database and start the scheduler which will connect to the resource manager in order to obtain resources and deploy tasks.

  • Start the JBoss server

Important Note add this property to the jboss launcher: -Dlog4j.configuration=JBOSS_HOME/default/conf/jboss-log4j.xml

./run.sh -Dlog4j.configuration=JBOSS_HOME/default/conf/jboss-log4j.xml

You have to do this in order to force ProActive use the log4j.configuration
file of JBoss (in order not to have logger conflicts in the JBoss JVM).

  • Run your client application.

On my machine the output of the client is:

Beginning computation in sequential version
12 divisors have been found
Answer have been received after 35638 milliseconds.
*****************
Beginning computation in distributed version
12 divisors have been found
Answer have been received after 18980 milliseconds.
*****************

This is it, if you followed me until this point, you have your session bean which delegates the computation on a set of JVMs. I only have few words to add about adding remote resources (nodes), starting the Scheduler itself on a remote machine, using the GUI for administration of the Scheduler and Resource manager.

Additional Information

Scheduler and Resource Manager Administration

  • First start the Resource Manager administration GUI. Right Click → connect to Resource Manager.

You should see now the four JVMs that have been deployed by default on your machine.

  • Now start the Scheduler administration GUI. Right Click → connect to scheduler ..
  • Relaunch your application

You can remove, if you want to, from the client, the call to the sequential method. You should see that, on the Resource Manager GUI some of the resources are marked as “occupied” (yellow), and, on the Scheduler Administration GUI you can see your job running.

Add remote resources

Connect to another machine of your network. Open a command console and navigate to SCHEDULER_HOME/bin folder Type ./startNode.sh myNode The ProActive Runtime (jvm, node) is launched and the url of the node is printed at stdout. Go to the Resource Manager, right click → Add node(s) and type the url of the node you have just started. (you can also remove one node from the localhost). You can rerun your client application now.

Running the scheduler and resource manager on remote machines

You can start the resource manager on a machine M1 and the scheduler on a machine M2. When you start the Scheduler, make sure you give the good url of the Resource Manager in argument (option -u //IpOfM2). Then modify the schedulerURL static variable in the DivisorCounterBean class with the ip of the machine M2. Export again the jar file of your application. Stop the JBoss server. When you start the JBoss server pass as argument “–host ip” where ip is the ip of your machine in the local network. Now run your client application. The bean now connects to the machine M2 on the scheduler server (which itself connects to the machine M1 to the Resource Manager server in order to obtain resources.). Run your client application again.

Remarks

  • You can specify your bean as “Stateless”

(for our example, a stateless bean would do just fine). Note that in this case, the ejbCreate() method will not be called (and, the SchedulerUI will be instantiated at the first call of distributedCountDivisors method)

  • In this example we have defined the number of task in a static variable.

This should be defined by taking in account the size of the number for which we are counting divisors

  • The results of the job can be obtained one by one.

Each result can be obtained as soon as the respective task has finished. This could be useful if, for instance, you are using a web client and want to refresh the page after each result (write on the web page something like “23 divisors have been found until now. ”).

  • ProActive Scheduler provides the possibility to define also Native Tasks

(instead of Java Tasks), which means that they execute native applications.

  • Dependencies between tasks can also be defined

(Task k use the results of Task i and Task j)

Fast Test

I have launched the application by using 4 nodes/JVMs (2 local JVMs and two JVMs on different machines). The output of my client application is:

Beginning computation in sequential version
12 divisors have been found
Answer have been received after 33484 milliseconds.
*****************
Beginning computation in distributed version
12 divisors have been found
Answer have been received after 9163 milliseconds.
*****************

So, by distributing the computation on 4 JVMs, I had an answering time from the server 3.65 times lower then the time for the sequential application.

Advanced

In the distributedCountDivisors method from the DivisorCounterBean class we have created a job, submitted it to the ProActive Scheduler, and then, within a loop, we have “asked” the Scheduler, every n milliseconds, if it our result is available. This solution goes well for our little example but a much better solution would be to subscribe a Listener to the Scheduler in order to be notified when the result is available.
In order to do so, you should create a Listener by implementing the org.ow2.proactive.scheduler.common.scheduler.SchedulerEventListener. You must subscribe your listener to the Scheduler, and let your listener play the role of proxy for the Scheduler. Moreover, your Listener should be an active object or, at least should belong to an Active Object.
But this requires the understanding of some ProActive concepts. I might come back on this advanced solution in some other article. Do not hesitate to let me know if you’re planning to implement this solution, I might have some useful tips for you (especially about how to configure Jboss and ProActive Scheduler in order to solve some ClassLoading conflicts that might appear)

Documentation

See JBoss at www.jboss.org

See ProActive and ProActive Scheduler at www.activeeon.com

]]> http://www.activeeon.com/blog/all/integration/performing-grid-computing-from-an-application-server/feed 0