Java Reference
In-Depth Information
In most of the loaders in Table 10-1 will be some sort of parameter that lets you provide the URL to a
Spring XML application context file.
Because GridGain itself is built on top of Spring, most of its “plumbing” is configurable. You might,
for example, want to use a JMS queue for the communications layer between nodes. You might want to
override the discovery mechanism. You might want to make use of any of numerous caching solutions
on the market. There are too many permutations to list, but the distribution itself will contain a config /
directory in which you can find numerous example configurations.
One common requirement is sharing one LAN with multiple grids. You could conceivably have
5 nodes doing one kind of processing, and another 10 doing another type for a different project, without
requiring a separate subnet.
You partition the cluster by setting the gridName property. gridName enables you to start several
grids on the same LAN without fear of one grid stealing another grid's jobs.
An example might be as follows:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
<bean id="grid.cfg" class="org.gridgain.grid.GridConfigurationAdapter"
<property name="gridName" value="mygrid-001"/>
<!-- ... other configuration … -->
The next level of parameterization is user attributes. These parameters are specific to the node
on which they're configured. You might imagine using these to partition your grid jobs, or to provide
box-specific metadata like a NFS mount, or which FireWire or USB device to consult for something.
In the following example, we use it to describe to the node on which countries' data it should concern
itself with:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
Search WWH ::

Custom Search