Over a million developers have joined DZone.

JPPF Grid Toolkit 1.2: Execution Policy, Serialization Schemes, Tomcat

DZone's Guide to

JPPF Grid Toolkit 1.2: Execution Policy, Serialization Schemes, Tomcat

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

Version 1.2 the Java Parallel Processing Framework (JPPF), the grid toolkit for Java, brings 3 major new features, outlined in this article.

Submitting jobs with an execution policy

A capability that was missing in the previous versions, was the ability to specify on which nodes a set of tasks - or job - could run. It is now possible to specify a set of conditions that a node must satisfy to execute a given set of computational tasks.

Let's take an example. Imagine that we have tasks that require a lot of memory, say 512 MB, and embed a large amount of data. We want that data to be transported as fast as possible, so we want the nodes to be as close as possible, for instance in the "mydomain.com" internet domain.

We would express our execution policy as follows:

<!--max memory in bytes-->
<Contains ignoreCase="true">

This translates as execute only if the node has at least 520,000,000 bytes of max memory and is in the "mydomain.com" domain.

Now all that remains to do is parse this XML policy and submit it along with the tasks:

ExecutionPolicy policy = PolicyParser.parsePolicyFile("../policies/MyPolicy.xml");
List<JPPFTask> results = jppfClient.submit(tasks, dataProvider, policy);

A second example: let's consider that we have N nodes, each one with a numeric ID, named very creatively "node.id", with a value from 1 to N.
We want our tasks to be executed only on nodes 2 to 5 and 9 to 12. We then specify an execution policy like this:


It looks very easy, doesn't it? I invite you to read a lot more in the full execution policy documentation pages.

Using alternate serialization schemes

A recurrent problem with Java serialization, is that our objects have to be ... Serializable, i.e. their classes must implement java.io.Serializable or java.io.Externalizable.
JPPF makes an extensive use of serialization to transport objects to its servers and nodes. But what happens if the application uses 3rd-party libraries where it is not possible to change the code to make objects Serializable?

JPPF addresses this situation by providing the capability to function with object streams other than the standard java.io.ObjectInputStream and java.io.ObjectOutputStream.
A built-in implementation is provided that enables JPPF to work entirely with the XStream XML serialization framework.
More on this in the JPPF documentation.

Tomcat port of JPPF client

Unlike the other J2EE application server ports (see JPPF and J2EE), the port to Tomcat is not based on the JPPF JCA connector.
It is rather a simple embedding of the J2SE client into a web application that can be deployed into a Tomcat container.

About JPPF:

JPPF is a grid toolkit for 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!

JPPF has many outstanding features:

  • A JPPF grid can be up and running in minutes
  • Simple programming model that abstracts the complexity of distributed and parallel processing
  • Highly scalable, distributed framework for the parallel execution of cpu-intensive tasks
  • Seamless integration with leading J2EE application servers
  • 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 of JPPF to real-life problems
  • JPPF@Home screensaver leverages idle enterprise resources
  • Runs on any platform that supports Java ®
  • Very flexible and business-friendly open source licensing
  • and more ....

Try it for yourself at the JPPF.org web site.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}