The partial update script defined in the AppConfig.xml document for a Dgraph deployment is included in this section, with numbered steps indicating the actions performed at each point in the script.
<script id="PartialUpdate">
<bean-shell-script>
<![CDATA[
log.info("Starting partial update script.");
// obtain lock
if (LockManager.acquireLock("update_lock")) {
// test if data is ready for processing
if (PartialForge.isPartialDataReady()) {
// archive logs
PartialForge.archiveLogDir();
// clean directories
PartialForge.cleanDirs();
// fetch extracted data files to forge input
PartialForge.getPartialIncomingData();
// fetch config files to forge input
PartialForge.getConfig();
// run ITL
PartialForge.run();
// timestamp partial, save to cumulative partials dir
PartialForge.timestampPartials();
PartialForge.fetchPartialsToCumulativeDir();
// distribute partial update, update Dgraphs
DgraphCluster.copyPartialUpdateToDgraphServers();
DgraphCluster.applyPartialUpdates();
// archive partials
PartialForge.archiveCumulativePartials();
// release lock
LockManager.releaseLock("update_lock");
log.info("Partial update script finished.");
}
else {
log.warning("Failed to obtain lock.");
}
]]>
</bean-shell-script>
</script>
INFO: Starting copy utility 'copy_partial_update_to_host_MDEXHost1'. Oct 20, 2008 11:46:37 AM org.apache.axis.encoding.ser.BeanSerializer serialize SEVERE: Exception: java.io.IOException: Non nillable element 'fromHostID' is null. ...
<dgraph-defaults>
<properties>
...
<property name="srcPartialsDir" value="./data/partials/forge_output" />
<property name="srcPartialsHostId" value="ITLHost" />
<property name="srcCumulativePartialsDir" value="./data/partials/cumulative_partials" />
<property name="srcCumulativePartialsHostId" value="ITLHost" />
...
</properties>
...
</dgraph-defaults>
The reason is that the script is obtaining the fromHostID value from this section.
If you have a configuration with two MDEX Engine servers each of which hosts two Dgraphs, you may want to run partial updates on each of these servers in parallel. This would require you to customize jobs for the EAC to make this happen. If you do this, keep in mind that the EAC Server expects all jobs sent to it to be unique across all servers.
Therefore, if you are customizing more than one job to the EAC Server, ensure that the jobs are created with a different name. This is because, even though each of these jobs runs on a separate MDEX Engine server and is unique on that server, the EAC Server expects all jobs to be unique across all servers.