Thanks,

Lucas

SO, i’m mixing your tutorial with the reality of opensuse (using /usr/src/packages/ instead of ~/rpm and copying ganttproject-2.0.9 binaries folder direct to /usr/src/packages/SOURCES) but the main problem i have is that when i type “rpmbuild -bb /usr/src/packages/SPECS/ganttproject.spec” all i have is File not found listing ALL the files from %file from spec file.

If i see the /tmp directory i can see all the files of ganttproject in that root directory (/tmp/ganttproject_files) so obviously i’m doing something wrong.

This is the spec file i’m using:
http://pastebin.com/f1187a291

This is the output i get:
http://pastebin.com/f15b4369a

Can you help me please ??

Thanks !!!

I will try to modify it such that we can see how coordination can be achieved on GridGain. Any suggestions would be welcome!

In GridGain there is a concept of split – a task gets split into multiple jobs for parallel execution. If you need to have synchronization between multiple jobs within the same task, you should use Distributed Grid Task Session. Session object is simply injected into GridTask or GridJob and you are able to set, get, or wait for any attribute/event either synchronously or asynchronously.

Hope this helps.

Best,
Dmitriy Setrakyan
GridGain – Grid Computing Made Simple

>>In your Terracotta example you started one producer and one consumer. So one node was producing jobs in one thread and another node was consuming jobs also in one thread. So you simply were not able to control how many consumers or producers you could have, and, hence, didn’t ask this question then.

I don’t think that is correct. I was able to control the number of producers or consumers by starting either a producer or a consumer on another node (see the main method). So I could have 1 producer and 2 consumers.

It looks like I can’t do so in GridGain without changing the code. I can add more grid nodes but since I have 1 Producer and 1 Consumer, it doesn’t matter how many nodes I have, the Job instances will still be processed sequentially by that Consumer. While Job.run() may be executed on another node, and the main node and all other nodes are idling. So basically, I will have to know before hand how many nodes do I have and accordingly start the number of Consumers.

Please let me know if that is not so.

What happens when a Consumer picks up a Job from Jobs and calls job.run().

The behavior of grid-enabled methods is just as it would be local – the method has to behave identically with or without grid. In your code, consumer synchronously waits for job completion and that’s exactly what happens after grid-enabling. What you are suggesting is that you want your consumer to wait asynchronously – but for that you have to update your own logic. The advantage of remote execution is that with addition of remote nodes you can afford to have many more consumers running locally in parallel.

How many Consumers should I start from Main?

In your Terracotta example you started one producer and one consumer. So one node was producing jobs in one thread and another node was consuming jobs also in one thread. So you simply were not able to control how many consumers or producers you could have, and, hence, didn’t ask this question then

The answer to your question is that every application is different. If you see that application is under-performing, then start another node to help out. If you see that application is idling, then either start more consumers or remove nodes to get better CPU utilization.

One of the big differences you didn’t mention is that with GridGain your remote nodes did not require any extra Jars or configuration – all your code was peer-loaded automatically onto remote nodes for execution. Just imagine what kind of time-saver it is during development.

Best,
Dmitriy Setrakyan
GridGain – Grid Computing Made Simple

Nothing could be further from the truth. For simply taking a code and running it with GridGain (just like Terracotta), you don’t have to write any code (GridTasks are useful when you want to split your logic into smaller pieces to achieve even higher level of parallelism).

Here are the steps you need to do in order to grid-enable your producer-consumer application described here.

1. Make Job implement java.io.Serializable

2. Attach @Gridify annotation to Job.run() method:
{code}
/**
* The body of the class is directly copied from your example.
*/
public class Job implements Serializable {
int jobduration = (int) (Math.random()*5000);

/**
* This method is grid-enabled by a virtue of attaching @Gridify annotation. The body of the method is directly copied from your example.
*/
@Gridify
public void run(){
try {
Thread.sleep(jobduration);

System.out.println(“Job finished in ” + jobduration + ” millis.”);
}
catch (InterruptedException ex) {
ex.printStackTrace();
}
}
}
{code}
3. That’s it. Here is what your Main would look like:
{code}
public class Main {
public static void main(String[] args) throws Exception {
// Start grid.
GridFactory.start();

try {
Jobs jobs = new Jobs();

new Producer(jobs).start();
new Consumer(jobs).start();
new Consumer(jobs).start();

Thread.sleep(Long.MAX_VALUE);
}
finally {
// Stop grid.
GridFactory.stop(true);
}
}
}
{code}

4. Now you can run your Main directly from IDE of your choice. Note that there is no extra configuration required. If you start remote GridGain node (just double-click on gridgain.bat script) then your jobs will be executed on that node without any (re)deployment steps – the classes will be peer-loaded automatically.

Best,
Dmitriy Setrakyan
GridGain – Grid Computing Made Simple

Looking forward to your GridGain analysis

I think GridGain benefits will shine not only when you have to execute something on remote node, but also when you need to split a bigger task into smaller subtasks.

Also GridGain’s peer-class-loading will come very convenient during development – there is no deployment or extra configuration of remote nodes.

Best,
Dmitriy Setrakyan
GridGain – Grid Computing Made Simple