Configuring SPADE to transfer data not placed in the dropbox
This article explains how to configure a SPADE deployment so that it can pick up and transfer data that is not placed in the dropbox. This scenario can be used in situations where the data files are managed by a software system other than SPADE, for example an experiment's data acquisition system.
Pre-requisites
It is assumed that the nest-spade-war project has been install and running as outlined here, and that the log output of the JBoss server can be seen in a second terminal.
Also, this scenario builds upon the Loopback scenario the handle the transfers so you should work through that one first.
Also, as in that scenario, the following environmental variables need to be set. They are show here being set to their standard values.
export JBOSS_HOME=${HOME}/server/jboss-as-7.1.1.Final
export SPADE_VERSION=2.2.0
export SPADE_WAR_HOME=${HOME}/nest-spade-war-${SPADE_VERSION}Configuration
The simplest configuration of SPADE deployment expects to find data in the same directory as its associated semaphore file, with the same file name except for a simple change in suffix. After SPADE has copied the semaphore file and its data into its cache it deletes these from the drop box. However, there are situations where the data already exists elsewhere and making a copying of it in the dropbox gains you nothing. In those situations you can define a registration for the file stream that does not take its data from the dropbox, but rather takes it from some other location. You can install a registration that does just that by using the following command.
cp ${SPADE_WAR_HOME}/src/main/extras/examples/registration.4.xml ~/spade/registrations/localThe difference between this registration and the on used in the Loopback scenario, apart from changes to the local identity and semaphore suffix elements, is that the dataSuffix element of the registration has been replaced by a locatorClass element. That element specifies the class that implements the gov.lbl.nest.spade.registry.DataFileLocator interface and will be used to locate the data when its accompanying semaphore file has been detected by SPADE. In this case the ReadFromSemaphore class simply reads the data' location from the first line of the semaphore file.
Execution
Execution of this scenario is similar to that of the Loopback one with the one change being the creation of the data file in a directory other than the dropbox and putting that location, relative to the dropbox, into the semaphore file. The following commands show how to run the whole scenario.
${JBOSS_HOME}/bin/jboss-cli.sh --connect --command="deploy \
--name=spade.war ${SPADE_WAR_HOME}/target/spade-${SPADE_VERSION}.war"
mkdir -p ~/spade/other/directory/mock
cat > ~/spade/other/directory/mock/mock.6.data << EOF
put some junk in here
EOF
echo "../../other/directory/mock/mock.6.data" > ~/spade/dropbox/mock/mock.6.nem
${SPADE_WAR_HOME}/src/main/bash/localScan
# Wait for the "finisher" for this file to stop, e.g. 5 seconds
sleep 5
${SPADE_WAR_HOME}/src/main/bash/inboundScan
# Wait for the "finisher" for this file to stop, e.g. 5 seconds
sleep 5
${SPADE_WAR_HOME}/src/main/bash/sendConfirmations
find ~/spade/warehouse -name "mock.6.*"
ls -l ~/spade/other/directory/mock/mock.6.dataThe last command above is included to show that when a DataFileLocator instance is used to map the semaphore file onto its data then, by default, the data is not deleted by SPADE. This behavior can be modified. (See the Registration reference article for details.)