JPPF, the grid computing platform for Java, releases version 1.6

Discussions

News: JPPF, the grid computing platform for Java, releases version 1.6

  1. JPPF is an open source Grid Computing platform written in Java that makes it easy to run applications in parallel, and speed up their execution by orders of magnitude. Write once, deploy once, execute everywhere! In this version: - Tasks can now be defined from plain old Java objects - A new JPPF Quick Start Guide is now availabe online and offline. - A new management feature enables resetting a node's task counter - Improvements to the remote JMX connectivity facilitate the JPPF administration through firewalls - Bugs were fixed in the peer-to-peer communication between servers JPPF has many outstanding features: - a JPPF grid can be up and running in minutes - highly scalable, distributed framework for the execution of Java tasks - leverages JCA 1.6 to integrate with leading J2EE application servers - easy programming model that abstracts the complexity of distributed and parallel processing - graphical and programmatic tools for fine-grained monitoring and administration - fault-tolerance and self-repair capabilities ensure the highest level of service and reliability - a set of fully documented sample applications, demonstrating the use of JPPF on real-life problems - very flexible open-source licensing - and more .... Try it for yourself on the JPPF web site.
  2. Hello, Anyone can compare this one with another grid open source project such as Globus Toolkit, Condor, .... ? Thanks
  3. Anyone can compare this one with another grid open source project such as Globus Toolkit, Condor, .... ?
    In my view, the major difference is that Globus, Condor, UNICORE etc are targetted at running arbitrary jobs (such as shell scripts, legacy apps, etc) on remote sites. The remote sites can be heterogeneous, and are usually in a different network, so you need to worry about firewalls and security. The Java frameworks (JPPF, GridGain, etc) are targetted at running Java tasks on remote nodes, sort of like a distributed version of java.util.concurrent.ExecutorService. Usually the nodes are in the same enterprise network. If you are in a Java-only setting in a controlled environment, choose one of the "enterprise Grid" solutions. For more heterogeneous problems, UNICORE, Condor, etc might be more suited.
  4. Anyone can compare this one with another grid open source project such as Globus Toolkit, Condor, .... ?

    In my view, the major difference is that Globus, Condor, UNICORE etc are targetted at running arbitrary jobs (such as shell scripts, legacy apps, etc) on remote sites. The remote sites can be heterogeneous, and are usually in a different network, so
    you need to worry about firewalls and security.
    The Java frameworks (JPPF, GridGain, etc) are targetted at running Java tasks on remote nodes, sort of like a distributed version of java.util.concurrent.ExecutorService. Usually the nodes are in the same enterprise network.

    If you are in a Java-only setting in a controlled environment, choose one of the "enterprise Grid" solutions. For more heterogeneous problems, UNICORE, Condor, etc might be more suited.
    Thanks Bernd, this is a very insightful comment. I just want to add that the ability to run run non-Java scripts, programs or apps is one of the features we are currently working on. Even though it is not easy to run external processes from Java, it is definitely not impossible. The problems are in the realm of finding a semantics that makes sense for the users, being able to detect when the job is actually terminated, being able to porcess inputs and ouptuts to/from the job, etc... Our intent is to have a first version delivered before the end of this year. Sincerely, -Laurent
  5. I just want to add that the ability to run run non-Java scripts, programs or apps is one of the features we are currently working on.

    Even though it is not easy to run external processes from Java, it is definitely not impossible. The problems are in the realm of finding a semantics that makes sense for the users, being able to detect when the job is actually terminated, being able to porcess inputs and ouptuts to/from the job, etc...
    Our intent is to have a first version delivered before the end of this year.
    In UNICORE, part of the solution (dealing with an external process from Java) looks like this. Maybe it helps meeting your deadline :-) Best regards, Bernd.
  6. "- A new management feature enables resetting a node's task counter" I have never been in favor of resetting management statistics - counters should always grow. This (poor) practice has been encouraged in a number of JMX APIs and derived management models. A much better option and one we provide in our multi-resource metering runtime for cloud and grid environments is the ability to mark and then track the change (and rate of change) since this mark. William
  7. I have never been in favor of resetting management statistics - counters should always grow. This (poor) practice has been encouraged in a number of JMX APIs and derived management models.
    Thanks William, I got your point. Do you have any pointers or references, as to why this is a poor practice? I am interested in reading on this topic. Also, do you see any harm in having this feature and not need it vs. not having it and need it? Thanks, -Laurent
  8. Hi Laurent, There is really no harm in offering this capability - everyone else is doing it. Unfortunately from an operations point of view, which is why everyone (developer) is adding it, it creates problems for the management software in trying to reconcile metric samples as well as possibly losing data (multiple resets between samples). Users most definitely do want to track change across two periods it is just that I do not like see data collected (counted) wasted by completely reseting. William